#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
#434: Keep track of masked-out volume in CarpetMask
-------------------------+--------------------------------------------------
Reporter: eschnett | Owner: eschnett
Type: enhancement | Status: new
Priority: minor | Milestone:
Component: Carpet | Version:
Keywords: |
-------------------------+--------------------------------------------------
Keep track of the volume that is masked out by CarpetMask, and take this
volume into account when checking in CarpetReduce that the integral over
the simulation domain equals the domain volume.
--
Ticket URL: <https://trac.einsteintoolkit.org/ticket/434>
Einstein Toolkit <http://einsteintoolkit.org>
The Einstein Toolkit
#361: delta_time when setting up ID with explicit time dependence
------------------------------------------+---------------------------------
Reporter: eloisa.bentivegna@… | Owner: eschnett
Type: defect | Status: new
Priority: minor | Milestone:
Component: Carpet | Version: ET_2010_11
Keywords: |
------------------------------------------+---------------------------------
In CallInitial, delta_time is used to calculate the time corresponding to
the different timelevels (line 399 of Carpet/src/Initialise.cc). At this
stage, though, delta_time is always equal to 1, leading to potentially
very separated initial-data slices when using init_each_timelevel and an
initial-data thorn that uses cctk_time explicitly. Should
cctkGH->cctk_delta_time be used here instead?
--
Ticket URL: <https://trac.einsteintoolkit.org/ticket/361>
Einstein Toolkit <http://einsteintoolkit.org>
The Einstein Toolkit
#323: GetComponents overwrites thorn list
---------------------------+------------------------------------------------
Reporter: eschnett | Owner: eric9
Type: defect | Status: new
Priority: critical | Milestone:
Component: GetComponents | Version:
Keywords: |
---------------------------+------------------------------------------------
I specified a thorn list located in the main Cactus directory.
GetComponents overwrote this thorn list with its own thorn list (the one
it generates automatically).
--
Ticket URL: <https://trac.einsteintoolkit.org/ticket/323>
Einstein Toolkit <http://einsteintoolkit.org>
The Einstein Toolkit
#517: archive CactusExternal
-------------------------+--------------------------------------------------
Reporter: knarf | Owner:
Type: enhancement | Status: new
Priority: minor | Milestone:
Component: Cactus | Version:
Keywords: |
-------------------------+--------------------------------------------------
We should move the CactusExternal thorns to archive. They cause trouble
and confusion where they are right now. This should happen for the next
Cactus release.
--
Ticket URL: <https://trac.einsteintoolkit.org/ticket/517>
Einstein Toolkit <http://einsteintoolkit.org>
The Einstein Toolkit
#176: Test parameter files without running them
-------------------------+--------------------------------------------------
Reporter: hinder | Owner:
Type: enhancement | Status: new
Priority: minor | Milestone:
Component: Cactus | Version:
Keywords: |
-------------------------+--------------------------------------------------
It would be useful to be able to check that the parameters of a run are OK
before running it. Since there can be long queue times on supercomputers,
it would be good to do this on a local machine which might not have as
much memory as is required for the full run. Currently, running the job
would cause memory exhaustion on the smaller machine.
One solution would be an additional command-line argument to Cactus
--exit-after-paramcheck which stops the run cleanly after the PARAMCHECK
Cactus bin. This is preferable to a new Cactus parameter, as it would not
require the parameter file to be modified. One could imagine this also
being potentially used by simfactory automatically when submitting a job
(though this would only work if you could run MPI executables on the head
node).
--
Ticket URL: <https://trac.einsteintoolkit.org/ticket/176>
Einstein Toolkit <http://einsteintoolkit.org>
The Einstein Toolkit
#535: Add autoconf macro to test C99 style variable declarations
-------------------------+--------------------------------------------------
Reporter: eschnett | Owner:
Type: enhancement | Status: new
Priority: major | Milestone:
Component: Cactus | Version:
Keywords: |
-------------------------+--------------------------------------------------
Many compilers don't support C99 style variable declarations in their
default settings. We should test this, add certain flags automatically if
we can, or abort with a clear error message otherwise.
--
Ticket URL: <https://trac.einsteintoolkit.org/ticket/535>
Einstein Toolkit <http://einsteintoolkit.org>
The Einstein Toolkit
#412: Split Appendices
-------------------------+--------------------------------------------------
Reporter: eschnett | Owner:
Type: enhancement | Status: new
Priority: minor | Milestone:
Component: Cactus | Version:
Keywords: |
-------------------------+--------------------------------------------------
Currently, the appendices of the users' guide are repeated into the
reference manual. This is somewhat confusing, and causes problems because
the appendices cannot easily reference other sections (e.g. "see page 15"
doesn't make sense since one doesn't know in which document this will be
read). I suggest to split the appendices and have some of them in the
users' guide while moving others into the reference manual, so that each
appendix is included in only one document
--
Ticket URL: <https://trac.einsteintoolkit.org/ticket/412>
Einstein Toolkit <http://einsteintoolkit.org>
The Einstein Toolkit
#531: Problem with adding/removing configuration.ccl files
----------------------+-----------------------------------------------------
Reporter: eschnett | Owner:
Type: defect | Status: new
Priority: minor | Milestone:
Component: Cactus | Version:
Keywords: |
----------------------+-----------------------------------------------------
Cactus doesn't handle well adding or removing configuration.ccl files.
When a new configuration.ccl file is added, Cactus ignores it until the
next "rebuild" (i.e. until another ccl file changes, until the thorn list
changes, or until the user calls *-rebuild explicitly). When a
configuration.ccl file is removed, make aborts with an error message, and
a rebuild is forced.
One way to remedy this would be to have (empty) configuration.ccl file in
all thorns. After all, param.ccl and schedule.ccl files also need to be
present even if they are empty. This would also remove a bit of complex
logic from the Cactus make system.
--
Ticket URL: <https://trac.einsteintoolkit.org/ticket/531>
Einstein Toolkit <http://einsteintoolkit.org>
The Einstein Toolkit