Trac April 2014

trac@lists.einsteintoolkit.org

1 participants
157 discussions

[Einstein Toolkit] #1497: CarpetInterp/waveinterp_1p and CarpetInterp/waveinterp_2p tests are failing
by Einstein Toolkit 26 Apr '14

26 Apr '14

#1497: CarpetInterp/waveinterp_1p and CarpetInterp/waveinterp_2p tests are failing --------------------+------------------------------------------------------- Reporter: hinder | Owner: eschnett Type: defect | Status: new Priority: minor | Milestone: Component: Carpet | Version: development version Keywords: | --------------------+------------------------------------------------------- The old tests CarpetInterp/waveinterp_1p and CarpetInterp/waveinterp_2p, which are almost identical apart from running on 1 or 2 processes, are both failing with the error {{{ ---------------------------------------------------------------- Iteration Time | WAVEMOL::phi | *VEMOL::phit | *VEMOL::phix | norm2 | norm2 | norm2 ---------------------------------------------------------------- 0 0.138 | -nan | -nan | -nan WARNING level 0 in thorn CarpetLib processor 0 host caltechcactusjenkins.spdns.org (line 428 of /home/jenkins/workspace/EinsteinToolkit/arrangements/Carpet/CarpetLib/src/gdata.cc): -> Internal error: extrapolation in time. variable=WAVEMOL::phi time=0.20000000000000001 times=[0.40000000000000002,0.67500000000000004,0.27500000000000002] WARNING level 0 in thorn CarpetLib processor 0 host caltechcactusjenkins.spdns.org (line 428 of /home/jenkins/workspace/EinsteinToolkit/arrangements/Carpet/CarpetLib/src/gdata.cc): -> Internal error: extrapolation in time. variable=WAVEMOL::phi time=0.20000000000000001 times=[0.40000000000000002,0.67500000000000004,0.27500000000000002] }}} This test is newly failing because the dependent thorn WaveMoL has only just been added to the toolkit. The tests had a parameter setting WaveMoL::num_timelevels = 3 which didn't correspond to any WaveMoL parameter, so previously the tests would crash earlier. I removed that parameter setting, and now the tests fail with this "extrapolation in time" error. I don't understand this failure. The times array seems to be non-monotonic [0.4, 0.675, 0.275] perhaps indicating that it might not have been initialised correctly? The coarse grid timestep should be 0.1*0.25 = 0.025, so I don't see where these times come from during iteration 1. The NaNs in the norms are probably poison, which probably wasn't enabled when this test was written, so nobody noticed. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/1497> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 8

[Einstein Toolkit] #1594: Carpet steps iterations individually
by Einstein Toolkit 26 Apr '14

26 Apr '14

#1594: Carpet steps iterations individually ----------------------+----------------------------------------------------- Reporter: eschnett | Owner: eschnett Type: defect | Status: new Priority: major | Milestone: Component: Carpet | Version: development version Keywords: | ----------------------+----------------------------------------------------- Carpet calls "advance_time" for each iteration. If many fine levels are possible, but are not present, then this is quite inefficient. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/1594> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 0

[Einstein Toolkit] #1340: simfactory does not abort --testsuite submission process if rsync fails
by Einstein Toolkit 26 Apr '14

26 Apr '14

#1340: simfactory does not abort --testsuite submission process if rsync fails ------------------------+--------------------------------------------------- Reporter: rhaas | Owner: eschnett Type: defect | Status: new Priority: minor | Milestone: Component: SimFactory | Version: Keywords: | ------------------------+--------------------------------------------------- when setting up testsuite runs simfactory uses rsync to copy the test suite data into the simulation folder. If this rsync fails (eg. because a user specified incorrect rsyncopts in defs.local.ini) the submission process does not abort and instead submits an emtpy test-suite run. {{{ rhaas@kraken-gsi2:~/ET_trunk> sim create-submit 2p6t --procs 12 --num- threads 6 --walltime 4:0:0 --tests uite --allocation TG-ASC120003 Skeleton Created Job directory: "/lustre/scratch/rhaas/simulations/2p6t" Option --testsuite given Executable: "/nics/c/home/rhaas/ET_trunk/exe/cactus_sim" Option list: "/lustre/scratch/rhaas/simulations/2p6t/SIMFACTORY/cfg/OptionList" Submit script: "/lustre/scratch/rhaas/simulations/2p6t/SIMFACTORY/run/SubmitScript" Run script: "/lustre/scratch/rhaas/simulations/2p6t/SIMFACTORY/run/RunScript" Assigned restart id: 0 Copying testsuite data rsync: --times=no: option does not take an argument rsync error: syntax or usage error (code 1) at main.c(1435) [client=3.0.9] Executing submit command: /opt/torque/2.5.7/bin/qsub /lustre/scratch/rhaas/simulations/2p6t/output-0000/SIMFACTORY/SubmitScript Submit finished, job id is 3236567.nid00016 rhaas@kraken-gsi2:~/ET_trunk> qdel 3236567.nid00016 }}} My rsynopts were: {{{ rsyncopts = --times=no --checksum --include 'configs/*/ThornList' --exclude 'configs/*/*' }}} which are bad for two reasons: 1.) kraken's rsync does not no --times-no (likely wants --notimes or so) 2.) --exclude 'configs/*/*' excludes cctk_MPI.h which is used by the test suite infrastructure to detect the presence of MPI Note that some of these options are obviously obsolete now that simfactory defaults to --times=no --checksum anyway. Still, simfactory should always check the exit status of any command it calls I think. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/1340> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 4

[Einstein Toolkit] #1550: Carpet Timer object gives 0 the first time it is read
by Einstein Toolkit 25 Apr '14

25 Apr '14

#1550: Carpet Timer object gives 0 the first time it is read --------------------+------------------------------------------------------- Reporter: hinder | Owner: eschnett Type: defect | Status: new Priority: major | Milestone: ET_2014_05 Component: Carpet | Version: development version Keywords: | --------------------+------------------------------------------------------- The getTime method of the Carpet Timer object returns a value of 0 the first time it is read. The following test demonstrates the problem: {{{ SCHEDULE Timer_TestTimer at startup { LANG: C } "Test the timers" }}} {{{ #include <unistd.h> extern "C" int Timer_TestTimer() { Timer timer("Test"); timer.start(); unsigned int reason = sleep(1); double val = timer.getTime(); assert(reason != 0 || val > 0.5); timer.stop(); } }}} This is a regression since the original version of the Timer class, possibly introduced during the move of the class from Carpet to Timers. A symptom is that the evolution timer tree shows "inf" for the percentage of the total time the first time it is used, since the Evolve timer used to normalise the time values has been read as zero. The underlying Cactus timers do not suffer from this problem, so there is something wrong in the logic for the Timer class. The following test passes: {{{ SCHEDULE Timer_TestCactusTimers at startup { LANG: C } "Test the Cactus timers" }}} {{{ extern "C" int Timer_TestCactusTimers() { int handle = CCTK_TimerCreate("TestTimer"); cout << "handle == " << handle << endl; assert(handle >= 0); CCTK_TimerStartI (handle); unsigned int reason = sleep(1); CCTK_TimerStopI (handle); static cTimerData * timer = 0; if (not timer) timer = CCTK_TimerCreateData (); assert (timer); CCTK_TimerI (handle, timer); const cTimerVal* tv = CCTK_GetClockValue("gettimeofday", timer); assert(tv); double val = CCTK_TimerClockSeconds(tv); assert(reason != 0 || val > 0.5); return 0; } }}} -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/1550> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 4

[Einstein Toolkit] #1359: add "read from file" option ot HydroBase's initial_data options
by Einstein Toolkit 25 Apr '14

25 Apr '14

#1359: add "read from file" option ot HydroBase's initial_data options -----------------------------------+---------------------------------------- Reporter: rhaas | Owner: Type: enhancement | Status: new Priority: minor | Milestone: Component: EinsteinToolkit thorn | Version: Keywords: HydroBase | -----------------------------------+---------------------------------------- the attached patch adds a value "read from file" to HydroBase's initial_XXX options. This makes it possible to use IOUtils file reader with hydro data. This is somewhat similar to IDFileADM's extension of ADMBase's options, only we do not have to set any grid scalars. Needed to be able to reproduce the MHD paper's collapse test since Whisky_RNSID is not public. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/1359> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 18

[Einstein Toolkit] #1589: suspicious code for operator+ in bboxset2
by Einstein Toolkit 24 Apr '14

24 Apr '14

#1589: suspicious code for operator+ in bboxset2 --------------------+------------------------------------------------------- Reporter: rhaas | Owner: eschnett Type: defect | Status: new Priority: major | Milestone: Component: Carpet | Version: development version Keywords: Carpet | --------------------+------------------------------------------------------- Operator+ in bboxset2 seems to actually implement operator^ but I don't quite understand what they are all doing so, please review. When running with CARPET_DEBUG and CARPET_USE_BBOXSET2 the code dies with an assert due to a non-empty box intersection from inside CARPET_DEBUG code which seems to be due to the (invalid) assumption that multiple box.exterior would not overlap. Finally the last patch fixes an possible obscure issue where CarpetIOHDF5 will ignore the checkpoint=no tag of a grid variable if the checkpoint file does indeed contain such a variable (since eg it was written with a code version that still had checkpoint=yes). -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/1589> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 8

[Einstein Toolkit] #1590: Non ET thorn OutsideMask implicitly defines sqrt as int sqrt()
by Einstein Toolkit 24 Apr '14

24 Apr '14

#1590: Non ET thorn OutsideMask implicitly defines sqrt as int sqrt() -------------------------+-------------------------------------------------- Reporter: rhaas | Owner: Type: defect | Status: new Priority: major | Milestone: Component: Other | Version: development version Keywords: OutsideMask | -------------------------+-------------------------------------------------- OutsideMask neglects to include math.h in src/update_mask.c which causes sqrt() to be implicitly defined as int sqrt() which causes distance estimates to be incorrect (most likely random since a double result is likely returned in some other way than an int result). -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/1590> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 6

[Einstein Toolkit] #1215: Source browsing not working
by Einstein Toolkit 24 Apr '14

24 Apr '14

#1215: Source browsing not working ----------------------------------+----------------------------------------- Reporter: hinder | Owner: Type: defect | Status: new Priority: minor | Milestone: Component: EinsteinToolkit trac | Version: Keywords: | ----------------------------------+----------------------------------------- The repositories in the "Browse source" TRAC interface (https://trac.einsteintoolkit.org/browser) are not being updated. The last Cactus flesh commit visible there is from 10 months ago. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/1215> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 4

[Einstein Toolkit] #1578: VizTools/DataVaultXVSutils: fix makefile to compile hdf5todv
by Einstein Toolkit 24 Apr '14

24 Apr '14

#1578: VizTools/DataVaultXVSutils: fix makefile to compile hdf5todv ----------------------------------------+----------------------------------- Reporter: bmundim | Owner: Type: defect | Status: new Priority: major | Milestone: ET_2014_05 Component: Other | Version: development version Keywords: VizTools DataVaultXVSutils | ----------------------------------------+----------------------------------- The attached patch fixes the makefile to compile hdf5todv. Is it ok to apply? -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/1578> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 8

[Einstein Toolkit] #1528: check that mainstream machines use correct thread binding
by Einstein Toolkit 23 Apr '14

23 Apr '14

#1528: check that mainstream machines use correct thread binding ------------------------+--------------------------------------------------- Reporter: rhaas | Owner: eschnett Type: task | Status: new Priority: major | Milestone: Component: SimFactory | Version: development version Keywords: | ------------------------+--------------------------------------------------- it is possible that systems that initialize themselves before hwloc (eg MPI) bind to the wrong CPU core unless (the equivalent of) numactl is used. For an example on bluewaters see #1527. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/1528> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 4

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

Trac April 2014