Trac March 2012

trac@lists.einsteintoolkit.org

1 participants
156 discussions

[Einstein Toolkit] #708: Cannot submit on Surveyor
by Einstein Toolkit 10 Aug '12

10 Aug '12

#708: Cannot submit on Surveyor ------------------------+--------------------------------------------------- Reporter: eschnett | Owner: eschnett Type: defect | Status: new Priority: major | Milestone: Component: SimFactory | Version: Keywords: | ------------------------+--------------------------------------------------- Surveyor is a BlueGene/P, and the operating system apparently does not support hard links. Submitting a job via Simfactory fails: DISTRIBUTE: Executing: ./simfactory/bin/sim --remote surveyor create- submit testsuite-surveyor-2011.12.21-19.31.05 --testsuite --parfile=recover.par --walltime=2:00:00 --procs=4 --ppn-used=4 --num- threads=2 Skeleton Created Job directory: "/pvfs-surveyor/eschnett/simulations/testsuite- surveyor-2011.12.21-19.31.05" Executable: "/gpfs/home/eschnett/Cbeta/exe/cactus_sim" Option list: "/pvfs-surveyor/eschnett/simulations/testsuite- surveyor-2011.12.21-19.31.05/SIMFACTORY/cfg/OptionList" Submit script: "/pvfs-surveyor/eschnett/simulations/testsuite- surveyor-2011.12.21-19.31.05/SIMFACTORY/run/SubmitScript" Run script: "/pvfs-surveyor/eschnett/simulations/testsuite- surveyor-2011.12.21-19.31.05/SIMFACTORY/run/RunScript" Assigned restart id: 0 Copying testsuite data Traceback (most recent call last): File "/home/eschnett/Cbeta/simfactory/bin/../lib/sim.py", line 147, in ? main() File "/home/eschnett/Cbeta/simfactory/bin/../lib/sim.py", line 143, in main CommandDispatch() File "/home/eschnett/Cbeta/simfactory/bin/../lib/sim.py", line 105, in CommandDispatch module.main() File "/gpfs/home/eschnett/Cbeta/simfactory/lib/sim-manage.py", line 397, in main CommandDispatch() File "/gpfs/home/eschnett/Cbeta/simfactory/lib/sim-manage.py", line 376, in CommandDispatch exec("command_%s()" % command) File "<string>", line 1, in ? File "/gpfs/home/eschnett/Cbeta/simfactory/lib/sim-manage.py", line 161, in command_create_submit command_submit() File "/gpfs/home/eschnett/Cbeta/simfactory/lib/sim-manage.py", line 262, in command_submit restart.userSubmit(simulationName) File "/gpfs/home/eschnett/Cbeta/simfactory/lib/simrestart.py", line 346, in userSubmit self.submit(submitScript) File "/gpfs/home/eschnett/Cbeta/simfactory/lib/simrestart.py", line 739, in submit self.copyTestsuiteData() File "/gpfs/home/eschnett/Cbeta/simfactory/lib/simrestart.py", line 487, in copyTestsuiteData os.link(self.Properties.executable, os.path.join(testexe,simlib.BaseName(self.Properties.executable))) OSError: [Errno 95] Operation not supported Simfactory should catch this, and should copy the file if it cannot be linked. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/708> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 1

[Einstein Toolkit] #767: removing the last REQUIRES item from configuration.ccl leads to build failures
by Einstein Toolkit 10 Aug '12

10 Aug '12

#767: removing the last REQUIRES item from configuration.ccl leads to build failures --------------------+------------------------------------------------------- Reporter: rhaas | Owner: Type: defect | Status: new Priority: minor | Milestone: Component: Cactus | Version: Keywords: | --------------------+------------------------------------------------------- The underlying issue seems to be that changing configuration.ccl does not necessarily rebuild all files the were generated using information in it. to reproduce: # get a fresh ET checkout (trunk will do) # add to {{{arrangements/EinsteinBase/CoordGauge/configuration.ccl}}} {{{ REQUIRES Carpet }}} # build Cactus # make sure that you have a file {{{configs/et/bindings/Configuration/Thorns/cctki_CoordGauge.h}}}. If such a file does not exists then most likely you did not start from a fresh checkout. touch the other .ccl files and src/Slicing.c in CoordGauge and build again. The file should appear. Make sure that {{{configs/et/build/CoordGauge/Slicing.c.d}}} contains {{{.../configs/et/bindings/include/../Configuration/Thorns/cctki_CoordGauge.h}}} if not, same as above. # remove the {{{REQUIRES}}} line you added # try to build Cactus # the build should fail with: {{{ Checking status of thorn CoordGauge make[2]: *** [make.checked] Error 2 make[1]: *** [/data/rhaas/postdoc/gr/ET/configs/et/lib/libthorn_CoordGauge.a] Error 2 make: *** [et] Error 2 }}} If you make is the buggy version 3.81 then no reason is given. (make SILENT=no or make -d does not help you either) If you are lucky and have a non buggy version of make (https://savannah.gnu.org/bugs/?15110#comment7) then it might actually tell you that it cannot find {{{ configs/et/bindings/Configuration/Thorns/cctki_CoordGauge.h}}}. To test this touch the file and try to build again. It should work now. Also Slicing.c.d will no longer contain a reference to the offending file. A workaround is to not unlink {{{cctki_CoordGauge.h}}} in {{{lib/sbin/CreateConfigurationBindings.pl}}} around line 176. This generates an empty file which makes make happy. To work around the buggy make (to get an error message) one can replace all {{{ -include foo bar baz }}} lines by {{{ -include $(filter-out $(wildcard foo bar baz),foo bar baz)) include $(filter $(wildcard foo bar baz),foo bar baz)) }}} ie use {{{-include}}} for non-existing files and {{{include}}} for existing ones. The buggy make is what makes this hard, you don't know why the compilation fails and trying to force recompile of CoordGauge by touching any of its .ccl or source files does not help. I usually ended up doing a realclean. Very annoying if this happens on say Kraken. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/767> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 6

[Einstein Toolkit] #730: The mojave variable "thornlist" cannot deal with absolute path names; update repo fails then...
by Einstein Toolkit 08 Aug '12

08 Aug '12

#730: The mojave variable "thornlist" cannot deal with absolute path names; update repo fails then... ---------------------+------------------------------------------------------ Reporter: alibeck | Owner: sbrandt Type: defect | Status: new Priority: blocker | Milestone: Component: Mojave | Version: Keywords: | ---------------------+------------------------------------------------------ Using Eclispe (indigo classic), I have tried to build with a new thornlist. Therefore I have entered the following name in mojave -> edit variables /home/alibeck/Cactus-Simfact2-NewRepos-save/Cactus/test-ali.th Staring then "update repo" gives me: [1m[31mError: [0mCould not open Cactus//home/alibeck/Cactus-Simfact2 -NewRepos-save/Cactus/test-ali.th So mojave tries to open a file called Cactus//home/alibeck/Cactus-Simfact2-NewRepos-save/Cactus/test-ali.th instead of /home/alibeck/Cactus-Simfact2-NewRepos-save/Cactus/test-ali.th -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/730> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 5

[Einstein Toolkit] #177: EXC_BAD_ACCESS in CarpetIOASCII
by Einstein Toolkit 06 Aug '12

06 Aug '12

#177: EXC_BAD_ACCESS in CarpetIOASCII --------------------+------------------------------------------------------- Reporter: hinder | Owner: eschnett Type: defect | Status: new Priority: major | Milestone: Component: Carpet | Version: Keywords: | --------------------+------------------------------------------------------- I am trying to run a minimal parameter file for testing purposes (attached). Cactus gets as far as printing the iteration 0 info line and then appears to hang. When I run in a debugger, it reports: Program received signal EXC_BAD_ACCESS, Could not access memory. Reason: 13 at address: 0x0000000000000000 0x0000000100b858b7 in CarpetIOASCII::WriteASCII<0> (os=@0x7fff5fbfc5e0, gfdatas={<std::_Vector_base<const gdata *, std::allocator<const gdata *> >> = {_M_impl = {<allocator<const gdata *>> = {<__gnu_cxx::new_allocator<const gdata *>> = {<No data fields>}, <No data fields>}, _M_start = 0x109f0ea10, _M_finish = 0x109f0eab8, _M_end_of_storage = 0x109f0eab8}}, <No data fields>}, gfext=@0x7fff5fbfc960, vi=0, time=0, org=@0x7fff5fbfcafc, dirs=@0x7fff5fbfd150, rl=0, ml=0, m=0, c=0, tl=0, coord_time=0, coord_lower=@0x7fff5fbfc9d8, coord_upper=@0x7fff5fbfc9f0) at ioascii.cc:1378 1378 switch (vartype) { (gdb) bt #0 0x0000000100b858b7 in CarpetIOASCII::WriteASCII<0> (os=@0x7fff5fbfc5e0, gfdatas={<std::_Vector_base<const gdata *, std::allocator<const gdata *> >> = {_M_impl = {<allocator<const gdata *>> = {<__gnu_cxx::new_allocator<const gdata *>> = {<No data fields>}, <No data fields>}, _M_start = 0x109f0ea10, _M_finish = 0x109f0eab8, _M_end_of_storage = 0x109f0eab8}}, <No data fields>}, gfext=@0x7fff5fbfc960, vi=0, time=0, org=@0x7fff5fbfcafc, dirs=@0x7fff5fbfd150, rl=0, ml=0, m=0, c=0, tl=0, coord_time=0, coord_lower=@0x7fff5fbfc9d8, coord_upper=@0x7fff5fbfc9f0) at ioascii.cc:1378 #1 0x0000000100b5b7ee in CarpetIOASCII::IOASCII<0>::OutputDirection (cctkGH=0x109f073f0, vindex=0, alias={_M_dataplus = {<allocator<char>> = {<__gnu_cxx::new_allocator<char>> = {<No data fields>}, <No data fields>}, _M_p = 0x10a06c1c8 "carpet::timing"}}, basefilename={_M_dataplus = {<allocator<char>> = {<__gnu_cxx::new_allocator<char>> = {<No data fields>}, <No data fields>}, _M_p = 0x10a06ba68 "minimal/carpet::timing"}}, dirs=@0x7fff5fbfd150, is_new_file=true, truncate_file=true) at ioascii.cc:610 #2 0x0000000100b554c4 in CarpetIOASCII::IOASCII<0>::OutputVarAs (cctkGH=0x109f073f0, varname=0x10a06c170 "CARPET::physical_time_per_hour", alias=0x10a06be00 "carpet::timing") at ioascii.cc:480 #3 0x0000000100b57370 in CarpetIOASCII::IOASCII<0>::TriggerOutput (cctkGH=0x109f073f0, vindex=0) at ioascii.cc:359 #4 0x0000000100b542b7 in CarpetIOASCII::IOASCII<0>::OutputGH (cctkGH=0x109f073f0) at ioascii.cc:239 #5 0x000000010329a006 in Carpet::OutputGH (cctkGH=0x109f073f0) at OutputGH.cc:55 #6 0x0000000103293b25 in Carpet::OutputGH (where=0x104c70f3c "Initialise::CallAnalysis", cctkGH=0x109f073f0) at Initialise.cc:1382 #7 0x000000010328d432 in Carpet::CallAnalysis (cctkGH=0x109f073f0) at Initialise.cc:530 #8 0x00000001032892d4 in Carpet::Initialise (fc=0x7fff5fbfe2b0) at Initialise.cc:118 #9 0x000000010005806a in main (argc=4, argv=0x7fff5fbfe318) at flesh.cc:80 I do not see how this line "switch(vartype)" where vartype is declared on the stack, could lead to this error. This configuration has been rebuilt with -O0 (Intel compiler) and debugging enabled. This is with the current production (Git) version of Carpet running on Mac OS 10.6.5. The code is compiled as 64 bit. This parameter file has worked in the past, though with 32 bit on Mac OS 10.5. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/177> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 6

[Einstein Toolkit] #465: Hydro_InitExcision test cases take a long time
by Einstein Toolkit 04 Aug '12

04 Aug '12

#465: Hydro_InitExcision test cases take a long time -----------------------------------+---------------------------------------- Reporter: eschnett | Owner: Type: defect | Status: new Priority: major | Milestone: Component: EinsteinToolkit thorn | Version: Keywords: | -----------------------------------+---------------------------------------- I am just running all test cases with an executable without optimisation, and I find that Hydro_InitExcision takes a long time. While most other test cases finish in a few minutes, Hydro_InitExcision takes two hours to run. The test cases should be reduced in number, size, or duration. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/465> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 10

[Einstein Toolkit] #550: CarpetIOHDF5 too verbose while reading from checkpoint
by Einstein Toolkit 02 Aug '12

02 Aug '12

#550: CarpetIOHDF5 too verbose while reading from checkpoint -------------------------+-------------------------------------------------- Reporter: knarf | Owner: eschnett Type: enhancement | Status: new Priority: minor | Milestone: Component: Carpet | Version: Keywords: | -------------------------+-------------------------------------------------- It is not that uncommon that I recover using a different number of processors. Every time I do this I see the error file cluttered with messages like WARNING level 1 in thorn CarpetIOHDF5 processor 21 host c312-313.ls4.tacc.utexas.edu (line 640 of /work/00920/tg459479/Cactus/arrangements/Carpet/CarpetIOHDF5/src/Input.cc): -> Variable AHFINDERDIRECT::ahmask on rl 0 and tl 0 not read completely. Will have to look for it in other files I expect this, this is not an error and not really something to warn about. I acknowledge that this might have been introduced when recovering using the same number of processors was a problem and caused reading all files, but I don't think this is an issue anymore. I propose to change the warnlevel for this message to CCTK_WARN_DEBUG(4). In addition it would be good to have _one_ separate message with level CCTK_WARN_PICKY(3) if any variable/reflevel/timelevel could not be read completely (but not one for each of these), ideally only once for all processors. This would not clutter the output of the default simfactory runs (-L 3) too much, but would indicate that this happened - and in case this is a problem it's easy to enable -L 4. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/550> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 13

[Einstein Toolkit] #634: Riemann1D fails to compile on Kraken
by Einstein Toolkit 08 Jul '12

08 Jul '12

#634: Riemann1D fails to compile on Kraken -----------------------------------+---------------------------------------- Reporter: hinder | Owner: Type: defect | Status: new Priority: minor | Milestone: Component: EinsteinToolkit thorn | Version: Keywords: GRHydro | -----------------------------------+---------------------------------------- I'm unable to compile the Riemann1D utility on Kraken. It gives the following error message. {{{ Creating Riemann1d in /nics/d/home/hinder/Cactus/EinsteinToolkit/exe/sim from /nics/d/home/hinder/Cactus/EinsteinToolkit/configs/sim/build/GRHydro/Riemann1d.o /nics/d/home/hinder/Cactus/EinsteinToolkit/configs/sim/build/GRHydro/Riemann1d.o: In function `riemann1d': /nics/d/home/hinder/Cactus/EinsteinToolkit/arrangements/EinsteinEvolve/GRHydro/src/util/Riemann1d.f90:10: undefined reference to `__kmpc_begin' /nics/d/home/hinder/Cactus/EinsteinToolkit/arrangements/EinsteinEvolve/GRHydro/src/util/Riemann1d.f90:374: undefined reference to `__kmpc_end' /usr/bin/ld: link errors found, deleting executable `/nics/d/home/hinder/Cactus/EinsteinToolkit/exe/sim/Riemann1d' make[1]: *** [/nics/d/home/hinder/Cactus/EinsteinToolkit/exe/sim/Riemann1d] Error 1 make: *** [sim-utils] Error 2 }}} I think that this needs an Intel library to be linked in, but I'm not sure which one or how to add it. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/634> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 4

[Einstein Toolkit] #751: Carpet fails when running qc0-mclachlan.par
by Einstein Toolkit 08 Jul '12

08 Jul '12

#751: Carpet fails when running qc0-mclachlan.par --------------------+------------------------------------------------------- Reporter: rhaas | Owner: eschnett Type: defect | Status: new Priority: major | Milestone: Component: Carpet | Version: Keywords: | --------------------+------------------------------------------------------- this is due to ggf::transfer_from_all line 613 (dst->transfer_from) where dst is NULL: {{{ 03 assert (lc1>=0 or lc2>=0); 604 605 // Source and destination data 606 gdata * const dst = 607 lc1>=0 ? storage.AT(ml1).AT(rl1).AT(lc1).AT(tl1) : NULL; 608 cdata const & srcs = srcstorage.AT(ml2).AT(rl2); 609 for (int i=0; i<(int)gsrcs.size(); ++i) { 610 gsrcs.AT(i) = lc2>=0 ? srcs.AT(lc2).AT(tl2s.AT(i)) : NULL; 611 } 612 613 dst->transfer_from 614 (state, gsrcs, times, recv, send, slabinfo, p1, p2, time, pos, pot); }}} which causes a segfault in line 613. lc1 is -1 in this case and passes the assert in line 603. Since dst is used as a pointer it may never be NULL. It can be reproduced with the qc0-mclachlan.par example from simfactory. Tested on Caltech's bethe workstation with 12 MPI processes and no OpenMP. hg blames commit 5418b354a3ab which seems to be the original Carpet import into mercurial so this seems to be caused by something else. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/751> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 4

[Einstein Toolkit] #732: qc0-mclachlan example parameter file should be more functional
by Einstein Toolkit 22 Jun '12

22 Jun '12

#732: qc0-mclachlan example parameter file should be more functional -------------------------+-------------------------------------------------- Reporter: hinder | Owner: Type: enhancement | Status: new Priority: minor | Milestone: Component: Other | Version: Keywords: | -------------------------+-------------------------------------------------- I propose adding wave extraction (using WeylScal4 and Multipole), as well as puncture tracking using PunctureTracker, to qc0-mclachlan.par. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/732> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 4

[Einstein Toolkit] #625: CapretIOHDF5 sliced output does not output symmetry points unless it also outputs buffer points
by Einstein Toolkit 20 Jun '12

20 Jun '12

#625: CapretIOHDF5 sliced output does not output symmetry points unless it also outputs buffer points --------------------------+------------------------------------------------- Reporter: hinder | Owner: eschnett Type: defect | Status: new Priority: major | Milestone: Component: Carpet | Version: Keywords: CarpetIOHDF5 | --------------------------+------------------------------------------------- The parameter CarpetIOHDF5::output_symmetry_points = yes does not work when CarpetIOHDF5::output_buffer_points = no (the default). This is probably due to the line if (not output_buffer_points) { exts &= allactive; } near line 1071 in OutputSlice.cc. I suspect that allactive does not include the symmetry points. The attached parameter file should be run on one processor. You can then use h5dump -d '/GRID::x it=0 tl=0 rl=0' output_symmetry/x.x.h5 Near the top you will see DATASET "/GRID::x it=0 tl=0 rl=0" { DATATYPE H5T_IEEE_F64LE DATASPACE SIMPLE { ( 5 ) / ( 5 ) } DATA { (0): 0, 0.1, 0.2, 0.3, 0.4 } i.e. the first point output is x = 0. For this parameter file, there should be a symmetry point at x = -0.1. If you modify the parameter file to use CarpetIOHDF5::output_buffer_points = yes, then the symmetry point appears in the output. The workaround is to always use CarpetIOHDF5::output_buffer_points = yes if you want to output symmetry points. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/625> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 11

← Newer
1
...
6
7
8
9
10
11
12
...
16
Older →

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

Trac March 2012