From users at einsteintoolkit.org Mon Sep 1 15:18:01 2025 From: users at einsteintoolkit.org (users at einsteintoolkit.org) Date: Mon, 01 Sep 2025 15:18:01 -0500 Subject: [Users] Agenda for Thursday's Meeting Message-ID: <68b5ff79.p1u09SG7c/tGhgPM%users@einsteintoolkit.org> Please update the Wiki with agenda items for Thursday's meeting. Thanks! https://docs.einsteintoolkit.org/et-docs/meeting_agenda --The Maintainers From PANAGIOTIS.IOSIF at units.it Tue Sep 2 08:32:26 2025 From: PANAGIOTIS.IOSIF at units.it (IOSIF PANAGIOTIS) Date: Tue, 2 Sep 2025 13:32:26 +0000 Subject: [Users] ET build errors (Leonardo DCGP, CINECA cluster) Message-ID: Hi Einstein Toolkit users, I am reaching out regarding some errors I am encountering during my attempts to compile ET on the Leonardo, CINECA cluster (DCGP partition). Here are some details on the Leonardo cluster: * cluster specifics: https://docs.hpc.cineca.it/hpc/leonardo.html#leonardo-card * OS: Red Hat Enterprise Linux 8.7 I attach the 4 configuration files I am using (with many added comments for guidance and future reference). I adapted them from the respective config files that Bruno Giacomazzo kindly provided. I also attach the make.log output of the command: ./simfactory/bin/sim build --verbose --reconfig --machine=leonardo-dcgp1 --optionlist simfactory/mdb/optionlists/leonardo-dcgp1.cfg --allocation=CNHPC_1479290_0 --thornlist thornlists/einsteintoolkit.th 2>&1 | tee make.log >From what I understand, the build process complains about syntax errors in the Exact thorn in these two source files: * decode_pars.F * Boost_rotation_symmetric.F How can I bypass the above problems? To be honest, I am not sure that I really need this thorn. I was simply trying to compile ET using the default thornlist from a fresh download/installation. Is there any other error that the log file is pointing out that I might be missing? Best regards, Panayotis ------------------- Panagiotis Iosif postdoctoral researcher Department of Physics, University of Trieste Via Alfonso Valerio 2, Trieste 34127 Italy ------------------- -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: make.log Type: text/x-log Size: 130884 bytes Desc: make.log URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: leonardo-dcgp1.sub Type: text/x-microdvd Size: 3432 bytes Desc: leonardo-dcgp1.sub URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: leonardo-dcgp1.run Type: application/octet-stream Size: 2673 bytes Desc: leonardo-dcgp1.run URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: leonardo-dcgp1.ini Type: application/octet-stream Size: 5628 bytes Desc: leonardo-dcgp1.ini URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: leonardo-dcgp1.cfg Type: application/octet-stream Size: 9429 bytes Desc: leonardo-dcgp1.cfg URL: From rhaas at phas.ubc.ca Tue Sep 2 10:08:09 2025 From: rhaas at phas.ubc.ca (Roland Haas) Date: Tue, 2 Sep 2025 08:08:09 -0700 Subject: [Users] ET build errors (Leonardo DCGP, CINECA cluster) In-Reply-To: References: Message-ID: <20250902080809.2c5aa158@fdea4908> Hello Panayotis, Thanks for including all the output files. In your options list whenever your set FPP you also must also set FPPFLAGS: FPPFLAGS=-traditional See eg generic.cfg or (very new!) Bruno's leonardo-DCGP.cfg file (in simfactory master). Yours, Roland > [CAUTION: Non-UBC Email] > > Hi Einstein Toolkit users, > > I am reaching out regarding some errors I am encountering during my attempts to compile ET on the Leonardo, CINECA cluster (DCGP partition). > > Here are some details on the Leonardo cluster: > > * > cluster specifics: https://docs.hpc.cineca.it/hpc/leonardo.html#leonardo-card > * > OS: Red Hat Enterprise Linux 8.7 > > I attach the 4 configuration files I am using (with many added comments for guidance and future reference). > I adapted them from the respective config files that Bruno Giacomazzo kindly provided. > > I also attach the make.log output of the command: > > ./simfactory/bin/sim build --verbose --reconfig --machine=leonardo-dcgp1 --optionlist simfactory/mdb/optionlists/leonardo-dcgp1.cfg --allocation=CNHPC_1479290_0 --thornlist thornlists/einsteintoolkit.th 2>&1 | tee make.log > > From what I understand, the build process complains about syntax errors in the Exact thorn in these two source files: > > * > decode_pars.F > * > Boost_rotation_symmetric.F > > How can I bypass the above problems? > > To be honest, I am not sure that I really need this thorn. > I was simply trying to compile ET using the default thornlist from a fresh download/installation. > > Is there any other error that the log file is pointing out that I might be missing? > > Best regards, > Panayotis > > > ------------------- > Panagiotis Iosif > postdoctoral researcher > Department of Physics, University of Trieste > Via Alfonso Valerio 2, Trieste 34127 > Italy > ------------------- > -- 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 . From PANAGIOTIS.IOSIF at units.it Tue Sep 2 10:19:24 2025 From: PANAGIOTIS.IOSIF at units.it (IOSIF PANAGIOTIS) Date: Tue, 2 Sep 2025 15:19:24 +0000 Subject: [Users] ET build errors (Leonardo DCGP, CINECA cluster) In-Reply-To: <20250902080809.2c5aa158@fdea4908> References: <20250902080809.2c5aa158@fdea4908> Message-ID: Hi Roland, In the config file I attached, I do have this line included already: FPPFLAGS = -g -traditional Is there anything else I might try? Best, Panayotis ________________________________ From: Roland Haas Sent: Tuesday, September 2, 2025 5:08 PM To: IOSIF PANAGIOTIS Cc: Einstein Toolkit Users Subject: Re: [Users] ET build errors (Leonardo DCGP, CINECA cluster) Hello Panayotis, Thanks for including all the output files. In your options list whenever your set FPP you also must also set FPPFLAGS: FPPFLAGS=-traditional See eg generic.cfg or (very new!) Bruno's leonardo-DCGP.cfg file (in simfactory master). Yours, Roland > [CAUTION: Non-UBC Email] > > Hi Einstein Toolkit users, > > I am reaching out regarding some errors I am encountering during my attempts to compile ET on the Leonardo, CINECA cluster (DCGP partition). > > Here are some details on the Leonardo cluster: > > * > cluster specifics: https://docs.hpc.cineca.it/hpc/leonardo.html#leonardo-card > * > OS: Red Hat Enterprise Linux 8.7 > > I attach the 4 configuration files I am using (with many added comments for guidance and future reference). > I adapted them from the respective config files that Bruno Giacomazzo kindly provided. > > I also attach the make.log output of the command: > > ./simfactory/bin/sim build --verbose --reconfig --machine=leonardo-dcgp1 --optionlist simfactory/mdb/optionlists/leonardo-dcgp1.cfg --allocation=CNHPC_1479290_0 --thornlist thornlists/einsteintoolkit.th 2>&1 | tee make.log > > From what I understand, the build process complains about syntax errors in the Exact thorn in these two source files: > > * > decode_pars.F > * > Boost_rotation_symmetric.F > > How can I bypass the above problems? > > To be honest, I am not sure that I really need this thorn. > I was simply trying to compile ET using the default thornlist from a fresh download/installation. > > Is there any other error that the log file is pointing out that I might be missing? > > Best regards, > Panayotis > > > ------------------- > Panagiotis Iosif > postdoctoral researcher > Department of Physics, University of Trieste > Via Alfonso Valerio 2, Trieste 34127 > Italy > ------------------- > -- 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: From rhaas at phas.ubc.ca Tue Sep 2 10:43:19 2025 From: rhaas at phas.ubc.ca (Roland Haas) Date: Tue, 2 Sep 2025 08:43:19 -0700 Subject: [Users] ET build errors (Leonardo DCGP, CINECA cluster) In-Reply-To: References: <20250902080809.2c5aa158@fdea4908> Message-ID: <20250902084319.7b1f0e24@fdea4908> Hello Panayotis, Oh, I had not noticed, sorry. Hmm, that is the typical cause for these issues. The only other difference I see is `-ffixed-line-length-none` though that would also point to an issue with the Cactus Fortran file processing not breaking things into short enough lines. Yours, Roland > [CAUTION: Non-UBC Email] > > Hi Roland, > > In the config file I attached, I do have this line included already: > > FPPFLAGS = -g -traditional > > Is there anything else I might try? > > Best, > Panayotis > ________________________________ > From: Roland Haas > Sent: Tuesday, September 2, 2025 5:08 PM > To: IOSIF PANAGIOTIS > Cc: Einstein Toolkit Users > Subject: Re: [Users] ET build errors (Leonardo DCGP, CINECA cluster) > > Hello Panayotis, > > Thanks for including all the output files. > > In your options list whenever your set FPP you also must also set > FPPFLAGS: > > FPPFLAGS=-traditional > > See eg generic.cfg or (very new!) Bruno's leonardo-DCGP.cfg file (in > simfactory master). > > Yours, > Roland > > > [CAUTION: Non-UBC Email] > > > > Hi Einstein Toolkit users, > > > > I am reaching out regarding some errors I am encountering during my attempts to compile ET on the Leonardo, CINECA cluster (DCGP partition). > > > > Here are some details on the Leonardo cluster: > > > > * > > cluster specifics: https://docs.hpc.cineca.it/hpc/leonardo.html#leonardo-card > > * > > OS: Red Hat Enterprise Linux 8.7 > > > > I attach the 4 configuration files I am using (with many added comments for guidance and future reference). > > I adapted them from the respective config files that Bruno Giacomazzo kindly provided. > > > > I also attach the make.log output of the command: > > > > ./simfactory/bin/sim build --verbose --reconfig --machine=leonardo-dcgp1 --optionlist simfactory/mdb/optionlists/leonardo-dcgp1.cfg --allocation=CNHPC_1479290_0 --thornlist thornlists/einsteintoolkit.th 2>&1 | tee make.log > > > > From what I understand, the build process complains about syntax errors in the Exact thorn in these two source files: > > > > * > > decode_pars.F > > * > > Boost_rotation_symmetric.F > > > > How can I bypass the above problems? > > > > To be honest, I am not sure that I really need this thorn. > > I was simply trying to compile ET using the default thornlist from a fresh download/installation. > > > > Is there any other error that the log file is pointing out that I might be missing? > > > > Best regards, > > Panayotis > > > > > > ------------------- > > Panagiotis Iosif > > postdoctoral researcher > > Department of Physics, University of Trieste > > Via Alfonso Valerio 2, Trieste 34127 > > Italy > > ------------------- > > > > > -- > 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 . -- 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 . From PANAGIOTIS.IOSIF at units.it Tue Sep 2 11:47:25 2025 From: PANAGIOTIS.IOSIF at units.it (IOSIF PANAGIOTIS) Date: Tue, 2 Sep 2025 16:47:25 +0000 Subject: [Users] ET build errors (Leonardo DCGP, CINECA cluster) In-Reply-To: <20250902084319.7b1f0e24@fdea4908> References: <20250902080809.2c5aa158@fdea4908> <20250902084319.7b1f0e24@fdea4908> Message-ID: Hi Roland, I amended my cfg file and added the flag -ffixed-line-length-none , in the Fortran 77 and 90 compiler options: * F77FLAGS = -g -march=native -fcray-pointer -ffixed-line-length-none * F90FLAGS = -g -march=native -fcray-pointer -ffixed-line-length-none This step solved the issue with the complaints about the "Exact" thorn. The build process continued and stopped at a different point, now complaining about the CarpetX/Arith thorn. I have attached the new make.log file. I ran the log through ChatGPT, and it suggested that this could be caused by C++ standard mismatches. Does this sound reasonable to you? Currently, the flags for the C and C++ compilers in my config file are like this: * CFLAGS = -g -march=native -std=gnu99 * CXXFLAGS = -g -march=native -std=gnu++11 I checked Bruno's file, and the respective options there are the following: * CFLAGS = -g -std=gnu99 #-std=c11 * CXXFLAGS = -g -std=gnu++0x #-std=c++14 However, I should note that in Bruno's version, all CarpetX-related thorns are disabled in the ini file. Again, I am not sure I need CarpetX. At this point, I am trying to get the build process to work and run some examples on the cluster. Returning to the compiler options, I suspect that CFLAGS can be left alone. Do you have any suggestions on how to change CXXFLAGS to bypass the CarpetX/Arith complaints? I checked the different C dialect options here, and it seems that there are a number of possibilities. Is there some -std=... option that is new enough for CarpetX and old/standard enough so that older C++ code is also OK? Best, Panayotis ________________________________ From: Roland Haas Sent: Tuesday, September 2, 2025 5:43 PM To: IOSIF PANAGIOTIS Cc: Einstein Toolkit Users Subject: Re: [Users] ET build errors (Leonardo DCGP, CINECA cluster) Hello Panayotis, Oh, I had not noticed, sorry. Hmm, that is the typical cause for these issues. The only other difference I see is `-ffixed-line-length-none` though that would also point to an issue with the Cactus Fortran file processing not breaking things into short enough lines. Yours, Roland > [CAUTION: Non-UBC Email] > > Hi Roland, > > In the config file I attached, I do have this line included already: > > FPPFLAGS = -g -traditional > > Is there anything else I might try? > > Best, > Panayotis > ________________________________ > From: Roland Haas > Sent: Tuesday, September 2, 2025 5:08 PM > To: IOSIF PANAGIOTIS > Cc: Einstein Toolkit Users > Subject: Re: [Users] ET build errors (Leonardo DCGP, CINECA cluster) > > Hello Panayotis, > > Thanks for including all the output files. > > In your options list whenever your set FPP you also must also set > FPPFLAGS: > > FPPFLAGS=-traditional > > See eg generic.cfg or (very new!) Bruno's leonardo-DCGP.cfg file (in > simfactory master). > > Yours, > Roland > > > [CAUTION: Non-UBC Email] > > > > Hi Einstein Toolkit users, > > > > I am reaching out regarding some errors I am encountering during my attempts to compile ET on the Leonardo, CINECA cluster (DCGP partition). > > > > Here are some details on the Leonardo cluster: > > > > * > > cluster specifics: https://docs.hpc.cineca.it/hpc/leonardo.html#leonardo-card > > * > > OS: Red Hat Enterprise Linux 8.7 > > > > I attach the 4 configuration files I am using (with many added comments for guidance and future reference). > > I adapted them from the respective config files that Bruno Giacomazzo kindly provided. > > > > I also attach the make.log output of the command: > > > > ./simfactory/bin/sim build --verbose --reconfig --machine=leonardo-dcgp1 --optionlist simfactory/mdb/optionlists/leonardo-dcgp1.cfg --allocation=CNHPC_1479290_0 --thornlist thornlists/einsteintoolkit.th 2>&1 | tee make.log > > > > From what I understand, the build process complains about syntax errors in the Exact thorn in these two source files: > > > > * > > decode_pars.F > > * > > Boost_rotation_symmetric.F > > > > How can I bypass the above problems? > > > > To be honest, I am not sure that I really need this thorn. > > I was simply trying to compile ET using the default thornlist from a fresh download/installation. > > > > Is there any other error that the log file is pointing out that I might be missing? > > > > Best regards, > > Panayotis > > > > > > ------------------- > > Panagiotis Iosif > > postdoctoral researcher > > Department of Physics, University of Trieste > > Via Alfonso Valerio 2, Trieste 34127 > > Italy > > ------------------- > > > > > -- > 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 . -- 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: -------------- next part -------------- A non-text attachment was scrubbed... Name: make.log Type: text/x-log Size: 423233 bytes Desc: make.log URL: From rhaas at phas.ubc.ca Tue Sep 2 12:05:44 2025 From: rhaas at phas.ubc.ca (Roland Haas) Date: Tue, 2 Sep 2025 10:05:44 -0700 Subject: [Users] ET build errors (Leonardo DCGP, CINECA cluster) In-Reply-To: References: <20250902080809.2c5aa158@fdea4908> <20250902084319.7b1f0e24@fdea4908> Message-ID: <20250902100544.5167e1d7@fdea4908> Hello Panayotis, oh, oops, for CarpetX (which includes Arith) code you actually need -std=c++17 . If you are not planning to develop for CarpetX then you can remove all CarpetX related thorns from your thornlist. Note that if you have a specific parameter file that you would like to run, then you can use the MakeThornList helper script to create a thornlist with just the thorns required for that parameter file, potentially speeding up compilation quite a bit. Something like: ./utils/Scripts/MakeThornList --master thornlists/einsteintoolkit.th --output thornlists/qc0.th par/qc0-mclachlan.par if you wanted to run qc0-mclachlan.par and had the full thornlist in thornlists/einsteintoolkit.th (GetComponents will do that for you). Then pass qc0.th to simfactory using its --thornlist argument (you likely also need to pass --reconfig to make sure it actually updates the thornlist it uses). Yours, Roland > [CAUTION: Non-UBC Email] > > Hi Roland, > > I amended my cfg file and added the flag -ffixed-line-length-none , > in the Fortran 77 and 90 compiler options: > > > * > F77FLAGS = -g -march=native -fcray-pointer -ffixed-line-length-none > * > F90FLAGS = -g -march=native -fcray-pointer -ffixed-line-length-none > > This step solved the issue with the complaints about the "Exact" > thorn. > > > The build process continued and stopped at a different point, now > complaining about the CarpetX/Arith thorn. > > I have attached the new make.log file. > > I ran the log through ChatGPT, and it suggested that this could be > caused by C++ standard mismatches. Does this sound reasonable to you? > > Currently, the flags for the C and C++ compilers in my config file > are like this: > > * > CFLAGS = -g -march=native -std=gnu99 > * > CXXFLAGS = -g -march=native -std=gnu++11 > > I checked Bruno's file, and the respective options there are the > following: > > * > CFLAGS = -g -std=gnu99 #-std=c11 > * > CXXFLAGS = -g -std=gnu++0x #-std=c++14 > > However, I should note that in Bruno's version, all CarpetX-related > thorns are disabled in the ini file. > > Again, I am not sure I need CarpetX. > At this point, I am trying to get the build process to work and run > some examples on the cluster. > > > Returning to the compiler options, I suspect that CFLAGS can be left > alone. Do you have any suggestions on how to change CXXFLAGS to > bypass the CarpetX/Arith complaints? > > I checked the different C dialect options > here, and > it seems that there are a number of possibilities. > > Is there some -std=... option that is new enough for CarpetX and > old/standard enough so that older C++ code is also OK? > > > Best, > Panayotis > > > > > ________________________________ > From: Roland Haas > Sent: Tuesday, September 2, 2025 5:43 PM > To: IOSIF PANAGIOTIS > Cc: Einstein Toolkit Users > Subject: Re: [Users] ET build errors (Leonardo DCGP, CINECA cluster) > > Hello Panayotis, > > Oh, I had not noticed, sorry. Hmm, that is the typical cause for these > issues. > > The only other difference I see is `-ffixed-line-length-none` though > that would also point to an issue with the Cactus Fortran file > processing not breaking things into short enough lines. > > Yours, > Roland > > > [CAUTION: Non-UBC Email] > > > > Hi Roland, > > > > In the config file I attached, I do have this line included already: > > > > FPPFLAGS = -g -traditional > > > > Is there anything else I might try? > > > > Best, > > Panayotis > > ________________________________ > > From: Roland Haas > > Sent: Tuesday, September 2, 2025 5:08 PM > > To: IOSIF PANAGIOTIS > > Cc: Einstein Toolkit Users > > Subject: Re: [Users] ET build errors (Leonardo DCGP, CINECA cluster) > > > > Hello Panayotis, > > > > Thanks for including all the output files. > > > > In your options list whenever your set FPP you also must also set > > FPPFLAGS: > > > > FPPFLAGS=-traditional > > > > See eg generic.cfg or (very new!) Bruno's leonardo-DCGP.cfg file (in > > simfactory master). > > > > Yours, > > Roland > > > > > [CAUTION: Non-UBC Email] > > > > > > Hi Einstein Toolkit users, > > > > > > I am reaching out regarding some errors I am encountering during > > > my attempts to compile ET on the Leonardo, CINECA cluster (DCGP > > > partition). > > > > > > Here are some details on the Leonardo cluster: > > > > > > * > > > cluster specifics: > > > https://docs.hpc.cineca.it/hpc/leonardo.html#leonardo-card * > > > OS: Red Hat Enterprise Linux 8.7 > > > > > > I attach the 4 configuration files I am using (with many added > > > comments for guidance and future reference). I adapted them from > > > the respective config files that Bruno Giacomazzo kindly provided. > > > > > > I also attach the make.log output of the command: > > > > > > ./simfactory/bin/sim build --verbose --reconfig > > > --machine=leonardo-dcgp1 --optionlist > > > simfactory/mdb/optionlists/leonardo-dcgp1.cfg > > > --allocation=CNHPC_1479290_0 --thornlist > > > thornlists/einsteintoolkit.th 2>&1 | tee make.log > > > > > > From what I understand, the build process complains about syntax > > > errors in the Exact thorn in these two source files: > > > > > > * > > > decode_pars.F > > > * > > > Boost_rotation_symmetric.F > > > > > > How can I bypass the above problems? > > > > > > To be honest, I am not sure that I really need this thorn. > > > I was simply trying to compile ET using the default thornlist > > > from a fresh download/installation. > > > > > > Is there any other error that the log file is pointing out that I > > > might be missing? > > > > > > Best regards, > > > Panayotis > > > > > > > > > ------------------- > > > Panagiotis Iosif > > > postdoctoral researcher > > > Department of Physics, University of Trieste > > > Via Alfonso Valerio 2, Trieste 34127 > > > Italy > > > ------------------- > > > > > > > > > -- > > 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 . > > > -- > 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 . From PANAGIOTIS.IOSIF at units.it Wed Sep 3 05:23:27 2025 From: PANAGIOTIS.IOSIF at units.it (IOSIF PANAGIOTIS) Date: Wed, 3 Sep 2025 10:23:27 +0000 Subject: [Users] ET build errors (Leonardo DCGP, CINECA cluster) In-Reply-To: <20250902100544.5167e1d7@fdea4908> References: <20250902080809.2c5aa158@fdea4908> <20250902084319.7b1f0e24@fdea4908> <20250902100544.5167e1d7@fdea4908> Message-ID: Hi Roland, Got it. Here is an update: I removed all CarpetX-related thorns and tried to compile again. This time, the build complained about thorns GRHayLHDX, GRHayLIDX, and NewRadX: CST error 1: -> Thorn 'GRHayLHDX' requires the capability 'Loop'. Please add a thorn that provides 'Loop' to your ThornList or remove 'GRHayLHDX' from it ! CST error 2: -> Thorn 'GRHayLIDX' requires the capability 'Loop'. Please add a thorn that provides 'Loop' to your ThornList or remove 'GRHayLIDX' from it ! CST error 3: -> Thorn 'NewRadX' requires the capability 'Loop'. Please add a thorn that provides 'Loop' to your ThornList or remove 'NewRadX' from it ! Comparing with Bruno's original file, I saw that he had disabled GRHayLHDX and GRHayLIDX. So I went ahead and disabled these two thorns for starters. Then the build complained just about the NewRadX thorn (same error message as above). So I disabled NewRadX too (see updated .ini file attached) and the error about NewRadX went away. Now the build complains about the CCE_Export thorn. 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' ). In my current cfg file, following what was mentioned in the wiki page about configuring a new machine, I have an older option, namely -std=gnu+11, for CXXFLAGS. I will experiment with different C standards options and see if something else works. Questions: * Are GRHayLHDX, GRHayLIDX and NewRadX safe to disable? * For context, my goal is to start with isolated neutron star simulations. Are these thorns necessary for that? * Do we expect newer C/C++ standards, like -std=c++17, to break backwards compatibility, i.e. older code? * 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 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. 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. Thanks for the help so far! Best, Panayotis ________________________________ From: Roland Haas Sent: Tuesday, September 2, 2025 7:05 PM To: IOSIF PANAGIOTIS Cc: rhaas at mail.ubc.ca ; Einstein Toolkit Users Subject: Re: [Users] ET build errors (Leonardo DCGP, CINECA cluster) Hello Panayotis, oh, oops, for CarpetX (which includes Arith) code you actually need -std=c++17 . If you are not planning to develop for CarpetX then you can remove all CarpetX related thorns from your thornlist. Note that if you have a specific parameter file that you would like to run, then you can use the MakeThornList helper script to create a thornlist with just the thorns required for that parameter file, potentially speeding up compilation quite a bit. Something like: ./utils/Scripts/MakeThornList --master thornlists/einsteintoolkit.th --output thornlists/qc0.th par/qc0-mclachlan.par if you wanted to run qc0-mclachlan.par and had the full thornlist in thornlists/einsteintoolkit.th (GetComponents will do that for you). Then pass qc0.th to simfactory using its --thornlist argument (you likely also need to pass --reconfig to make sure it actually updates the thornlist it uses). Yours, Roland > [CAUTION: Non-UBC Email] > > Hi Roland, > > I amended my cfg file and added the flag -ffixed-line-length-none , > in the Fortran 77 and 90 compiler options: > > > * > F77FLAGS = -g -march=native -fcray-pointer -ffixed-line-length-none > * > F90FLAGS = -g -march=native -fcray-pointer -ffixed-line-length-none > > This step solved the issue with the complaints about the "Exact" > thorn. > > > The build process continued and stopped at a different point, now > complaining about the CarpetX/Arith thorn. > > I have attached the new make.log file. > > I ran the log through ChatGPT, and it suggested that this could be > caused by C++ standard mismatches. Does this sound reasonable to you? > > Currently, the flags for the C and C++ compilers in my config file > are like this: > > * > CFLAGS = -g -march=native -std=gnu99 > * > CXXFLAGS = -g -march=native -std=gnu++11 > > I checked Bruno's file, and the respective options there are the > following: > > * > CFLAGS = -g -std=gnu99 #-std=c11 > * > CXXFLAGS = -g -std=gnu++0x #-std=c++14 > > However, I should note that in Bruno's version, all CarpetX-related > thorns are disabled in the ini file. > > Again, I am not sure I need CarpetX. > At this point, I am trying to get the build process to work and run > some examples on the cluster. > > > Returning to the compiler options, I suspect that CFLAGS can be left > alone. Do you have any suggestions on how to change CXXFLAGS to > bypass the CarpetX/Arith complaints? > > I checked the different C dialect options > here, and > it seems that there are a number of possibilities. > > Is there some -std=... option that is new enough for CarpetX and > old/standard enough so that older C++ code is also OK? > > > Best, > Panayotis > > > > > ________________________________ > From: Roland Haas > Sent: Tuesday, September 2, 2025 5:43 PM > To: IOSIF PANAGIOTIS > Cc: Einstein Toolkit Users > Subject: Re: [Users] ET build errors (Leonardo DCGP, CINECA cluster) > > Hello Panayotis, > > Oh, I had not noticed, sorry. Hmm, that is the typical cause for these > issues. > > The only other difference I see is `-ffixed-line-length-none` though > that would also point to an issue with the Cactus Fortran file > processing not breaking things into short enough lines. > > Yours, > Roland > > > [CAUTION: Non-UBC Email] > > > > Hi Roland, > > > > In the config file I attached, I do have this line included already: > > > > FPPFLAGS = -g -traditional > > > > Is there anything else I might try? > > > > Best, > > Panayotis > > ________________________________ > > From: Roland Haas > > Sent: Tuesday, September 2, 2025 5:08 PM > > To: IOSIF PANAGIOTIS > > Cc: Einstein Toolkit Users > > Subject: Re: [Users] ET build errors (Leonardo DCGP, CINECA cluster) > > > > Hello Panayotis, > > > > Thanks for including all the output files. > > > > In your options list whenever your set FPP you also must also set > > FPPFLAGS: > > > > FPPFLAGS=-traditional > > > > See eg generic.cfg or (very new!) Bruno's leonardo-DCGP.cfg file (in > > simfactory master). > > > > Yours, > > Roland > > > > > [CAUTION: Non-UBC Email] > > > > > > Hi Einstein Toolkit users, > > > > > > I am reaching out regarding some errors I am encountering during > > > my attempts to compile ET on the Leonardo, CINECA cluster (DCGP > > > partition). > > > > > > Here are some details on the Leonardo cluster: > > > > > > * > > > cluster specifics: > > > https://docs.hpc.cineca.it/hpc/leonardo.html#leonardo-card * > > > OS: Red Hat Enterprise Linux 8.7 > > > > > > I attach the 4 configuration files I am using (with many added > > > comments for guidance and future reference). I adapted them from > > > the respective config files that Bruno Giacomazzo kindly provided. > > > > > > I also attach the make.log output of the command: > > > > > > ./simfactory/bin/sim build --verbose --reconfig > > > --machine=leonardo-dcgp1 --optionlist > > > simfactory/mdb/optionlists/leonardo-dcgp1.cfg > > > --allocation=CNHPC_1479290_0 --thornlist > > > thornlists/einsteintoolkit.th 2>&1 | tee make.log > > > > > > From what I understand, the build process complains about syntax > > > errors in the Exact thorn in these two source files: > > > > > > * > > > decode_pars.F > > > * > > > Boost_rotation_symmetric.F > > > > > > How can I bypass the above problems? > > > > > > To be honest, I am not sure that I really need this thorn. > > > I was simply trying to compile ET using the default thornlist > > > from a fresh download/installation. > > > > > > Is there any other error that the log file is pointing out that I > > > might be missing? > > > > > > Best regards, > > > Panayotis > > > > > > > > > ------------------- > > > Panagiotis Iosif > > > postdoctoral researcher > > > Department of Physics, University of Trieste > > > Via Alfonso Valerio 2, Trieste 34127 > > > Italy > > > ------------------- > > > > > > > > > -- > > 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 . > > > -- > 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 . -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: make_updated.log Type: text/x-log Size: 321172 bytes Desc: make_updated.log URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: leonardo-dcgp1_updated.ini Type: application/octet-stream Size: 6470 bytes Desc: leonardo-dcgp1_updated.ini URL: From rhaas at mail.ubc.ca Wed Sep 3 10:29:06 2025 From: rhaas at mail.ubc.ca (Roland Haas) Date: Wed, 3 Sep 2025 08:29:06 -0700 Subject: [Users] ET build errors (Leonardo DCGP, CINECA cluster) In-Reply-To: References: <20250902080809.2c5aa158@fdea4908> <20250902084319.7b1f0e24@fdea4908> <20250902100544.5167e1d7@fdea4908> Message-ID: <20250903082906.03675083@haengie2.phas.ubc.ca> 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 namespace fs = std::experimental::filesystem; #else #include 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 header, which itself is C++20 (though it exists in gcc-12 and will have values). Unfortunately even if I add #include 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, > 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 > 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 . From users at einsteintoolkit.org Wed Sep 3 17:15:02 2025 From: users at einsteintoolkit.org (users at einsteintoolkit.org) Date: Wed, 03 Sep 2025 17:15:02 -0500 Subject: [Users] Einstein Toolkit Meeting Reminder Message-ID: <68b8bde6.w0IYi92W+DEmY7/d%users@einsteintoolkit.org> Hello, Please consider joining the weekly Einstein Toolkit phone call at 9:00 am US central time on Thursdays. For details on how to connect and what agenda items are to be discussed, use the link below. https://docs.einsteintoolkit.org/et-docs/Main_Page#Weekly_Users_Call --The Maintainers From f.h.noori at gmail.com Thu Sep 4 10:02:54 2025 From: f.h.noori at gmail.com (Fatemeh Hossein Nouri) Date: Thu, 4 Sep 2025 17:02:54 +0200 Subject: [Users] Help with Spritz + external FUKA/Kadath Message-ID: Hi all, I?ve been trying to run Spritz using initial data generated by the latest version of FUKA for a BNS simulation, but I?ve run into issues related to the Kadath libraries. At first, I was getting a mismatch error (Assertion ndim==nbr_points.get_ndim()), which suggests an incompatibility between Spritz?s bundled Kadath and the external version of FUKA/Kadath I used to generate the initial data. To fix this, I tried to build Spritz against my own external Kadath installation (~/fuka/lib/libkadath.a) instead of the one bundled in the Einstein Toolkit. I did this by disabling these thorns in my thornlist: Fuka/kadath_pizza, Fuka/KadathImporter and Fuka/KadathThorn. I also added the following lines to my ET_2024_05/Cactus/simfactory/mdb/optionlists/.cfg KADATH_DIR = $(HOME)/fuka KADATH_INC_DIRS = $(KADATH_DIR)/include KADATH_LIB_DIRS = $(KADATH_DIR)/lib One question so far: Did I do things correctly? Then I removed the old Kadath: rm -rf configs/Spritz_LORENE/build/Kadath The code compiles fine, but when I try to run the executable with my parameter file, using the '-S' option, I get: Error: Thorn kadathimporter not found Error: Thorn kadaththorn not found Activation failed - 2 errors in activation sequence The confusing part is that my ActiveThorns line in the .par file does not explicitly list KadathThorn or KadathImporter: ActiveThorns = "volomnia bnstrackergen bnsanalysis pizzanumutils" Yet Spritz fails because those thorns are missing. From what I understand, some of the thorns I?m using (like volomnia, bnstrackergen, or bnsanalysis) depend on KadathThorn and KadathImporter, so they are indirectly required. The core problem: - I need to keep KadathThorn and KadathImporter active, since my parameter file requires them through dependencies. - But I also need them to link against my external Kadath ( ~/fuka/lib/libkadath.a) so that the FUKA initial data is compatible. Would you have suggestions on the cleanest way to make the ET KadathThorn and KadathImporter use my external Kadath library? Is there a recommended workflow for this? Thanks in advance for your help! Bests, Fatemeh Nouri -------------- next part -------------- An HTML attachment was scrubbed... URL: From PANAGIOTIS.IOSIF at units.it Thu Sep 4 12:00:39 2025 From: PANAGIOTIS.IOSIF at units.it (IOSIF PANAGIOTIS) Date: Thu, 4 Sep 2025 17:00:39 +0000 Subject: [Users] ET build errors (Leonardo DCGP, CINECA cluster) In-Reply-To: <20250903082906.03675083@haengie2.phas.ubc.ca> References: <20250902080809.2c5aa158@fdea4908> <20250902084319.7b1f0e24@fdea4908> <20250902100544.5167e1d7@fdea4908> <20250903082906.03675083@haengie2.phas.ubc.ca> Message-ID: 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 Sent: Wednesday, September 3, 2025 5:29 PM To: IOSIF PANAGIOTIS Cc: Einstein Toolkit Users 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 namespace fs = std::experimental::filesystem; #else #include 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 header, which itself is C++20 (though it exists in gcc-12 and will have values). Unfortunately even if I add #include 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, > 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 > 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: -------------- next part -------------- A non-text attachment was scrubbed... Name: make_gnu17.log Type: text/x-log Size: 942149 bytes Desc: make_gnu17.log URL: From rhaas at mail.ubc.ca Thu Sep 4 13:20:01 2025 From: rhaas at mail.ubc.ca (Roland Haas) Date: Thu, 4 Sep 2025 11:20:01 -0700 Subject: [Users] ET build errors (Leonardo DCGP, CINECA cluster) In-Reply-To: References: <20250902080809.2c5aa158@fdea4908> <20250902084319.7b1f0e24@fdea4908> <20250902100544.5167e1d7@fdea4908> <20250903082906.03675083@haengie2.phas.ubc.ca> Message-ID: <20250904112001.6f802d77@haengie2.phas.ubc.ca> 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 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 > Sent: Wednesday, September 3, 2025 5:29 PM > To: IOSIF PANAGIOTIS > Cc: Einstein Toolkit Users > 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 > namespace fs = std::experimental::filesystem; > #else > #include > 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 header, which itself is C++20 (though it exists > in gcc-12 and will have values). > > Unfortunately even if I add > > #include > > 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, > > 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 > > 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 . From bill.gabella at gmail.com Thu Sep 4 14:06:44 2025 From: bill.gabella at gmail.com (Bill Gabella) Date: Thu, 4 Sep 2025 15:06:44 -0400 Subject: [Users] Meeting Minutes 2025-09-04 Message-ID: <45961438-66cd-418d-8a76-ba9e590cbcbf@gmail.com> Minutes for the Einstein Toolkit Meeting, 20250904. https://docs.einsteintoolkit.org/et-docs/Main_Page#Weekly_Users_Call 9am CDT Thursdays Present:? Steve B, Deborah F, Peter D, Peyhan, Roland H, Lucas TS, Johnny T, Nikolai W, Zach E, Keith D, Bill G, Leo W Chair: Peter D?? Minutes: Bill G * BBH gallery example (Zach) -- not yet done (2024-11 also missing) Peter and Zach, no new work. * AOB ** Next release is in May 2026 and Steve is the release manager. https://docs.einsteintoolkit.org/et-docs/Release_Process * Unanswered emails https://www.einsteintoolkit.org/tools/unanswered.php ** No updates. * Open tickets sorted https://bitbucket.org/einsteintoolkit/tickets/issues?status=open&status=new&sort=-updated_on #2885, test for std::filesystem availability in Silo output likely broken Roland, this should not affect you if you are on a modern system. You have to look at a predefined variable and you have to use it to include the version of a file, and it is declared in those files.? There is a version.h that was standardized in C++20...exists in older gcc but not standardized.? In the IO code of Carpet that writes out Silo, maybe check on a file existence. Not a major issue.? Was in CC_Export also, which has a recent pull request with the fix.? Some bug with a static variable that depends on a function argument so it is never changed.? On Deborah's to do list also.? Deborah, it may not need to change. Will take a look at it. #2882, Running BBH with CarpetX with CPUs: High memory consumption and low performance Alejandra will take a look at it. #1847, FFTW3 fortran interface not working for system installation A very old ticket from Frank Loeffler.? Yosef may use FFTW in his code(s). #2858, SF files for MN5 (was: Compiling CarpetX: issues with PDESolvers) Changed the name to the current one.? Lucas has begun testing, thinks files very specific to Alejandra's work, on Marenostrum 5 (Barcelona).? Some external libraries seem to compile themselves and put them into a folder referencing the user.? Steve, not uncommon but should not had code the user directory.? Lucas, that is what is happening here.? On LSU machines there are directories hardcoded to Steve's directories; that is where the external libraries are, and this works. Steve, setup a system to have future checkouts and builds refer to previous compiled libraries/tools.? Some external libraries take forever to compile and better to refer to some already installed library.? Good to have a "benevolent user" to install these for global use. Lucas, (Marenostrum) the machine is organized into projects and allocations, and projects have an expiration date...like a DOE machine.? Steve, that is awful.? Lucas agrees.? Lucas, think singularity would be the right thing to do, if the image is put together correctly.? Peter, can you chance the setup so that they use external libraries instead of their pre-compiled ones?? Lucas, have not tested with the bundles libraries.? Believe they tried that and failed.? Roland, you might succeed, when they tried some of the libraries did a git clone of a repositories.? Lucas, Marenostrum has limitations that annoy one.? Will try the bare minimum and see if that works. #2866, Problem while building the ET on MN5: OpenCL Steve disavows any knowledge of this one---name removed from ticket.? This is for Marenostrum 5. ?? [European clusters with ET include Marenostrum 5 (Barcelona), Leonardo (Bologna), and Sunrise (Stockholm).]? ? Peter, maybe Lucas can take a look at OpenCL? Roland, we are not using OpenCL for anything now---once we had an example using it.? Lucas, will try the bundled version of OpenCL and if it fails will ask them to take it out.? Leaching off of Steve's Singularity image which works on LSU machines, might try for Marenostrum. #2867, WaveToyX examples, HDF5 output error in all three examples. Steve, we discuss this every wekk and the error message is considered harmless.? We should close this ticket. #2773, make CarpetX-ThornDoc is confused in InterLatex.pl Steve, I need to check on that. #2878, CarpetX: Add multipatch output support to Silo Lucas, sitting and waiting for review.? Not urgent. #2764, PUGH tries to free memory not allocated by malloc Beyhan, no update. #2282, gallery examples use low-order integration n Multipole Roland, part of updating. #963, Improve McLachlan accuracy Peter, will meet with Zach and work on this. #2706, Update default TwoPunctures parameters, or at least default parameters in BBH gallery example Zach, part of the BBH Gallery example and will be looked at. #2877, ET_BHaHAHA Features Ticket Zach, keep this one, I use it as a ticket to jot down ideas to improve the robustness of BHaHAHA. #2855, NoiseX: Improve noise generation in CarpetX Lucas, not worked on it for a while, intend to get back to it. #2874, NRPyElliptic lacks regeneration instructions Leo, on my list, will get back to it.? Zach, you should wait on this.? I plan to refactor NRPyElliptic in a library like BHaHAHA. The refactor will be a different NRPyElliptic. #2862, Update `SpacetimeX/Z4c` robust stability paramete file Lucas, that is just a parameter file update.? Will review desire to include.? The existing one did not work, but this one should. #2860, Don't call the optimized 4th order second derivative operators. Peter, will take a look at it. #2052, piraha assumes that assert(false) always aborts Steve, I will get to this one. * Tickets for Review https://bitbucket.org/einsteintoolkit/tickets/issues?status=new&status=open&sort=-updated_on&q=Please%20review Nothing new.? Roland, no longer a ticket to backport libraries that compile with GCC 15 to earlier or to update with cmake 4.0. Applied those changes to master and release branches.? Tickets #2880, #2883. *AOB at end of meeting Roland, have a CarpetX call next and Erik said he would give a presentation on mesh files. Zach, should we advertise the CarpetX call?? Roland, we should list it.? Will draft a description of CarpetX and give the call link.? Bill, maybe we should put it down at the ET Meeting link [wiki] and not on the front web page. CarpetX wiki https://github.com/EinsteinToolkit/CarpetX/wiki CarpetX zoom https://ubc.zoom.us/j/66033196685?pwd=zxXTpcrBY1L7nT2kNFITm71ZuoZEiO.1 Next Meeting, Thursday, 11 September 2025. https://docs.einsteintoolkit.org/et-docs/Meeting_agenda FYI, bill e.g. -- Home Page LinkedIn -------------- next part -------------- An HTML attachment was scrubbed... URL: From topolski at itp.uni-frankfurt.de Fri Sep 5 01:04:31 2025 From: topolski at itp.uni-frankfurt.de (Konrad Topolski) Date: Fri, 05 Sep 2025 08:04:31 +0200 Subject: [Users] =?utf-8?q?Help_with_Spritz_+_external_FUKA/Kadath?= In-Reply-To: References: Message-ID: <2a49b-68ba7d80-461-21e18e00@197642200> Hi Fatemeh, The thorns you've disabled in the thornlist are responsible for the import of the data in the ADMBase / Hydrobase variables and interact directly with the FUKA exporters (in the bundled/separate FUKA installation). As such, they are necessary to import FUKA ID and simultaneously independent of the thorns you use for subsequent evolution. The kadathimport thorn provides the headers for the import functions for specific initial data, whose implementation is then linked from libkadath.a.? I would recommend that you uncomment the thorns in the thornlist, recompile (kadath library linking is still governed by the .cfg file, which shouldn't change) and re-enable the thorns in the parameter file so that they're active and the ETK can schedule the import routines in the appropriate bins. I was actually unaware that bnsanalysis and related analysis thorns depend on the kadath importer thorns. Is this a custom extension or is it possible that some other thorn lists them as depencencies?? In any case, doing the above should help. Best regards Konrad W dniu: Czwartek, Wrzesie? 04, 2025 17:02 CEST, Fatemeh Hossein Nouri napisa?(a): ? Hi all,? I?ve been trying to run Spritz?using initial data generated by the latest version of FUKA for a BNS simulation, but I?ve run into issues related to the Kadath libraries. At first, I was getting a mismatch error (Assertion ndim==nbr_points.get_ndim()), which suggests an incompatibility between Spritz?s bundled Kadath and the external version of FUKA/Kadath I used to generate the initial data. To fix this, I tried to build Spritz against my own external Kadath installation (~/fuka/lib/libkadath.a) instead of the one bundled in the Einstein Toolkit. I did this by disabling these thorns in my thornlist:?Fuka/kadath_pizza,?Fuka/KadathImporter and?Fuka/KadathThorn. I also added the following lines to my?ET_2024_05/Cactus/simfactory/mdb/optionlists/.cfg KADATH_DIR = $(HOME)/fuka KADATH_INC_DIRS = $(KADATH_DIR)/include ? KADATH_LIB_DIRS =?$(KADATH_DIR)/lib ? One question so far: Did I do things correctly? ? Then I removed the old Kadath: ? ? rm -rf configs/Spritz_LORENE/build/Kadath The code compiles fine, but when I try to run the executable with my parameter file, using the '-S' option, I get:?Error: Thorn kadathimporter not found Error: Thorn kadaththorn not found Activation failed - 2 errors in activation sequence The confusing part is that my ActiveThorns line in the .par file does not explicitly list KadathThorn or KadathImporter:?ActiveThorns = "volomnia bnstrackergen bnsanalysis pizzanumutils" Yet Spritz fails because those thorns are missing. From what I understand, some of the thorns I?m using (like volomnia, bnstrackergen, or bnsanalysis) depend on KadathThorn and KadathImporter, so they are indirectly required. The core problem: - I need to keep KadathThorn and KadathImporter active, since my parameter file requires them through dependencies. - But I also need them to link against my external Kadath (~/fuka/lib/libkadath.a) so that the FUKA initial data is compatible. Would you have suggestions on the cleanest way to make the ET KadathThorn and KadathImporter use my external Kadath library? Is there a recommended workflow for this? Thanks in advance for your help! Bests, Fatemeh Nouri ? ? -------------- next part -------------- An HTML attachment was scrubbed... URL: From tootle at itp.uni-frankfurt.de Fri Sep 5 01:21:23 2025 From: tootle at itp.uni-frankfurt.de (Samuel Tootle) Date: Fri, 5 Sep 2025 08:21:23 +0200 (GMT+02:00) Subject: [Users] Help with Spritz + external FUKA/Kadath In-Reply-To: <2a49b-68ba7d80-461-21e18e00@197642200> References: <2a49b-68ba7d80-461-21e18e00@197642200> Message-ID: <4b5c7353-39e1-4b40-8206-8ba7860f6cdb@itp.uni-frankfurt.de> Hi Fatemeh, In addition to Konrad's correct notes, I want to addresd the build issues: > "At first, I was getting a mismatch error (Assertion ndim==nbr_points.get_ndim()), which suggests an incompatibility between Spritz?s bundled Kadath and the external version of FUKA/Kadath I used to generate the initial data. > > To fix this, I tried to build Spritz against my own external Kadath installation (~/fuka/lib/libkadath.a) instead of the one bundled in the Einstein Toolkit. I did this by disabling these thorns in my thornlist:?Fuka/kadath_pizza,?Fuka/KadathImporter and?Fuka/KadathThorn. I also added the following lines to my?ET_2024_05/Cactus/simfactory/mdb/optionlists/.cfg > > KADATH_DIR = $(HOME)/fuka > > KADATH_INC_DIRS = $(KADATH_DIR)/include > ? > > KADATH_LIB_DIRS =?$(KADATH_DIR)/lib" You are likely correct if there is a pre compiled version of Fuka with spritz. If the data was generated with the latest release (since June 25), there is a discrepancy with how the numerical domains are constructed and stored as noted in the Readme. Linking against the latest library should resolve the ndim error. Regarding your cfg, I believe you have to use brackets, not parentheses, e.g. ${HOME_KADATH}, for the etk config parser to recognize environment variables. All the best, Samuel Volunteer Physicist Sep 5, 2025 08:04:51 Konrad Topolski : > Hi Fatemeh, > > The thorns you've disabled in the thornlist are responsible for the import of the data in the ADMBase / Hydrobase variables and interact directly with the FUKA exporters (in the bundled/separate FUKA installation). As such, they are necessary to import FUKA ID and simultaneously independent of the thorns you use for subsequent evolution. > > The kadathimport thorn provides the headers for the import functions for specific initial data, whose implementation is then linked from libkadath.a.? > > I would recommend that you uncomment the thorns in the thornlist, recompile (kadath library linking is still governed by the .cfg file, which shouldn't change) and re-enable the thorns in the parameter file so that they're active and the ETK can schedule the import routines in the appropriate bins. > > I was actually unaware that bnsanalysis and related analysis thorns depend on the kadath importer thorns. Is this a custom extension or is it possible that some other thorn lists them as depencencies?? > > In any case, doing the above should help. > > Best regards > > Konrad > > > > W dniu: Czwartek, Wrzesie? 04, 2025 17:02 CEST, Fatemeh Hossein Nouri napisa?(a): > > ? > >> Hi all,? >> >> I?ve been trying to run Spritz?using initial data generated by the latest version of FUKA for a BNS simulation, but I?ve run into issues related to the Kadath libraries. >> >> At first, I was getting a mismatch error (*Assertion ndim==nbr_points.get_ndim()*), which suggests an incompatibility between Spritz?s bundled Kadath and the external version of FUKA/Kadath I used to generate the initial data. >> >> To fix this, I tried to build Spritz against my own external Kadath installation (*~/fuka/lib/libkadath.a*) instead of the one bundled in the Einstein Toolkit. I did this by disabling these thorns in my thornlist:?Fuka/kadath_pizza,?Fuka/KadathImporter and?Fuka/KadathThorn. I also added the following lines to my?ET_2024_05/Cactus/simfactory/mdb/optionlists/.cfg >> >> KADATH_DIR = $(HOME)/fuka >> >> KADATH_INC_DIRS = $(KADATH_DIR)/include >> ? >> >> KADATH_LIB_DIRS =?$(KADATH_DIR)/lib >> >> ? >> One question so far: Did I do things correctly? >> >> ? >> Then I removed the old Kadath: >> >> ? >> ? >> rm -rf configs/Spritz_LORENE/build/Kadath >> >> The code compiles fine, but when I try to run the executable with my parameter file, using the '-S' option, I get: >> >> ? >> *Error: Thorn kadathimporter not found Error: Thorn kadaththorn not found Activation failed - 2 errors in activation sequence* >> >> The confusing part is that my *ActiveThorns* line in the *.par* file does not explicitly list *KadathThorn* or *KadathImporter*: >> >> ? >> *ActiveThorns = "volomnia bnstrackergen bnsanalysis pizzanumutils"* >> >> Yet Spritz fails because those thorns are missing. From what I understand, some of the thorns I?m using (like *volomnia*, *bnstrackergen*, or *bnsanalysis*) depend on *KadathThorn* and *KadathImporter*, so they are indirectly required. >> >> The core problem: >> >> - I need to keep *KadathThorn* and *KadathImporter* active, since my parameter file requires them through dependencies. >> >> - But I also need them to link against my external Kadath (*~/fuka/lib/libkadath.a*) so that the FUKA initial data is compatible. >> >> Would you have suggestions on the cleanest way to make the ET *KadathThorn* and *KadathImporter* use my external Kadath library? Is there a recommended workflow for this? >> >> Thanks in advance for your help! >> >> Bests, >> >> Fatemeh Nouri >> >> >> ? >> > > > > ? > -------------- next part -------------- An HTML attachment was scrubbed... URL: From f.h.noori at gmail.com Fri Sep 5 11:11:18 2025 From: f.h.noori at gmail.com (Fatemeh Hossein Nouri) Date: Fri, 5 Sep 2025 18:11:18 +0200 Subject: [Users] Help with Spritz + external FUKA/Kadath In-Reply-To: <4b5c7353-39e1-4b40-8206-8ba7860f6cdb@itp.uni-frankfurt.de> References: <2a49b-68ba7d80-461-21e18e00@197642200> <4b5c7353-39e1-4b40-8206-8ba7860f6cdb@itp.uni-frankfurt.de> Message-ID: Thank you very much for the help! The problem is solved now. Best regards, Fatemeh On Fri, Sep 5, 2025 at 8:21?AM Samuel Tootle wrote: > Hi Fatemeh, > > In addition to Konrad's correct notes, I want to addresd the build issues: > > "At first, I was getting a mismatch error (Assertion > ndim==nbr_points.get_ndim()), which suggests an incompatibility between > Spritz?s bundled Kadath and the external version of FUKA/Kadath I used to > generate the initial data. > > To fix this, I tried to build Spritz against my own external Kadath > installation (~/fuka/lib/libkadath.a) instead of the one bundled in the > Einstein Toolkit. I did this by disabling these thorns in my > thornlist: Fuka/kadath_pizza, Fuka/KadathImporter and Fuka/KadathThorn. I > also added the following lines to > my ET_2024_05/Cactus/simfactory/mdb/optionlists/.cfg > > KADATH_DIR = $(HOME)/fuka > > KADATH_INC_DIRS = $(KADATH_DIR)/include > > > KADATH_LIB_DIRS = $(KADATH_DIR)/lib" > > > > You are likely correct if there is a pre compiled version of Fuka with > spritz. If the data was generated with the latest release (since June 25), > there is a discrepancy with how the numerical domains are constructed and > stored as noted in the Readme. Linking against the latest library should > resolve the ndim error. > > Regarding your cfg, I believe you have to use brackets, not parentheses, > e.g. ${HOME_KADATH}, for the etk config parser to recognize environment > variables. > > All the best, > Samuel > Volunteer Physicist > > Sep 5, 2025 08:04:51 Konrad Topolski : > > Hi Fatemeh, > > The thorns you've disabled in the thornlist are responsible for the import > of the data in the ADMBase / Hydrobase variables and interact directly with > the FUKA exporters (in the bundled/separate FUKA installation). As such, > they are necessary to import FUKA ID and simultaneously independent of the > thorns you use for subsequent evolution. > > The kadathimport thorn provides the headers for the import functions for > specific initial data, whose implementation is then linked from > libkadath.a. > > I would recommend that you uncomment the thorns in the thornlist, > recompile (kadath library linking is still governed by the .cfg file, which > shouldn't change) and re-enable the thorns in the parameter file so that > they're active and the ETK can schedule the import routines in the > appropriate bins. > > I was actually unaware that bnsanalysis and related analysis thorns depend > on the kadath importer thorns. Is this a custom extension or is it possible > that some other thorn lists them as depencencies? > > In any case, doing the above should help. > > Best regards > > Konrad > > > > W dniu: Czwartek, Wrzesie? 04, 2025 17:02 CEST, Fatemeh Hossein Nouri < > f.h.noori at gmail.com> napisa?(a): > > > > Hi all, > > I?ve been trying to run Spritz using initial data generated by the latest > version of FUKA for a BNS simulation, but I?ve run into issues related to > the Kadath libraries. > > At first, I was getting a mismatch error (Assertion > ndim==nbr_points.get_ndim()), which suggests an incompatibility between > Spritz?s bundled Kadath and the external version of FUKA/Kadath I used to > generate the initial data. > > To fix this, I tried to build Spritz against my own external Kadath > installation (~/fuka/lib/libkadath.a) instead of the one bundled in the > Einstein Toolkit. I did this by disabling these thorns in my thornlist: Fuka/kadath_pizza, Fuka/KadathImporter > and Fuka/KadathThorn. I also added the following lines to > my ET_2024_05/Cactus/simfactory/mdb/optionlists/.cfg > > KADATH_DIR = $(HOME)/fuka > > KADATH_INC_DIRS = $(KADATH_DIR)/include > > > > KADATH_LIB_DIRS = $(KADATH_DIR)/lib > > > > > One question so far: Did I do things correctly? > > > > > Then I removed the old Kadath: > > > > > > > rm -rf configs/Spritz_LORENE/build/Kadath > > The code compiles fine, but when I try to run the executable with my > parameter file, using the '-S' option, I get: > > Error: Thorn kadathimporter not found Error: Thorn kadaththorn not found > Activation failed - 2 errors in activation sequence > > The confusing part is that my ActiveThorns line in the .par file does not > explicitly list KadathThorn or KadathImporter: > > ActiveThorns = "volomnia bnstrackergen bnsanalysis pizzanumutils" > > Yet Spritz fails because those thorns are missing. From what I understand, > some of the thorns I?m using (like volomnia, bnstrackergen, or bnsanalysis) > depend on KadathThorn and KadathImporter, so they are indirectly required. > > The core problem: > > - I need to keep KadathThorn and KadathImporter active, since my > parameter file requires them through dependencies. > > - But I also need them to link against my external Kadath ( > ~/fuka/lib/libkadath.a) so that the FUKA initial data is compatible. > > Would you have suggestions on the cleanest way to make the ET KadathThorn > and KadathImporter use my external Kadath library? Is there a recommended > workflow for this? > > Thanks in advance for your help! > > Bests, > > Fatemeh Nouri > > > > > > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: