Hi. I have a working recent release of the ET (2019_03) that compiles & runs fine, but which fails when I try to build the associated utilities:
---------------------
make sim-utils
Building utilities for sim make[1]: *** No rule to make target '/nobackupp2/bjkelly1/codes/Cactus/exe/sim/RNS', needed by 'utils'. Stop. Makefile:872: recipe for target 'sim-utils' failed ---------------------
I'm left with about 50% of the utilities --- basically everything through "hdf5tobinary_slicer". But "hwloc-assembler" and all the other hwloc-related utilities haven't built.
I have the ET_2018_03 release on the same machine, and that builds both the primary executable *and* all the utilities with no issues, even though the compilation options are identical between the two.
Possibly relevant:
(1) I don't know what the RNS refers to, but I am including the thorn GSFC_GRMHD_Initial/RNSID in my configuration (both old and new).
(2) One difference between old and new configurations is that I'm not compiling CactusUtils/SystemTopology, as that gives me link-time errors with hwloc.
Bernard
-- ------------------------------------------------------------------ Bernard Kelly -- CRESST Assistant Research Scientist, NASA/GSFC Gravitational Astrophysics Laboratory --- Code 663
Phone: +1 (301) 286-7243 *** Fax: +1 (301) 286-2226 Web: http://science.gsfc.nasa.gov/sed/bio/bernard.j.kelly ORCID: orcid.org/0000-0002-3326-4454 ------------------------------------------------------------------
Hello Bernard,
I am not quite sure what could cause this. The RNS utility in the Einstein Toolkit is part of einsteininitialdata/Hydro_RNSID is your thorn the same or a older / modified version of that thorn?
I am not sure how SystemTopology itself could be responsible, however removing it from the thornlist may have triggered a CST run which may have uncovered a previously existing issue.
I would try the following:
1. try if "make sim-cleandeps" helps 2. if you have *moved* the RNSID thorn I would go for a full rebuild from scratch 3. if you have not moved it (and even if you have) I'd have a look at the thorns make.configuration.deps file and check if it hard-codes the name of the thorn or arrangement. Also check in make.configuration.defn for the names of the utilities (defn not deps this time).
Yours, Roland
Hi. I have a working recent release of the ET (2019_03) that compiles & runs fine, but which fails when I try to build the associated utilities:
make sim-utils
Building utilities for sim make[1]: *** No rule to make target '/nobackupp2/bjkelly1/codes/Cactus/exe/sim/RNS', needed by 'utils'. Stop. Makefile:872: recipe for target 'sim-utils' failed
I'm left with about 50% of the utilities --- basically everything through "hdf5tobinary_slicer". But "hwloc-assembler" and all the other hwloc-related utilities haven't built.
I have the ET_2018_03 release on the same machine, and that builds both the primary executable *and* all the utilities with no issues, even though the compilation options are identical between the two.
Possibly relevant:
(1) I don't know what the RNS refers to, but I am including the thorn GSFC_GRMHD_Initial/RNSID in my configuration (both old and new).
(2) One difference between old and new configurations is that I'm not compiling CactusUtils/SystemTopology, as that gives me link-time errors with hwloc.
Bernard
--
Bernard Kelly -- CRESST Assistant Research Scientist, NASA/GSFC Gravitational Astrophysics Laboratory --- Code 663
Phone: +1 (301) 286-7243 *** Fax: +1 (301) 286-2226 Web: http://science.gsfc.nasa.gov/sed/bio/bernard.j.kelly ORCID: orcid.org/0000-0002-3326-4454
Users mailing list Users@einsteintoolkit.org http://lists.einsteintoolkit.org/mailman/listinfo/users
Hi Roland. Thanks for the quick response.
You're right; that was a non-standard version of RNSID I made to remove the GRHydro dependence some time ago.
I've restored the original version, and included GRHydro in my Thornlist, while also running make sim-cleandeps. Compilation (without SsytemTopology) works, but now the make sim-utils fails when trying to build GRHydro's utilities:
------------
pfe25.bjkelly1 85> make sim-utils
Building utilities for sim
Compiling /nobackupp2/bjkelly1/codes/Cactus/arrangements/EinsteinEvolve/GRHydro/src/util/Riemann1d.f90
Preprocessing /nobackupp2/bjkelly1/codes/Cactus/arrangements/EinsteinEvolve/GRHydro/src/util/Riemann1d-main.c
Compiling /nobackupp2/bjkelly1/codes/Cactus/configs/sim/build/GRHydro/Riemann1d-main.c
Creating Riemann1d in /nobackupp2/bjkelly1/codes/Cactus/exe/sim from /nobackupp2/bjkelly1/codes/Cactus/configs/sim/build/GRHydro/Riemann1d.o
/usr/lib64/gcc/x86_64-suse-linux/4.8/../../../../x86_64-suse-linux/bin/ld: /nobackupp2/bjkelly1/codes/Cactus/configs/sim/build/GRHydro/Riemann1d-main.o: in function `main':
/nobackupp2/bjkelly1/codes/Cactus/configs/sim/build/GRHydro/Riemann1d-main.c:4: undefined reference to `__kmpc_begin'
/usr/lib64/gcc/x86_64-suse-linux/4.8/../../../../x86_64-suse-linux/bin/ld: /nobackupp2/bjkelly1/codes/Cactus/configs/sim/build/GRHydro/Riemann1d-main.c:6: undefined reference to `__kmpc_end'
/nobackupp2/bjkelly1/codes/Cactus/arrangements/EinsteinEvolve/GRHydro/src/make.configuration.deps:4: recipe for target '/nobackupp2/bjkelly1/codes/Cactus/exe/sim/Riemann1d' failed
make[1]: *** [/nobackupp2/bjkelly1/codes/Cactus/exe/sim/Riemann1d] Error 1
Makefile:872: recipe for target 'sim-utils' failed
make: *** [sim-utils] Error 2 -------------------
Interestingly, this new failure looks similar to something reported back in 2011 [ https://bitbucket.org/einsteintoolkit/tickets/issues/634 ], and then it was solved by "(programmatically) removing the -openmp flag from the utilities build command." It can't be the same issue, can it?
On Wed, 18 Sep 2019 at 12:31, Haas, Roland rhaas@illinois.edu wrote:
Hello Bernard,
I am not quite sure what could cause this. The RNS utility in the Einstein Toolkit is part of einsteininitialdata/Hydro_RNSID is your thorn the same or a older / modified version of that thorn?
I am not sure how SystemTopology itself could be responsible, however removing it from the thornlist may have triggered a CST run which may have uncovered a previously existing issue.
I would try the following:
- try if "make sim-cleandeps" helps
- if you have *moved* the RNSID thorn I would go for a full rebuild
from scratch 3. if you have not moved it (and even if you have) I'd have a look at the thorns make.configuration.deps file and check if it hard-codes the name of the thorn or arrangement. Also check in make.configuration.defn for the names of the utilities (defn not deps this time).
Yours, Roland
Hi. I have a working recent release of the ET (2019_03) that compiles & runs fine, but which fails when I try to build the associated utilities:
make sim-utils
Building utilities for sim make[1]: *** No rule to make target '/nobackupp2/bjkelly1/codes/Cactus/exe/sim/RNS', needed by 'utils'. Stop. Makefile:872: recipe for target 'sim-utils' failed
I'm left with about 50% of the utilities --- basically everything through "hdf5tobinary_slicer". But "hwloc-assembler" and all the other hwloc-related utilities haven't built.
I have the ET_2018_03 release on the same machine, and that builds both the primary executable *and* all the utilities with no issues, even though the compilation options are identical between the two.
Possibly relevant:
(1) I don't know what the RNS refers to, but I am including the thorn GSFC_GRMHD_Initial/RNSID in my configuration (both old and new).
(2) One difference between old and new configurations is that I'm not compiling CactusUtils/SystemTopology, as that gives me link-time errors with hwloc.
Bernard
--
Bernard Kelly -- CRESST Assistant Research Scientist, NASA/GSFC Gravitational Astrophysics Laboratory --- Code 663
Phone: +1 (301) 286-7243 *** Fax: +1 (301) 286-2226 Web: http://science.gsfc.nasa.gov/sed/bio/bernard.j.kelly ORCID: orcid.org/0000-0002-3326-4454
Users mailing list Users@einsteintoolkit.org http://lists.einsteintoolkit.org/mailman/listinfo/users
-- 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 .
-- ------------------------------------------------------------------ Bernard Kelly -- CRESST Assistant Research Scientist, NASA/GSFC Gravitational Astrophysics Laboratory --- Code 663
Phone: +1 (301) 286-7243 *** Fax: +1 (301) 286-2226 Web: http://science.gsfc.nasa.gov/sed/bio/bernard.j.kelly ORCID: orcid.org/0000-0002-3326-4454 ------------------------------------------------------------------
Hello Bernard,
You're right; that was a non-standard version of RNSID I made to remove the GRHydro dependence some time ago.
Ah ok. In theory this dependence should now also have been removed from the vanilla version (there should be a ticket about this).
Interestingly, this new failure looks similar to something reported back in 2011 [ https://bitbucket.org/einsteintoolkit/tickets/issues/634 ], and then it was solved by "(programmatically) removing the -openmp flag from the utilities build command." It can't be the same issue, can it?
It does sound like the same issue to me as the __kmpc stuff is the Intel compiler's OpenMP code.
The other option may be to make sure that you do set LDFLAGS to -openmp. Unfortunately there is no LD_OPENMP_FLAGS (which is really what we'd want).
The original fix for https://bitbucket.org/einsteintoolkit/tickets/issues/634 is in https://bitbucket.org/einsteintoolkit/einsteinevolve/commits/06502dc04b5592b... and taht fix (the $(filter-out ...) call) is present also for the current code for both the C and the F90 bit of the (horrible) makefile.
Did you enable OpenMP "properly" by setting:
CFLAGS = -g C_OPENMP_FLAGS = -openmp OPENMP = yes
or "manually" by setting
CFLAGS = -g -openmp
? If you were to send me your option list I could try and see if this is another corner case.
Yours, Roland
Bernard
As a general work-around for make: You can use the option "-k" ("keep going") to make. This makes make continue after errors. Of course, the thing it couldn't build won't be build, and other things that depend on the broken one also won't be built, but other independent targets will still be built. In your case, it is likely that all other utilities would have been built except RNS.
-erik
On Wed, Sep 18, 2019 at 12:14 PM Bernard Kelly physicsbeany@gmail.com wrote:
Hi. I have a working recent release of the ET (2019_03) that compiles & runs fine, but which fails when I try to build the associated utilities:
make sim-utils
Building utilities for sim make[1]: *** No rule to make target '/nobackupp2/bjkelly1/codes/Cactus/exe/sim/RNS', needed by 'utils'. Stop. Makefile:872: recipe for target 'sim-utils' failed
I'm left with about 50% of the utilities --- basically everything through "hdf5tobinary_slicer". But "hwloc-assembler" and all the other hwloc-related utilities haven't built.
I have the ET_2018_03 release on the same machine, and that builds both the primary executable *and* all the utilities with no issues, even though the compilation options are identical between the two.
Possibly relevant:
(1) I don't know what the RNS refers to, but I am including the thorn GSFC_GRMHD_Initial/RNSID in my configuration (both old and new).
(2) One difference between old and new configurations is that I'm not compiling CactusUtils/SystemTopology, as that gives me link-time errors with hwloc.
Bernard
--
Bernard Kelly -- CRESST Assistant Research Scientist, NASA/GSFC Gravitational Astrophysics Laboratory --- Code 663
Phone: +1 (301) 286-7243 *** Fax: +1 (301) 286-2226 Web: http://science.gsfc.nasa.gov/sed/bio/bernard.j.kelly ORCID: orcid.org/0000-0002-3326-4454
Users mailing list Users@einsteintoolkit.org http://lists.einsteintoolkit.org/mailman/listinfo/users
users@lists.einsteintoolkit.org
-
Bernard Kelly -
Erik Schnetter -
Haas, Roland