Trac April 2011

trac@lists.einsteintoolkit.org

1 participants
139 discussions

[Einstein Toolkit] #334: unsuccessful qsub not recognized / submit succeeds for finished simulation
by Einstein Toolkit 18 Aug '15

18 Aug '15

#334: unsuccessful qsub not recognized / submit succeeds for finished simulation ------------------------+--------------------------------------------------- Reporter: knarf | Owner: mthomas Type: defect | Status: new Priority: minor | Milestone: Component: SimFactory | Version: Keywords: | ------------------------+--------------------------------------------------- python version: I submitted a simulation 'sim submit' but the corresponding qsub failed due to wrong numbers of procs/node (philip cluster). I changed the number given on the command line and did a 'sim submit' again, this time successful. Several things happend which I think could be done better: - the unsuccessful qsub was not detected during the new submit - it attempted a restart and didn't simply clean the unsuccessful submit - when trying the restart, it went ahead and queued the job, but this later failed when run with "cannot rerun a restart that has been finished". This could have been caught earlier - without the wait time in the queue. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/334> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 6

[Einstein Toolkit] #114: per-variable tolerances for Cactus testsuites
by Einstein Toolkit 24 Jan '14

24 Jan '14

#114: per-variable tolerances for Cactus testsuites -------------------------+-------------------------------------------------- Reporter: knarf | Owner: Type: enhancement | Status: new Priority: major | Milestone: ET_2011_06 Component: Cactus | Version: Keywords: | -------------------------+-------------------------------------------------- It would be nice to be able to specify per-variable testsuite tolerances in Cactus (per regexp for the name in the ideal case). -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/114> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 24

[Einstein Toolkit] #392: Strange message "already on master"
by Einstein Toolkit 07 Nov '13

07 Nov '13

#392: Strange message "already on master" ---------------------------+------------------------------------------------ Reporter: eschnett | Owner: eric9 Type: defect | Status: new Priority: minor | Milestone: Component: GetComponents | Version: Keywords: | ---------------------------+------------------------------------------------ GetComponents outputs "already on master" for every git repository. This message should not appear. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/392> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 12

[Einstein Toolkit] #117: Error while building multiple configurations
by Einstein Toolkit 12 Aug '13

12 Aug '13

#117: Error while building multiple configurations ------------------------+--------------------------------------------------- Reporter: eschnett | Owner: mthomas Type: defect | Status: new Priority: major | Milestone: Component: SimFactory | Version: Keywords: | ------------------------+--------------------------------------------------- I wanted to build multiple configurations at once with the command ./simfactory/sim build sim-debug sim sim-debug is a debug configuration, sim is optimised. SimFactory built sim-debug, then aborted with the error: optionlist is: /Users/eschnett/EinsteinToolkit-hg/configs/sim/OptionList Error: pattern '^\s*DEBUG\s*=.*$' exists already It assumes that SimFactory doesn't properly distinguish between the different build options of the different configurations. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/117> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 2

[Einstein Toolkit] #107: Update released einsteintoolkit.bib once we have a more final version
by Einstein Toolkit 06 Jul '13

06 Jul '13

#107: Update released einsteintoolkit.bib once we have a more final version -----------------------+---------------------------------------------------- Reporter: anonymous | Type: task Status: new | Priority: major Milestone: | Component: EinsteinToolkit website Version: | Keywords: -----------------------+---------------------------------------------------- -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/107> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 3

[Einstein Toolkit] #346: Detect when --reconfig is necessary
by Einstein Toolkit 06 Jul '13

06 Jul '13

#346: Detect when --reconfig is necessary ----------------------+----------------------------------------------------- Reporter: eschnett | Owner: Type: defect | Status: new Priority: minor | Milestone: Component: Other | Version: Keywords: | ----------------------+----------------------------------------------------- Cactus sometimes outputs an error message that a configuration needs to be reconfigured. Simfactory should notice this, and then automatically build with --reconfig. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/346> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 3

[Einstein Toolkit] #229: Using a nonexistent header file should lead to an error message
by Einstein Toolkit 06 Jul '13

06 Jul '13

#229: Using a nonexistent header file should lead to an error message --------------------+------------------------------------------------------- Reporter: hinder | Owner: Type: defect | Status: new Priority: major | Milestone: Component: Cactus | Version: Keywords: | --------------------+------------------------------------------------------- If I have the following in my interface.ccl, USES INCLUDE: vectors.h but no thorn in my thornlist provides this header file, there is no error at compile time. Further, if I #include this file in my source file, an empty file is included, which means that again I don't get an error. The first indication that something is wrong is that the contents of the header file are not available, which makes debugging the problem with the thornlist very confusing. I propose that the CST should emit a fatal error if one of the thorns tries to use a header file which does not exist. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/229> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 14

[Einstein Toolkit] #283: Update and make CoreDoc.pdf available in the EinsteinToolkit website
by Einstein Toolkit 10 May '13

10 May '13

#283: Update and make CoreDoc.pdf available in the EinsteinToolkit website -------------------------------------+-------------------------------------- Reporter: bmundim | Owner: Type: enhancement | Status: new Priority: minor | Milestone: Component: EinsteinToolkit website | Version: Keywords: | -------------------------------------+-------------------------------------- The advanced concepts document: http://cactuscode.org/documentation/CoreDoc.pdf should be updated and made available in the ET website, both in pdf and html. Does anyone know where its .tex file version is located? Thanks, Bruno. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/283> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 16

[Einstein Toolkit] #322: SimFactory metadata deleted by periodic filesystem purges
by Einstein Toolkit 19 Apr '13

19 Apr '13

#322: SimFactory metadata deleted by periodic filesystem purges -------------------------+-------------------------------------------------- Reporter: hinder | Owner: mthomas Type: enhancement | Status: new Priority: minor | Milestone: Component: SimFactory | Version: Keywords: | -------------------------+-------------------------------------------------- Production filesystems are subject to periodic purges (typically on the order of weeks or months) where data which has not been accessed recently is deleted. This means that it is possible for some restarts of very long-running simulations to be deleted by the system. This can be addressed by an automated archiving system, but such a system does not address the problem that the simulation metadata directory (currently called SIMFACTORY) and any restarts which have not been run yet, will also be purged. This would make it impossible to submit future restarts and limits the number of chained restarts you can submit to the purge time of the system. One possibility to solve this problem would be to store a backup, or "shadow" copy of all the simulation metadata in a non-volatile location. This could be the user's home directory, or a "work" directory which is not purged. The details would need to be worked out. This is not a serious issue yet. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/322> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 4

[Einstein Toolkit] #163: Assertion `tl>=0 and tl<timelevels' failed error
by Einstein Toolkit 13 Nov '12

13 Nov '12

#163: Assertion `tl>=0 and tl<timelevels' failed error ------------------------------------+--------------------------------------- Reporter: azebrowski@… | Owner: eschnett Type: defect | Status: new Priority: major | Milestone: Component: Carpet | Version: Keywords: | ------------------------------------+--------------------------------------- I'm currently running a Cactus simulation based off the ET mclachlan parameter file. I have some custom thorns which force checkpointing every iteration, and then write new parameter files. The new parameter files are used to run specific functions from the host simulation ("spawning"), but I'm having some problems resuming simulations. Currently, I get this error when resuming: INFO (Carpet): GF: rhs: 818k active, 1440k owned (+76%), 1896k total (+32%), 328 steps/time cactus_sim: /home/azebrowski/Cactus/arrangements/Carpet/CarpetLib/src/th.hh:79: double th::get_time(int, int, int) const: Assertion `tl>=0 and tl<timelevels' failed. [cyder:32759] *** Process received signal *** [cyder:32759] Signal: Aborted (6) I'm guessing there's a parameter I'm not setting properly in my child simulation, could anyone give me a pointer to where I should be looking? I looked for things relating to timelevels in the host/spawned parameter files, but didn't see anything that stood out. My parameter files used and full output are attached to this email, with the disclaimer that I modified the spawned parameter file to run every function instead of skipping some in an attempt to bypass any problems that could be caused by skipping some Carpet function on accident. I've made a bzipped tarball containing the checkpointed data from the simulation. It contains several parameter files. The parameter file of interest here is spawn.par, as it doesn't use any of my custom code but still causes Cactus to abort with an error. I left the other parameter files in on the off chance that I might need to refer to them later. Here is the source parameter file, which creates the spawned simulation: http://www.cct.lsu.edu/~azebrowski/ml-ahfinder-spawn.par Here is the spawned simulation's parameter file: http://www.cct.lsu.edu/~azebrowski/spawn.par Here is the full checkpointed data and another copy of the spawned parameter file: http://www.cct.lsu.edu/~azebrowski/data.tar.bz2 Other information: I ran the simulation using OpenMP with 12 cores to generate the checkpointed data. I've also tried MPI, but that didn't seem to make a difference. Thornlist: http://www.cct.lsu.edu/~azebrowski/ThornList gcc: azebrowski@cyder:~/Cactus$ gcc -v Using built-in specs. Target: x86_64-linux-gnu Configured with: ../src/configure -v --with-pkgversion='Ubuntu 4.4.3-4ubuntu5' --with-bugurl=file:///usr/share/doc/gcc-4.4/README.Bugs --enable-languages=c,c++,fortran,objc,obj-c++ --prefix=/usr --enable- shared --enable-multiarch --enable-linker-build-id --with-system-zlib --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --with-gxx-include-dir=/usr/include/c++/4.4 --program-suffix=-4.4 --enable-nls --enable-clocale=gnu --enable-libstdcxx-debug --enable-plugin --enable-objc-gc --disable-werror --with-arch-32=i486 --with-tune=generic --enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu Thread model: posix gcc version 4.4.3 (Ubuntu 4.4.3-4ubuntu5) Fortran is gfortran-4.4 I'm using the Mercurial version of Carpet, and the ET development thorns. If you need more information, please let me know. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/163> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 13

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

Trac April 2011