Trac August 2011

trac@lists.einsteintoolkit.org

1 participants
182 discussions

[Einstein Toolkit] #327: Simfactory: ranger-intel11.run question.
by Einstein Toolkit 27 Oct '11

27 Oct '11

#327: Simfactory: ranger-intel11.run question. ------------------------+--------------------------------------------------- Reporter: bmundim | Owner: mthomas Type: defect | Status: new Priority: minor | Milestone: Component: SimFactory | Version: Keywords: | ------------------------+--------------------------------------------------- Shouldn't we load intel/11.1 there, since the default on Ranger is intel/10.1? Also unless "module load intel/11.1" is in your .login_user, it will fail to "module load mvapich" since no compiler has been selected. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/327> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 2

[Einstein Toolkit] #472: Correct scheduling of TmunuBase's SetTmunu
by Einstein Toolkit 27 Oct '11

27 Oct '11

#472: Correct scheduling of TmunuBase's SetTmunu ----------------------+----------------------------------------------------- Reporter: eschnett | Owner: Type: defect | Status: new Priority: minor | Milestone: Component: Other | Version: Keywords: | ----------------------+----------------------------------------------------- I notice that TmunuBase doesn't schedule the group SetTmunu often enough. In particular, it is not scheduled after recovery, and it's scheduling at evol is also questionable. I also notice that GRHydro "fixes" this by scheduling SetTmunu by itself. This needs to be cleaned up. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/472> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 2

[Einstein Toolkit] #480: Problem with determining host name in SimFactory 1
by Einstein Toolkit 27 Oct '11

27 Oct '11

#480: Problem with determining host name in SimFactory 1 ------------------------+--------------------------------------------------- Reporter: hinder | Owner: eschnett Type: defect | Status: new Priority: major | Milestone: Component: SimFactory | Version: Keywords: | ------------------------+--------------------------------------------------- On the new Scientific Linux 6 installation at the AEI, SimFactory 1 thinks that the local machine is called localhost.localdomain: $ simfactory/sim build --thornlist WaveToy.th --optionlist damiana_sl6.cfg Simulation Factory: Configuration name(s) not specified -- using default configuration "sim" Uncaught exception from user code: Unknown machine name "localhost.localdomain" at simfactory/sim line 5061. at simfactory/sim line 5061 main::get_machine('') called at simfactory/sim line 1498 main::command_build() called at simfactory/sim line 454 Looking at the code for get_hostnamealias, it appears to look for all the host name aliases of the current machine and select the first one in the returned list which contains a dot. On the workstation in question, I get: [ianhin@sl-18 ~]$ hostname -a localhost.localdomain localhost localhost6.localdomain6 localhost6 sl-18 sl-18.damiana.admin which explains the behaviour. My first reaction would be to filter the list to remove all the "local" aliases. This might break peoples' existing setup. I have seen mailing list posts which indicate that people use localhost as their machine name in simfactory. Since SimFactory 1 is approaching end-of-life, it might just be better to say that you need to use the --hostname option directly if you run into this problem, rather than breaking peoples' existing workflow. Thoughts? -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/480> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 4

[Einstein Toolkit] #147: Write transition guide for EOS_Omni
by Einstein Toolkit 24 Oct '11

24 Oct '11

#147: Write transition guide for EOS_Omni -------------------------------------+-------------------------------------- Reporter: eschnett | Owner: Type: defect | Status: new Priority: major | Milestone: Component: EinsteinToolkit website | Version: Keywords: | -------------------------------------+-------------------------------------- The Einstein Toolkit pages need a wiki tutorial for switching to EOS_Omni. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/147> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 7

[Einstein Toolkit] #162: Document CCTK_GFINDEX3D and friends in reference manual
by Einstein Toolkit 23 Oct '11

23 Oct '11

#162: Document CCTK_GFINDEX3D and friends in reference manual ----------------------+----------------------------------------------------- Reporter: eschnett | Owner: Type: defect | Status: new Priority: major | Milestone: Component: Cactus | Version: Keywords: | ----------------------+----------------------------------------------------- I believe the reference manual does not describe any of the CCTK_GFINDEX* and CCTK_VECTGFINDEX* functions. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/162> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 7

[Einstein Toolkit] #534: Checkpointing fails on LoneStar
by Einstein Toolkit 23 Oct '11

23 Oct '11

#534: Checkpointing fails on LoneStar --------------------------+------------------------------------------------- Reporter: hinder | Owner: eschnett Type: defect | Status: new Priority: major | Milestone: Component: Carpet | Version: Keywords: CarpetIOHDF5 | --------------------------+------------------------------------------------- Hi, I am starting to run on LoneStar, but find that I cannot checkpoint. This is for a production simulation. I see: INFO (CarpetIOHDF5): --------------------------------------------------------- INFO (CarpetIOHDF5): Dumping periodic checkpoint at iteration 9876, simulation time 18.5175 INFO (CarpetIOHDF5): --------------------------------------------------------- on stdout, and there is nothing on stderr. The checkpoint files are partially written: -rw------- 1 hinder G-25181 61M Aug 25 15:58 checkpoint.chkpt.tmp.it_9876.file_0.h5 -rw------- 1 hinder G-25181 47M Aug 25 15:58 checkpoint.chkpt.tmp.it_9876.file_10.h5 -rw------- 1 hinder G-25181 47M Aug 25 15:58 checkpoint.chkpt.tmp.it_9876.file_11.h5 -rw------- 1 hinder G-25181 47M Aug 25 15:58 checkpoint.chkpt.tmp.it_9876.file_12.h5 -rw------- 1 hinder G-25181 46M Aug 25 15:58 checkpoint.chkpt.tmp.it_9876.file_13.h5 -rw------- 1 hinder G-25181 46M Aug 25 15:58 checkpoint.chkpt.tmp.it_9876.file_14.h5 -rw------- 1 hinder G-25181 47M Aug 25 15:58 checkpoint.chkpt.tmp.it_9876.file_15.h5 -rw------- 1 hinder G-25181 47M Aug 25 15:58 checkpoint.chkpt.tmp.it_9876.file_16.h5 -rw------- 1 hinder G-25181 47M Aug 25 15:58 checkpoint.chkpt.tmp.it_9876.file_17.h5 -rw------- 1 hinder G-25181 46M Aug 25 15:58 checkpoint.chkpt.tmp.it_9876.file_18.h5 -rw------- 1 hinder G-25181 46M Aug 25 15:58 checkpoint.chkpt.tmp.it_9876.file_19.h5 -rw------- 1 hinder G-25181 60M Aug 25 15:58 checkpoint.chkpt.tmp.it_9876.file_1.h5 -rw------- 1 hinder G-25181 47M Aug 25 15:58 checkpoint.chkpt.tmp.it_9876.file_20.h5 -rw------- 1 hinder G-25181 47M Aug 25 15:58 checkpoint.chkpt.tmp.it_9876.file_21.h5 -rw------- 1 hinder G-25181 47M Aug 25 15:58 checkpoint.chkpt.tmp.it_9876.file_22.h5 -rw------- 1 hinder G-25181 46M Aug 25 15:58 checkpoint.chkpt.tmp.it_9876.file_23.h5 -rw------- 1 hinder G-25181 58M Aug 25 15:58 checkpoint.chkpt.tmp.it_9876.file_24.h5 -rw------- 1 hinder G-25181 58M Aug 25 15:58 checkpoint.chkpt.tmp.it_9876.file_25.h5 -rw------- 1 hinder G-25181 58M Aug 25 15:58 checkpoint.chkpt.tmp.it_9876.file_26.h5 -rw------- 1 hinder G-25181 57M Aug 25 15:58 checkpoint.chkpt.tmp.it_9876.file_27.h5 -rw------- 1 hinder G-25181 58M Aug 25 15:58 checkpoint.chkpt.tmp.it_9876.file_28.h5 -rw------- 1 hinder G-25181 58M Aug 25 15:58 checkpoint.chkpt.tmp.it_9876.file_29.h5 -rw------- 1 hinder G-25181 60M Aug 25 15:58 checkpoint.chkpt.tmp.it_9876.file_2.h5 -rw------- 1 hinder G-25181 58M Aug 25 15:58 checkpoint.chkpt.tmp.it_9876.file_30.h5 -rw------- 1 hinder G-25181 57M Aug 25 15:58 checkpoint.chkpt.tmp.it_9876.file_31.h5 -rw------- 1 hinder G-25181 59M Aug 25 15:58 checkpoint.chkpt.tmp.it_9876.file_3.h5 -rw------- 1 hinder G-25181 46M Aug 25 15:58 checkpoint.chkpt.tmp.it_9876.file_4.h5 -rw------- 1 hinder G-25181 47M Aug 25 15:58 checkpoint.chkpt.tmp.it_9876.file_5.h5 -rw------- 1 hinder G-25181 47M Aug 25 15:58 checkpoint.chkpt.tmp.it_9876.file_6.h5 -rw------- 1 hinder G-25181 47M Aug 25 15:58 checkpoint.chkpt.tmp.it_9876.file_7.h5 -rw------- 1 hinder G-25181 46M Aug 25 15:58 checkpoint.chkpt.tmp.it_9876.file_8.h5 -rw------- 1 hinder G-25181 46M Aug 25 15:58 checkpoint.chkpt.tmp.it_9876.file_9.h5 and invalid: c334-106$ h5ls checkpoint.chkpt.tmp.it_9876.file_0.h5 checkpoint.chkpt.tmp.it_9876.file_0.h5: unable to open file The job and the processes are all still running. Logging into one of the nodes and attaching gdb to the Cactus process yields: 0x00002b8eb3f6a287 in MPIDI_CH3I_MRAILI_Get_next_vbuf (vc_ptr=0x7fff50b96cb0, vbuf_ptr=0x7fff50b96cb8) at ibv_channel_manager.c:367 367 if (*head && vc->mrail.rfp.p_RDMA_recv != vc->mrail.rfp.p_RDMA_recv_tail) (gdb) bt #0 0x00002b8eb3f6a287 in MPIDI_CH3I_MRAILI_Get_next_vbuf (vc_ptr=0x7fff50b96cb0, vbuf_ptr=0x7fff50b96cb8) at ibv_channel_manager.c:367 #1 0x00002b8eb3f0426c in MPIDI_CH3I_read_progress (vc_pptr=0x7fff50b96cb0, v_ptr=0x7fff50b96cb8, is_blocking=259164064) at ch3_read_progress.c:130 #2 0x00002b8eb3f023dd in MPIDI_CH3I_Progress (is_blocking=1354329264, state=0x7fff50b96cb8) at ch3_progress.c:206 #3 0x00002b8eb3f6852c in MPIC_Wait (request_ptr=0x7fff50b96cb0) at helper_fns.c:518 #4 0x00002b8eb3f67e9c in MPIC_Recv (buf=0x7fff50b96cb0, count=1354329272, datatype=259164064, source=30, tag=0, comm=-788556288, status=0x1) at helper_fns.c:76 #5 0x00002b8eb3eee47e in MPIR_Bcast_OSU (buffer=0x7fff50b96cb0, count=1354329272, datatype=259164064, root=30, comm_ptr=0x0) at bcast_osu.c:283 #6 0x00002b8eb3eed0c6 in PMPI_Bcast (buffer=0x7fff50b96cb0, count=1354329272, datatype=259164064, root=30, comm=0) at bcast.c:1274 #7 0x0000000000c12fc4 in CarpetIOHDF5::WriteVarChunkedParallel (cctkGH=0x7fff50b96cb0, outfile=1354329272, io_bytes=@0xf7287a0, request=0x1e, called_from_checkpoint=false, indexfile=-788556288, $q8=<value optimized out>, $q9=<value optimized out>, $r0=<value optimized out>, $r1=<value optimized out>, $r2=<value optimized out>, $r3=<value optimized out>) at /work/00915/hinder/Cactus/llama/arrangements/Carpet/CarpetIOHDF5/src/Output.cc:519 #8 0x0000000000bf3f7f in CarpetIOHDF5::Checkpoint (cctkGH=0x7fff50b96cb0, called_from=1354329272, $W3=<value optimized out>, $W4=<value optimized out>) at /work/00915/hinder/Cactus/llama/arrangements/Carpet/CarpetIOHDF5/src/CarpetIOHDF5.cc:973 #9 0x0000000000bf360b in CarpetIOHDF5::CarpetIOHDF5_EvolutionCheckpoint (cctkGH=0x7fff50b96cb0) at /work/00915/hinder/Cactus/llama/arrangements/Carpet/CarpetIOHDF5/src/CarpetIOHDF5.cc:186 #10 0x0000000000413a5f in CCTK_CallFunction (function=0x7fff50b96cb0, fdata=0x7fff50b96cb8, data=0xf7287a0) at /work/00915/hinder/Cactus/llama/src/main/ScheduleInterface.c:291 #11 0x00000000011c2eb1 in Carpet::CallFunction (function=0x7fff50b96cb0, attribute=0x7fff50b96cb8, data=0xf7287a0, $01=<value optimized out>, $04=<value optimized out>, $05=<value optimized out>) at /work/00915/hinder/Cactus/llama/arrangements/Carpet/Carpet/src/CallFunction.cc:135 #12 0x0000000000418dea in CCTKi_ScheduleCallFunction (function=0x7fff50b96cb0, attribute=0x7fff50b96cb8, data=0xf7287a0) at /work/00915/hinder/Cactus/llama/src/main/ScheduleInterface.c:2826 #13 0x000000000041bc26 in CCTKi_DoScheduleTraverse (group_name=0x7fff50b96cb0 "", item_entry=0x7fff50b96cb8, item_exit=0xf7287a0, while_check=0x1e, if_check=0, function_process=0x2aabd0ff9600, data=0x7fff50b97848) at /work/00915/hinder/Cactus/llama/src/schedule/ScheduleTraverse.c:158 #14 0x0000000000414f19 in CCTK_ScheduleTraverse (where=0x7fff50b96cb0 "", GH=0x7fff50b96cb8, CallFunction=0xf7287a0) at /work/00915/hinder/Cactus/llama/src/main/ScheduleInterface.c:812 #15 0x000000000116f6c0 in Carpet::CallAnalysis (cctkGH=0x7fff50b96cb0, $=2=<value optimized out>) at /work/00915/hinder/Cactus/llama/arrangements/Carpet/Carpet/src/Evolve.cc:556 #16 0x000000000116e755 in Carpet::Evolve (fc=0x7fff50b96cb0, $<1=<value optimized out>) at /work/00915/hinder/Cactus/llama/arrangements/Carpet/Carpet/src/Evolve.cc:81 #17 0x000000000040ccc5 in main (argc=4, argv=0x7fff50b98888) at /work/00915/hinder/Cactus/llama/src/main/flesh.cc:84 I'm not sure why CarpetIOHDF5 is performing MPI calls. This is with the stable version of Carpet. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/534> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 19

[Einstein Toolkit] #367: When a repo URL changes, GetComponents should offer more help
by Einstein Toolkit 19 Oct '11

19 Oct '11

#367: When a repo URL changes, GetComponents should offer more help ---------------------------+------------------------------------------------ Reporter: eschnett | Owner: eric9 Type: enhancement | Status: new Priority: major | Milestone: Component: GetComponents | Version: Keywords: | ---------------------------+------------------------------------------------ When a repo URL changes, GetComponents currently suggests to check out the repo from scratch (and presumably delete/ignore the old repo). This is very inflexible, in particular when the user has changes in the old repository, which often happens during development. SVN (and presumably all other VC software) offer commands to update the URL, so that one can keep the current checkout. Of course, this makes only sense if this is the same repository that only moved to a new URL, but this seems to happen often enough. GetComponents should at least output instructions for updating the URL. It would be even better if GetComponents detected that new and old repo are the same, and then update the repo URL by itself. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/367> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 10

[Einstein Toolkit] #494: CarpetReduce tests nonstaggered and staggered fail with development version of Carpet
by Einstein Toolkit 19 Oct '11

19 Oct '11

#494: CarpetReduce tests nonstaggered and staggered fail with development version of Carpet --------------------+------------------------------------------------------- Reporter: hinder | Owner: eschnett Type: defect | Status: new Priority: major | Milestone: Component: Carpet | Version: Keywords: | --------------------+------------------------------------------------------- The CarpetReduce tests nonstaggered and staggered fail with the development version of Carpet and pass with the stable version. The failure is reported as: weight.d.asc: substantial differences did not reproduce 3 NaNs from old weight.d.asc significant differences on 3 (out of 9) lines Were the NaNs wrong before, and somehow got into the test output incorrectly? Or are the NaNs supposed to be there? -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/494> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 10

[Einstein Toolkit] #414: --parallel option not documented in GetComponents
by Einstein Toolkit 19 Oct '11

19 Oct '11

#414: --parallel option not documented in GetComponents ---------------------------+------------------------------------------------ Reporter: bmundim | Owner: eric9 Type: defect | Status: new Priority: minor | Milestone: Component: GetComponents | Version: Keywords: | ---------------------------+------------------------------------------------ The --parallel option is not documented in both versions of GetComponents, the released and development ones. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/414> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 1

[Einstein Toolkit] #219: ExternalLibraries method should be documented
by Einstein Toolkit 19 Oct '11

19 Oct '11

#219: ExternalLibraries method should be documented ---------------------------+------------------------------------------------ Reporter: hinder | Owner: Type: defect | Status: new Priority: major | Milestone: Component: Cactus | Version: Keywords: documentation | ---------------------------+------------------------------------------------ The Cactus documentation http://einsteintoolkit.org/info/documentation/UsersGuide/UsersGuidech6.html… (scroll down to Compiling with Extra Packages) currently tells people to use the "extras" method for enabling access to external libraries such as HDF5, MPI etc. As I understand it, this method is deprecated in favour of the ExternalLibraries method, and both should not be used at the same time for the same library. The documentation should be updated to describe the ExternalLibraries method, and the old method description should be moved to an appendix with a clear warning that this is deprecated. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/219> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 4

← Newer
1
...
7
8
9
10
11
12
13
...
19
Older →

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

Trac August 2011