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 machinehttps://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 filehttps://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