[Users] ET build errors (Leonardo DCGP, CINECA cluster)

Thu Sep 4 12:00:39 CDT 2025

Hi Roland,

Thank you very much for your detailed explanations.

Here is another follow-up that seems to have a happy ending:

  *
I disabled the ADIOS2, AMReX and Silo thorns and recompiled.
     *
I did not add THCExtra/WeakRates to the disabled thorn list.
        *
>From what I understand, this must probably be related to WhiskyTHC, which I do not have installed.
     *
The build complained about the CMake version, triggered by the ExternalLibraries/OpenPMD thorn.

openPMD: Configuring...
CMake Error at CMakeLists.txt:3 (cmake_minimum_required):
  CMake 3.22.0 or higher is required.  You are running version 3.20.2

     *
For some reason, the build this time did not complain about the CCE_Export thorn, even though I did not update the -std=gnu+11 option under CXXFLAGS yet (I was trying to make one change at a time for clarity).
        *
I found this behavior strange. I guess the CMake error happened first, and the build terminated before reaching the CCE_Export problem?

Anyway, this error seemed easy enough to fix.

  *
I updated envsetup in my ini file with:
     *
module load cmake/3.27.9
  *
Recompiled, and the CMake version error went away, but (expectedly) the CCE_Export error reappeared.

Then,  I tried recompiling  by adding -std=gnu++14 to CXXFLAGS.

  *
The build failed, complaining again about the CCE_Export thorn.
  *
At least the change from gnu+11 to gnu++14did not cause new additional errors.
     *
at least no new errors, in the specific cluster and with the specific config files.

Then I tried recompiling by adding -std=gnu++17 to CXXFLAGS.

  *
>From the attached log file, it seems to me that the build was successful this time.
  *
No new errors arose because of the change to -std=gnu++17 in CXXFLAGS.

I will now attempt to run the TOV star example from the gallery and see if everything works as it should.

I will start a new email thread in case I encounter run problems.

I appreciate the help!

Best,
Panayotis

-------------------
Panagiotis Iosif
postdoctoral researcher
Department of Physics, University of Trieste
Via Alfonso Valerio 2, Trieste 34127
Italy
-------------------

________________________________
From: Roland Haas <rhaas at mail.ubc.ca>
Sent: Wednesday, September 3, 2025 5:29 PM
To: IOSIF PANAGIOTIS <PANAGIOTIS.IOSIF at units.it>
Cc: Einstein Toolkit Users <users at einsteintoolkit.org>
Subject: Re: [Users] ET build errors (Leonardo DCGP, CINECA cluster)

Hello Panayotis,

> I removed all CarpetX-related thorns and tried to compile again.
> This time, the build complained about thorns GRHayLHDX, GRHayLIDX, and NewRadX:

They are all using CarpetX (the "X" is the giveaway :-) ).

> Now the build complains about the CCE_Export thorn.

Hmm, that one is very new.

> You may see the error messages in the updated log file attached.
>
> From what I understand, the first main error seems to be this (see make_updated.log file):
> /leonardo/home/userexternal/piosif00/Cactus/arrangements/EinsteinAnalysis/CCE_Export/src/h5_export.cc:8:21: error: 'filesystem' is not a namespace-name; did you mean 'system'?
> 8 | namespace fs = std::filesystem;
> The text around that error message suggests that again a newer C++ dialect option might be required (-std=c++17' or '-std=gnu++17' ).

Hmm, for C++'s filesystem namespace is somewhat new. Some older
compiler put it in experimental/filesystem . However CCE_Export already
has code to handle this (in src/h5_export.cc):

#if defined __cpp_lib_filesystem && __cpp_lib_filesystem < 201703L
#include <experimental/filesystem>
namespace fs = std::experimental::filesystem;
#else
#include <filesystem>
namespace fs = std::filesystem;
#endif

Hmm, you are using gcc-12 though I'd have expected it to be new enough
for this.

Hmm, hmm, those __cpp_lib_filesystem ones may only haven been introduced
in C++20 (https://en.cppreference.com/w/cpp/feature_test.html) and they
require the <version> header, which itself is C++20 (though it exists
in gcc-12 and will have values).

Unfortunately even if I add

#include <version>

to src/h5_export.cc then things still fail with -std=gnu++11 since the
macros are only defined when C++17 is used.

So.... I'd disable the thorn (only used to export data for use with
SpECTRE's CCE code) or enable C++17 support.

This may require some larger reworking of the ET code to try and
contain C++17 requirements to CarpetX code if possible.

> In my current cfg file, following what was mentioned in the wiki page
> about configuring a new
> machine<https://docs.einsteintoolkit.org/et-docs/Configuring_a_new_machine>,
> I have an older option, namely -std=gnu+11, for CXXFLAGS.

gnu+11 is kind of old by now, at least I'd try gnu++14 (10 years old).
So no guarantees that this would work (gcc defaults to gnu++17 as of
version 11 "C++17 mode is the default since GCC 11" on
https://gcc.gnu.org/projects/cxx-status.html).

> I will experiment with different C standards options and see if
> something else works.

I'd have expected that both gnu++14 and gnu++17 should work actually
(as long as CarpetX related code is disable since it and eg AMReX
require C++17).

> Questions:
>
>   *
> Are GRHayLHDX, GRHayLIDX and NewRadX safe to disable?

Yes, they are all using CarpetX.

>      *
> For context, my goal is to start with isolated neutron star simulations. Are these thorns necessary for that?

No, they are CarpetX flavors of the GRHayLHD, GRHayLID and NewRad
thorns.

>   *
> Do we expect newer C/C++ standards, like -std=c++17, to break backwards compatibility, i.e. older code?

Yes, new standards will eventually remove functionality that has been
deprecated in older ones. On top of that g++ is becoming more strict in
allowing non-standard constructs. This is, unfortunately, beyond our
control.

>   *
> Please let me know if I am on the right track, or if you see some
> additional issues from the log file.

> Let me note that I did not start with all of the disabled thorns that
> Bruno's original ini
> file<https://bitbucket.org/simfactory/simfactory2/src/a6dff6ecc4a4346c5a73536681486e745d34bb98/mdb/machines/leonardo-DCGP.ini>
> uses, because I didn't know exactly what was needed or not.
> Currently, the disabled thorns in my ini file almost align with those
> in Bruno's original file. There are, though, some additional thorns
> disabled in Bruno's original file, namely: ADIOS2, AMReX, Silo, PAPI
> and THCExtra/WeakRates.

All except PAPI (which you'll only need if doing low-level
benchmarking) are using only by CarpetX (or in WeakRates case are no
even part of the Einstein Toolkit), so those can also be safely
disabled.

> I do not know if I should disable them too, but since I did not
> encounter specific errors about them, I let them be. Let me know if
> they should go too.

It will make compiling faster (note the MakeThornList script I had
suggested will also remove them).

Yours,
Roland

--
My email is as private as my paper mail. I therefore support encrypting
and signing email messages. Get my PGP key from http://pgp.mit.edu .
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.einsteintoolkit.org/pipermail/users/attachments/20250904/b9ba537c/attachment-0001.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: make_gnu17.log
Type: text/x-log
Size: 942149 bytes
Desc: make_gnu17.log
URL: <http://lists.einsteintoolkit.org/pipermail/users/attachments/20250904/b9ba537c/attachment-0001.bin>