[Users] ET build errors (Leonardo DCGP, CINECA cluster)
Roland Haas
rhaas at mail.ubc.ca
Thu Sep 4 13:20:01 CDT 2025
Hello Panayotis,
Thanks for the update. Fingers crossed that the simulations work well.
CCE_Export requires C++17 (or using the experimental branch
"rhaas/no_c++17" in https://github.com/rhaas80/CCE_Export).
If you do not intent to use SpECTRE's CCE code then you can disable
CCE_Export.
OpenPMD as of commit:
commit c6ac85d8f63ec4521e77d815035c0361c025614f (HEAD -> master, origin/master, origin/HEAD, origin/ET_2025_05, ET_2025_05)
Author: Roland Haas <rhaas at mail.ubc.ca>
Date: Thu Aug 7 18:26:43 2025 -0700
openPMD: bump version to 0.16.1
this includes fixes for HDF5 and a newewr version of toml11 that works
with CMake 4.0
bump json version to 3.12 for cmake 4.0 support
should work with CMake 4.0. But it is only ever used by CarpetX so if
you have disabled CarpetX you lose nothing by also disabling openPMD.
Yours,
Roland
> [CAUTION: Non-UBC Email]
>
> 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 .
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 .
More information about the Users
mailing list