Hi all.
I recently checked out ETK Maxwell on the machine XSEDE machine Kraken, and am having trouble compiling and running a simple test case. The problem is with LSUThorns/Vectors/src/test.cc, where the "signbit" function is (apparently) undefined. No doubt the problem recurs with later source files, but I can't get past this one without abandoning Vectors and hence all of Carpet.
Now I can compile a "hello world" program in C invoking signbit.cc without a problem, as long as I include <math.h>, so presumably the ETK process is looking in the wrong location for this library or its headers.
Since Kraken is a "known" machine in ETK's simfactory, and lots of Numerical Relativity groups must have used it during the recently expired "NR-AR" allocation, I assume the problem's at my end. Any ideas?
Thanks,
Bernard
Some details:
(1) I initially used the simfactory "build" mechanism, but I have this problem with a straightforward Cactus "make" as well.
(2) Here's a list of my loaded modules on Kraken. I'm using the PGI compilers (item 18 below):
1) modules/3.1.6.5 2) torque/2.4.14 3) moab/5.4.3.s16991 4) /opt/cray/xt-asyncpe/default/modulefiles/xtpe-istanbul 5) tgusage/3.0-r2 6) altd/1.0 7) DefApps 8) xtpe-target-cnl 9) xt-service/2.2.74 10) xt-os/2.2.74 11) xt-boot/2.2.74 12) xt-lustre-ss/2.2.74_1.6.5 13) cray/job/1.5.5-0.1_2.0202.21413.56.7 14) cray/csa/3.0.0-1_2.0202.21426.77.7 15) cray/account/1.0.0-2.0202.19482.49.18 16) cray/projdb/1.0.0-1.0202.19483.52.1 17) Base-opts/2.2.74 18) pgi/11.4.0 19) xt-libsci/10.5.02 20) pmi/2.1.4-1.0000.8596.15.1.ss 21) xt-mpt/5.2.3 22) xt-pe/2.2.74 23) xt-asyncpe/4.9 24) PrgEnv-pgi/2.2.74 25) cray/MySQL/5.0.64-1.0202.2899.21.1 26) git/1.7.4.2 27) python/2.6.4 28) mercurial/1.6.4 29) subversion/1.6.9 30) hdf5-parallel/1.6.10
---------------------------------------------------------------------------
Bernard
test.cc is just a self-test. You can try commenting out the respective code (or the whole routine), and see where this gets you.
Carpet (which may also use signbit) has a different, more complex logic to handle various levels of C++ compliance, and may actually still do the right thing.
-erik
On Mon, Feb 6, 2012 at 10:53 PM, Kelly, Bernard J. (GSFC-660.0)[UNIVERSITY OF MARYLAND BALTIMORE COUNTY] bernard.j.kelly@nasa.gov wrote:
Hi all.
I recently checked out ETK Maxwell on the machine XSEDE machine Kraken, and am having trouble compiling and running a simple test case. The problem is with LSUThorns/Vectors/src/test.cc, where the "signbit" function is (apparently) undefined. No doubt the problem recurs with later source files, but I can't get past this one without abandoning Vectors and hence all of Carpet.
Now I can compile a "hello world" program in C invoking signbit.cc without a problem, as long as I include <math.h>, so presumably the ETK process is looking in the wrong location for this library or its headers.
Since Kraken is a "known" machine in ETK's simfactory, and lots of Numerical Relativity groups must have used it during the recently expired "NR-AR" allocation, I assume the problem's at my end. Any ideas?
Thanks,
Bernard
Some details:
(1) I initially used the simfactory "build" mechanism, but I have this problem with a straightforward Cactus "make" as well.
(2) Here's a list of my loaded modules on Kraken. I'm using the PGI compilers (item 18 below):
- modules/3.1.6.5
- torque/2.4.14
- moab/5.4.3.s16991
- /opt/cray/xt-asyncpe/default/modulefiles/xtpe-istanbul
- tgusage/3.0-r2
- altd/1.0
- DefApps
- xtpe-target-cnl
- xt-service/2.2.74
10) xt-os/2.2.74 11) xt-boot/2.2.74 12) xt-lustre-ss/2.2.74_1.6.5 13) cray/job/1.5.5-0.1_2.0202.21413.56.7 14) cray/csa/3.0.0-1_2.0202.21426.77.7 15) cray/account/1.0.0-2.0202.19482.49.18 16) cray/projdb/1.0.0-1.0202.19483.52.1 17) Base-opts/2.2.74 18) pgi/11.4.0 19) xt-libsci/10.5.02 20) pmi/2.1.4-1.0000.8596.15.1.ss 21) xt-mpt/5.2.3 22) xt-pe/2.2.74 23) xt-asyncpe/4.9 24) PrgEnv-pgi/2.2.74 25) cray/MySQL/5.0.64-1.0202.2899.21.1 26) git/1.7.4.2 27) python/2.6.4 28) mercurial/1.6.4 29) subversion/1.6.9 30) hdf5-parallel/1.6.10
-- Bernard Kelly -- CRESST Research Associate, NASA/GSFC
Phone: +1 (301) 286-7243 E-Mail: bernard.j.kelly@nasa.gov Web: http://science.gsfc.nasa.gov/sed/index.cfm?fuseAction=people.jumpBio&iph... bookid=13052
--
Users mailing list Users@einsteintoolkit.org http://lists.einsteintoolkit.org/mailman/listinfo/users
Hi Erik.
Thanks for the advice. I commented out all references to "signbit", and to "kifpos" lower down, and it now gets through the Vectors thorn. I'm now hitting an issue with an omp pragma in CarpetLib, but that's a separate problem.
BTW, I just tried to create a ticket (about the signbit issue) on trac.einsteintoolkit.org, but ...
"Submission rejected as potential spam"
I thought it was the list of modules I put in, but even without them it gets blocked. Also, the TRAC system doesn't list the Maxwell release (ET_2011_10) as a possible "version", which makes it hard to give an accurate report.
Bernard
---------------------------------------------------------------------------
I believe that kraken has just undergone a software upgrade. Maybe the problem was introduced then? Maxwell definitely compiled on kraken when it was released.
Bernard
The PGI compiler is often picky about what C++/OpenMP constructs it accepts. Do you want to try the Intel compiler instead? I've been using it successfully on Kraken.
-erik
On Tue, Feb 7, 2012 at 10:54 AM, Kelly, Bernard J. (GSFC-660.0)[UNIVERSITY OF MARYLAND BALTIMORE COUNTY] bernard.j.kelly@nasa.gov wrote:
Hi Erik.
Thanks for the advice. I commented out all references to "signbit", and to "kifpos" lower down, and it now gets through the Vectors thorn. I'm now hitting an issue with an omp pragma in CarpetLib, but that's a separate problem.
BTW, I just tried to create a ticket (about the signbit issue) on trac.einsteintoolkit.org, but ...
"Submission rejected as potential spam"
I thought it was the list of modules I put in, but even without them it gets blocked. Also, the TRAC system doesn't list the Maxwell release (ET_2011_10) as a possible "version", which makes it hard to give an accurate report.
Bernard
-- Bernard Kelly -- CRESST Research Associate, NASA/GSFC
Phone: +1 (301) 286-7243 E-Mail: bernard.j.kelly@nasa.gov Web: http://science.gsfc.nasa.gov/sed/index.cfm?fuseAction=people.jumpBio&iph... bookid=13052
--
On 2/6/12 11:17 PM, "Erik Schnetter" schnetter@cct.lsu.edu wrote:
Bernard
test.cc is just a self-test. You can try commenting out the respective code (or the whole routine), and see where this gets you.
Carpet (which may also use signbit) has a different, more complex logic to handle various levels of C++ compliance, and may actually still do the right thing.
-erik
On Mon, Feb 6, 2012 at 10:53 PM, Kelly, Bernard J. (GSFC-660.0)[UNIVERSITY OF MARYLAND BALTIMORE COUNTY] bernard.j.kelly@nasa.gov wrote:
Hi all.
I recently checked out ETK Maxwell on the machine XSEDE machine Kraken, and am having trouble compiling and running a simple test case. The problem is with LSUThorns/Vectors/src/test.cc, where the "signbit" function is (apparently) undefined. No doubt the problem recurs with later source files, but I can't get past this one without abandoning Vectors and hence all of Carpet.
Now I can compile a "hello world" program in C invoking signbit.cc without a problem, as long as I include <math.h>, so presumably the ETK process is looking in the wrong location for this library or its headers.
Since Kraken is a "known" machine in ETK's simfactory, and lots of Numerical Relativity groups must have used it during the recently expired "NR-AR" allocation, I assume the problem's at my end. Any ideas?
Thanks,
Bernard
Some details:
(1) I initially used the simfactory "build" mechanism, but I have this problem with a straightforward Cactus "make" as well.
(2) Here's a list of my loaded modules on Kraken. I'm using the PGI compilers (item 18 below):
- modules/3.1.6.5
- torque/2.4.14
- moab/5.4.3.s16991
- /opt/cray/xt-asyncpe/default/modulefiles/xtpe-istanbul
- tgusage/3.0-r2
- altd/1.0
- DefApps
- xtpe-target-cnl
- xt-service/2.2.74
10) xt-os/2.2.74 11) xt-boot/2.2.74 12) xt-lustre-ss/2.2.74_1.6.5 13) cray/job/1.5.5-0.1_2.0202.21413.56.7 14) cray/csa/3.0.0-1_2.0202.21426.77.7 15) cray/account/1.0.0-2.0202.19482.49.18 16) cray/projdb/1.0.0-1.0202.19483.52.1 17) Base-opts/2.2.74 18) pgi/11.4.0 19) xt-libsci/10.5.02 20) pmi/2.1.4-1.0000.8596.15.1.ss 21) xt-mpt/5.2.3 22) xt-pe/2.2.74 23) xt-asyncpe/4.9 24) PrgEnv-pgi/2.2.74 25) cray/MySQL/5.0.64-1.0202.2899.21.1 26) git/1.7.4.2 27) python/2.6.4 28) mercurial/1.6.4 29) subversion/1.6.9 30) hdf5-parallel/1.6.10
--
Bernard Kelly -- CRESST Research Associate, NASA/GSFC
Phone: +1 (301) 286-7243 E-Mail: bernard.j.kelly@nasa.gov Web:
http://science.gsfc.nasa.gov/sed/index.cfm?fuseAction=people.jumpBio&iph... ne bookid=13052
--
Users mailing list Users@einsteintoolkit.org http://lists.einsteintoolkit.org/mailman/listinfo/users
-- Erik Schnetter schnetter@cct.lsu.edu http://www.cct.lsu.edu/~eschnett/
That might be an idea. Do you have a feeling for the relative efficiency of PGI vs Intel on this machine?
I sent the NICS people a ticket about the later compilation issues (who knows; perhaps they're coming from the same source as the signbit problem).
Bernard
P.S. Any idea why my ETK TRAC ticket wasn't accepted? I don't have a login (I think ...), so I was submitting as "bernard.j.kelly@nasa.gov".
On 2/7/12 11:44 AM, "Erik Schnetter" schnetter@cct.lsu.edu wrote:
Bernard
The PGI compiler is often picky about what C++/OpenMP constructs it accepts. Do you want to try the Intel compiler instead? I've been using it successfully on Kraken.
-erik
On Tue, Feb 7, 2012 at 10:54 AM, Kelly, Bernard J. (GSFC-660.0)[UNIVERSITY OF MARYLAND BALTIMORE COUNTY] bernard.j.kelly@nasa.gov wrote:
Hi Erik.
Thanks for the advice. I commented out all references to "signbit", and to "kifpos" lower down, and it now gets through the Vectors thorn. I'm now hitting an issue with an omp pragma in CarpetLib, but that's a separate problem.
BTW, I just tried to create a ticket (about the signbit issue) on trac.einsteintoolkit.org, but ...
"Submission rejected as potential spam"
I thought it was the list of modules I put in, but even without them it gets blocked. Also, the TRAC system doesn't list the Maxwell release (ET_2011_10) as a possible "version", which makes it hard to give an accurate report.
Bernard
--
Bernard Kelly -- CRESST Research Associate, NASA/GSFC
Phone: +1 (301) 286-7243 E-Mail: bernard.j.kelly@nasa.gov Web:
http://science.gsfc.nasa.gov/sed/index.cfm?fuseAction=people.jumpBio&iph... ne bookid=13052
--
On 2/6/12 11:17 PM, "Erik Schnetter" schnetter@cct.lsu.edu wrote:
Bernard
test.cc is just a self-test. You can try commenting out the respective code (or the whole routine), and see where this gets you.
Carpet (which may also use signbit) has a different, more complex logic to handle various levels of C++ compliance, and may actually still do the right thing.
-erik
On Mon, Feb 6, 2012 at 10:53 PM, Kelly, Bernard J. (GSFC-660.0)[UNIVERSITY OF MARYLAND BALTIMORE COUNTY] bernard.j.kelly@nasa.gov wrote:
Hi all.
I recently checked out ETK Maxwell on the machine XSEDE machine Kraken, and am having trouble compiling and running a simple test case. The problem is with LSUThorns/Vectors/src/test.cc, where the "signbit" function is (apparently) undefined. No doubt the problem recurs with later source files, but I can't get past this one without abandoning Vectors and hence all of Carpet.
Now I can compile a "hello world" program in C invoking signbit.cc without a problem, as long as I include <math.h>, so presumably the ETK process is looking in the wrong location for this library or its headers.
Since Kraken is a "known" machine in ETK's simfactory, and lots of Numerical Relativity groups must have used it during the recently expired "NR-AR" allocation, I assume the problem's at my end. Any ideas?
Thanks,
Bernard
Some details:
(1) I initially used the simfactory "build" mechanism, but I have this problem with a straightforward Cactus "make" as well.
(2) Here's a list of my loaded modules on Kraken. I'm using the PGI compilers (item 18 below):
- modules/3.1.6.5
- torque/2.4.14
- moab/5.4.3.s16991
- /opt/cray/xt-asyncpe/default/modulefiles/xtpe-istanbul
- tgusage/3.0-r2
- altd/1.0
- DefApps
- xtpe-target-cnl
- xt-service/2.2.74
- xt-os/2.2.74
- xt-boot/2.2.74
- xt-lustre-ss/2.2.74_1.6.5
- cray/job/1.5.5-0.1_2.0202.21413.56.7
- cray/csa/3.0.0-1_2.0202.21426.77.7
- cray/account/1.0.0-2.0202.19482.49.18
- cray/projdb/1.0.0-1.0202.19483.52.1
- Base-opts/2.2.74
- pgi/11.4.0
- xt-libsci/10.5.02
- pmi/2.1.4-1.0000.8596.15.1.ss
- xt-mpt/5.2.3
- xt-pe/2.2.74
- xt-asyncpe/4.9
- PrgEnv-pgi/2.2.74
- cray/MySQL/5.0.64-1.0202.2899.21.1
- git/1.7.4.2
- python/2.6.4
- mercurial/1.6.4
- subversion/1.6.9
- hdf5-parallel/1.6.10
--
-- Bernard Kelly -- CRESST Research Associate, NASA/GSFC
Phone: +1 (301) 286-7243 E-Mail: bernard.j.kelly@nasa.gov Web:
http://science.gsfc.nasa.gov/sed/index.cfm?fuseAction=people.jumpBio&ip ho ne bookid=13052
--
--
Users mailing list Users@einsteintoolkit.org http://lists.einsteintoolkit.org/mailman/listinfo/users
-- Erik Schnetter schnetter@cct.lsu.edu http://www.cct.lsu.edu/~eschnett/
-- Erik Schnetter schnetter@cct.lsu.edu http://www.cct.lsu.edu/~eschnett/
On Tue, Feb 7, 2012 at 11:50 AM, Kelly, Bernard J. (GSFC-660.0)[UNIVERSITY OF MARYLAND BALTIMORE COUNTY] bernard.j.kelly@nasa.gov wrote:
That might be an idea. Do you have a feeling for the relative efficiency of PGI vs Intel on this machine?
There is a table near the bottom of https://docs.einsteintoolkit.org/et-docs/Vectorisation. Hopper and Kraken had very similar configurations when this table was made.
At this point, vectorisation did not work with PGI, leading to 439.572s (PGI) vs. 272.993s (Intel) for the run time for this benchmark.
Of course, this is a benchmark, and your numbers will vary.
-erik
I sent the NICS people a ticket about the later compilation issues (who knows; perhaps they're coming from the same source as the signbit problem).
Bernard
P.S. Any idea why my ETK TRAC ticket wasn't accepted? I don't have a login (I think ...), so I was submitting as "bernard.j.kelly@nasa.gov".
On 2/7/12 11:44 AM, "Erik Schnetter" schnetter@cct.lsu.edu wrote:
Bernard
The PGI compiler is often picky about what C++/OpenMP constructs it accepts. Do you want to try the Intel compiler instead? I've been using it successfully on Kraken.
-erik
On Tue, Feb 7, 2012 at 10:54 AM, Kelly, Bernard J. (GSFC-660.0)[UNIVERSITY OF MARYLAND BALTIMORE COUNTY] bernard.j.kelly@nasa.gov wrote:
Hi Erik.
Thanks for the advice. I commented out all references to "signbit", and to "kifpos" lower down, and it now gets through the Vectors thorn. I'm now hitting an issue with an omp pragma in CarpetLib, but that's a separate problem.
BTW, I just tried to create a ticket (about the signbit issue) on trac.einsteintoolkit.org, but ...
"Submission rejected as potential spam"
I thought it was the list of modules I put in, but even without them it gets blocked. Also, the TRAC system doesn't list the Maxwell release (ET_2011_10) as a possible "version", which makes it hard to give an accurate report.
Bernard
--
Bernard Kelly -- CRESST Research Associate, NASA/GSFC
Phone: +1 (301) 286-7243 E-Mail: bernard.j.kelly@nasa.gov Web:
http://science.gsfc.nasa.gov/sed/index.cfm?fuseAction=people.jumpBio&iph... ne bookid=13052
--
On 2/6/12 11:17 PM, "Erik Schnetter" schnetter@cct.lsu.edu wrote:
Bernard
test.cc is just a self-test. You can try commenting out the respective code (or the whole routine), and see where this gets you.
Carpet (which may also use signbit) has a different, more complex logic to handle various levels of C++ compliance, and may actually still do the right thing.
-erik
On Mon, Feb 6, 2012 at 10:53 PM, Kelly, Bernard J. (GSFC-660.0)[UNIVERSITY OF MARYLAND BALTIMORE COUNTY] bernard.j.kelly@nasa.gov wrote:
Hi all.
I recently checked out ETK Maxwell on the machine XSEDE machine Kraken, and am having trouble compiling and running a simple test case. The problem is with LSUThorns/Vectors/src/test.cc, where the "signbit" function is (apparently) undefined. No doubt the problem recurs with later source files, but I can't get past this one without abandoning Vectors and hence all of Carpet.
Now I can compile a "hello world" program in C invoking signbit.cc without a problem, as long as I include <math.h>, so presumably the ETK process is looking in the wrong location for this library or its headers.
Since Kraken is a "known" machine in ETK's simfactory, and lots of Numerical Relativity groups must have used it during the recently expired "NR-AR" allocation, I assume the problem's at my end. Any ideas?
Thanks,
Bernard
Some details:
(1) I initially used the simfactory "build" mechanism, but I have this problem with a straightforward Cactus "make" as well.
(2) Here's a list of my loaded modules on Kraken. I'm using the PGI compilers (item 18 below):
- modules/3.1.6.5
- torque/2.4.14
- moab/5.4.3.s16991
- /opt/cray/xt-asyncpe/default/modulefiles/xtpe-istanbul
- tgusage/3.0-r2
- altd/1.0
- DefApps
- xtpe-target-cnl
- xt-service/2.2.74
10) xt-os/2.2.74 11) xt-boot/2.2.74 12) xt-lustre-ss/2.2.74_1.6.5 13) cray/job/1.5.5-0.1_2.0202.21413.56.7 14) cray/csa/3.0.0-1_2.0202.21426.77.7 15) cray/account/1.0.0-2.0202.19482.49.18 16) cray/projdb/1.0.0-1.0202.19483.52.1 17) Base-opts/2.2.74 18) pgi/11.4.0 19) xt-libsci/10.5.02 20) pmi/2.1.4-1.0000.8596.15.1.ss 21) xt-mpt/5.2.3 22) xt-pe/2.2.74 23) xt-asyncpe/4.9 24) PrgEnv-pgi/2.2.74 25) cray/MySQL/5.0.64-1.0202.2899.21.1 26) git/1.7.4.2 27) python/2.6.4 28) mercurial/1.6.4 29) subversion/1.6.9 30) hdf5-parallel/1.6.10
--
-- Bernard Kelly -- CRESST Research Associate, NASA/GSFC
Phone: +1 (301) 286-7243 E-Mail: bernard.j.kelly@nasa.gov Web:
http://science.gsfc.nasa.gov/sed/index.cfm?fuseAction=people.jumpBio&ip ho ne bookid=13052
--
--
Users mailing list Users@einsteintoolkit.org http://lists.einsteintoolkit.org/mailman/listinfo/users
-- Erik Schnetter schnetter@cct.lsu.edu http://www.cct.lsu.edu/~eschnett/
-- Erik Schnetter schnetter@cct.lsu.edu http://www.cct.lsu.edu/~eschnett/
On 7 Feb 2012, at 17:44, Erik Schnetter wrote:
Bernard
The PGI compiler is often picky about what C++/OpenMP constructs it accepts. Do you want to try the Intel compiler instead? I've been using it successfully on Kraken.
Hi Bernard,
Are you compiling using SimFactory's optionlist? If you use "sim build", as you mentioned, then it will by default pick up kraken-intel.cfg and will use the Intel compiler.
The build should not depend on the modules you have loaded, as SimFactory sets all the variables etc. itself. When you tried the Cactus make mechanism, what optionlist were you giving it? Cactus auto-detection is unlikely to work out of the box for the entire ET.
Building using SimFactory was definitely working on Kraken when Maxwell was released (the release test status results are still available at http://einsteintoolkit.org/release-info/parse_testsuite_results.php - note that these are not run regularly, only around the time of a release).
My previous email about the Kraken software upgrade was wrong - they have postponed the upgrade. However, I have not compiled on Kraken for a while, so it may be that something else changed there.
-erik
On Tue, Feb 7, 2012 at 10:54 AM, Kelly, Bernard J. (GSFC-660.0)[UNIVERSITY OF MARYLAND BALTIMORE COUNTY] bernard.j.kelly@nasa.gov wrote:
Hi Erik.
Thanks for the advice. I commented out all references to "signbit", and to "kifpos" lower down, and it now gets through the Vectors thorn. I'm now hitting an issue with an omp pragma in CarpetLib, but that's a separate problem.
BTW, I just tried to create a ticket (about the signbit issue) on trac.einsteintoolkit.org, but ...
"Submission rejected as potential spam"
I thought it was the list of modules I put in, but even without them it gets blocked. Also, the TRAC system doesn't list the Maxwell release (ET_2011_10) as a possible "version", which makes it hard to give an accurate report.
Bernard
-- Bernard Kelly -- CRESST Research Associate, NASA/GSFC
Phone: +1 (301) 286-7243 E-Mail: bernard.j.kelly@nasa.gov Web: http://science.gsfc.nasa.gov/sed/index.cfm?fuseAction=people.jumpBio&iph... bookid=13052
--
On 2/6/12 11:17 PM, "Erik Schnetter" schnetter@cct.lsu.edu wrote:
Bernard
test.cc is just a self-test. You can try commenting out the respective code (or the whole routine), and see where this gets you.
Carpet (which may also use signbit) has a different, more complex logic to handle various levels of C++ compliance, and may actually still do the right thing.
-erik
On Mon, Feb 6, 2012 at 10:53 PM, Kelly, Bernard J. (GSFC-660.0)[UNIVERSITY OF MARYLAND BALTIMORE COUNTY] bernard.j.kelly@nasa.gov wrote:
Hi all.
I recently checked out ETK Maxwell on the machine XSEDE machine Kraken, and am having trouble compiling and running a simple test case. The problem is with LSUThorns/Vectors/src/test.cc, where the "signbit" function is (apparently) undefined. No doubt the problem recurs with later source files, but I can't get past this one without abandoning Vectors and hence all of Carpet.
Now I can compile a "hello world" program in C invoking signbit.cc without a problem, as long as I include <math.h>, so presumably the ETK process is looking in the wrong location for this library or its headers.
Since Kraken is a "known" machine in ETK's simfactory, and lots of Numerical Relativity groups must have used it during the recently expired "NR-AR" allocation, I assume the problem's at my end. Any ideas?
Thanks,
Bernard
Some details:
(1) I initially used the simfactory "build" mechanism, but I have this problem with a straightforward Cactus "make" as well.
(2) Here's a list of my loaded modules on Kraken. I'm using the PGI compilers (item 18 below):
- modules/3.1.6.5
- torque/2.4.14
- moab/5.4.3.s16991
- /opt/cray/xt-asyncpe/default/modulefiles/xtpe-istanbul
- tgusage/3.0-r2
- altd/1.0
- DefApps
- xtpe-target-cnl
- xt-service/2.2.74
- xt-os/2.2.74
- xt-boot/2.2.74
- xt-lustre-ss/2.2.74_1.6.5
- cray/job/1.5.5-0.1_2.0202.21413.56.7
- cray/csa/3.0.0-1_2.0202.21426.77.7
- cray/account/1.0.0-2.0202.19482.49.18
- cray/projdb/1.0.0-1.0202.19483.52.1
- Base-opts/2.2.74
- pgi/11.4.0
- xt-libsci/10.5.02
- pmi/2.1.4-1.0000.8596.15.1.ss
- xt-mpt/5.2.3
- xt-pe/2.2.74
- xt-asyncpe/4.9
- PrgEnv-pgi/2.2.74
- cray/MySQL/5.0.64-1.0202.2899.21.1
- git/1.7.4.2
- python/2.6.4
- mercurial/1.6.4
- subversion/1.6.9
- hdf5-parallel/1.6.10
--
Bernard Kelly -- CRESST Research Associate, NASA/GSFC
Phone: +1 (301) 286-7243 E-Mail: bernard.j.kelly@nasa.gov Web:
http://science.gsfc.nasa.gov/sed/index.cfm?fuseAction=people.jumpBio&iph... ne bookid=13052
--
Users mailing list Users@einsteintoolkit.org http://lists.einsteintoolkit.org/mailman/listinfo/users
-- Erik Schnetter schnetter@cct.lsu.edu http://www.cct.lsu.edu/~eschnett/
-- Erik Schnetter schnetter@cct.lsu.edu http://www.cct.lsu.edu/~eschnett/ _______________________________________________ Users mailing list Users@einsteintoolkit.org http://lists.einsteintoolkit.org/mailman/listinfo/users
On Tue, Feb 7, 2012 at 6:59 PM, Ian Hinder ian.hinder@aei.mpg.de wrote:
Are you compiling using SimFactory's optionlist? If you use "sim build", as you mentioned, then it will by default pick up kraken-intel.cfg and will use the Intel compiler.
The build should not depend on the modules you have loaded, as SimFactory sets all the variables etc. itself. When you tried the Cactus make mechanism, what optionlist were you giving it? Cactus auto-detection is unlikely to work out of the box for the entire ET.
Building using SimFactory was definitely working on Kraken when Maxwell was released (the release test status results are still available at http://einsteintoolkit.org/release-info/parse_testsuite_results.php - note that these are not run regularly, only around the time of a release).
I was able to build on Kraken today using SimFactory with the Maxwell release. I didn't encounter any problems with either Vectors or Carpet. All I did was get the Maxwell release, add my defs.local.ini to SimFactory and run 'sim build'.
Are you sure you're using a clean checkout of the release? Could there be some local changes causing problems?
As Ian says, it shouldn't matter but FWIW my loaded modules are: Currently Loaded Modulefiles: 1) modules/3.1.6.5 2) torque/2.4.14 3) moab/5.4.3.s16991 4) /opt/cray/xt-asyncpe/default/modulefiles/xtpe-istanbul 5) tgusage/3.0-r2 6) altd/1.0 7) DefApps 8) xtpe-target-cnl 9) xt-service/2.2.74 10) xt-os/2.2.74 11) xt-boot/2.2.74 12) xt-lustre-ss/2.2.74_1.6.5 13) cray/job/1.5.5-0.1_2.0202.21413.56.7 14) cray/csa/3.0.0-1_2.0202.21426.77.7 15) cray/account/1.0.0-2.0202.19482.49.18 16) cray/projdb/1.0.0-1.0202.19483.52.1 17) Base-opts/2.2.74 18) pgi/11.4.0 19) xt-libsci/10.5.02 20) pmi/2.1.4-1.0000.8596.15.1.ss 21) xt-mpt/5.2.3 22) xt-pe/2.2.74 23) xt-asyncpe/4.9 24) PrgEnv-pgi/2.2.74 25) cray/MySQL/5.0.64-1.0202.2899.21.1
Barry
Hi Barry, Ian, Erik.
Problem solved. It wasn't my codebase or my loaded modules, but a set of legacy environment variables I was setting in my .bashrc. When I cleared that out and recompiled from scratch, the problems went away. I've submitted the "static_tov" test now.
Thanks for the help,
Bernard
From: Barry Wardell <barry.wardell@gmail.commailto:barry.wardell@gmail.com> Date: Tue, 7 Feb 2012 13:53:28 -0600 To: Ian Hinder <ian.hinder@aei.mpg.demailto:ian.hinder@aei.mpg.de> Cc: "users@einsteintoolkit.orgmailto:users@einsteintoolkit.org" <users@einsteintoolkit.orgmailto:users@einsteintoolkit.org> Subject: Re: [Users] "signbit" not defined during compilation of ETK on XSEDE:Kraken?
On Tue, Feb 7, 2012 at 6:59 PM, Ian Hinder <ian.hinder@aei.mpg.demailto:ian.hinder@aei.mpg.de> wrote: Are you compiling using SimFactory's optionlist? If you use "sim build", as you mentioned, then it will by default pick up kraken-intel.cfg and will use the Intel compiler.
The build should not depend on the modules you have loaded, as SimFactory sets all the variables etc. itself. When you tried the Cactus make mechanism, what optionlist were you giving it? Cactus auto-detection is unlikely to work out of the box for the entire ET.
Building using SimFactory was definitely working on Kraken when Maxwell was released (the release test status results are still available at http://einsteintoolkit.org/release-info/parse_testsuite_results.php - note that these are not run regularly, only around the time of a release).
I was able to build on Kraken today using SimFactory with the Maxwell release. I didn't encounter any problems with either Vectors or Carpet. All I did was get the Maxwell release, add my defs.local.ini to SimFactory and run 'sim build'.
Are you sure you're using a clean checkout of the release? Could there be some local changes causing problems?
As Ian says, it shouldn't matter but FWIW my loaded modules are: Currently Loaded Modulefiles: 1) modules/3.1.6.5http://3.1.6.5 2) torque/2.4.14 3) moab/5.4.3.s16991 4) /opt/cray/xt-asyncpe/default/modulefiles/xtpe-istanbul 5) tgusage/3.0-r2 6) altd/1.0 7) DefApps 8) xtpe-target-cnl 9) xt-service/2.2.74 10) xt-os/2.2.74 11) xt-boot/2.2.74 12) xt-lustre-ss/2.2.74_1.6.5 13) cray/job/1.5.5-0.1_2.0202.21413.56.7 14) cray/csa/3.0.0-1_2.0202.21426.77.7 15) cray/account/1.0.0-2.0202.19482.49.18 16) cray/projdb/1.0.0-1.0202.19483.52.1 17) Base-opts/2.2.74 18) pgi/11.4.0 19) xt-libsci/10.5.02 20) pmi/2.1.4-1.0000.8596.15.1.ss 21) xt-mpt/5.2.3 22) xt-pe/2.2.74 23) xt-asyncpe/4.9 24) PrgEnv-pgi/2.2.74 25) cray/MySQL/5.0.64-1.0202.2899.21.1
Barry
users@lists.einsteintoolkit.org
-
Barry Wardell -
Erik Schnetter -
Ian Hinder -
Kelly, Bernard J. (GSFC-660.0)[UNIVERSITY OF MARYLAND BALTIMORE COUNTY]