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 . _______________________________________________ Users mailing list Users@einsteintoolkit.org http://lists.einsteintoolkit.org/mailman/listinfo/users
