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

[Roland Haas]

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 .