#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
#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
#626: Recovery fails in AHFinderDirect RecoverML with out-of-bounds assertion in
CarpetLib
--------------------+-------------------------------------------------------
Reporter: rhaas | Owner: eschnett
Type: defect | Status: new
Priority: major | Milestone: ET_2011_10
Component: Carpet | Version:
Keywords: |
--------------------+-------------------------------------------------------
when trying to recover in AHFinderDirect's RecoverML test (parfiles
attached) I get:
{{{
cactus_et:
/home/rhaas/ET_2011_10/arrangements/Carpet/CarpetLib/src/th.hh:79: double
th::get_time(int, int, int) const: Assertion `tl>=0 and tl<timelevels'
failed.
}}}
After some debuggin I traced this down to the metric which in
CarpetIOHDF5/src/Input.cc:762 is reported (by gf->timelevels (ml, rl)) to
have three timelevels. However the timelevels member of gf->t (a th) gives
the number of timelevels as two
{{{
gf->t.timelevels
$28 = 2
}}}
Since timelevels is new in Carpet/Hg my suspicion would be that it is not
properly updated when gf->set_timelevels is called (the comments in th.hh
seem to indicated that it is assumed to be const which seems odd given
that ggf::set_timelevels exists).
I don't understand enough of Carpet to fix or further debug this. Marking
its as major and release relevant in case it is actually a Carpet bug.
--
Ticket URL: <https://trac.einsteintoolkit.org/ticket/626>
Einstein Toolkit <http://einsteintoolkit.org>
The Einstein Toolkit
#652: CACTUS_CONFIGS_DIR should be documented
-------------------------+--------------------------------------------------
Reporter: knarf | Owner:
Type: enhancement | Status: new
Priority: minor | Milestone:
Component: Cactus | Version:
Keywords: |
-------------------------+--------------------------------------------------
At the moment CACTUS_CONFIGS_DIR is only mentioned in doc/FAQ. It should
be documented in the regular documentation as well.
--
Ticket URL: <https://trac.einsteintoolkit.org/ticket/652>
Einstein Toolkit <http://einsteintoolkit.org>
The Einstein Toolkit
#605: Simfactory does not find the right 'path' for symlinked cactus directories
------------------------+---------------------------------------------------
Reporter: knarf | Owner: eschnett
Type: defect | Status: new
Priority: minor | Milestone: ET_2011_10
Component: SimFactory | Version: development version
Keywords: |
------------------------+---------------------------------------------------
Simfactory currently does not detect the 'right' path to a Cactus
sourcetree if this is from within a symlink, e.g. Cactus ->
/mnt/data/Cactus. This is because while `pwd` returns '/home/user/Cactus',
simfactory uses a wrapper to the C-library getcwd(), which dereferences
symlinks. Simfactory then gets '/mnt/data/Cactus' and tries to use this
path on remote machines when syncing - which of course does not work.
The attached patch fixes this by using os.environ.get("PWD") and, if this
is not defined, using os.getcwd() as workaround.
--
Ticket URL: <https://trac.einsteintoolkit.org/ticket/605>
Einstein Toolkit <http://einsteintoolkit.org>
The Einstein Toolkit
#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
#780: missing small packages
----------------------------------------------+-----------------------------
Reporter: knarf | Owner: dcastl2
Type: enhancement | Status: new
Priority: major | Milestone:
Component: Einstein Toolkit Virtual Machine | Version:
Keywords: |
----------------------------------------------+-----------------------------
Some tools to be installed:
mmv
screen
tmux
texlive (probably quite large, but also probably necessary)
--
Ticket URL: <https://trac.einsteintoolkit.org/ticket/780>
Einstein Toolkit <http://einsteintoolkit.org>
The Einstein Toolkit
#456: Ensure functions are not defined twice
-------------------------+--------------------------------------------------
Reporter: hinder | Owner:
Type: enhancement | Status: new
Priority: major | Milestone:
Component: Cactus | Version:
Keywords: |
-------------------------+--------------------------------------------------
When multiple source files define non-static functions with the same name,
these are all compiled together into the resulting executable. Which one
gets called is not predictable by the user.
This can happen if a user copies a thorn, modifies it slightly, and
compiles both thorns into the same configuration. This can lead to *very*
difficult-to-find bugs, and it would be helpful if Cactus was able to
prevent this, or at least to mitigate the problem.
At the CST level, Cactus should be able to tell that there are two thorns
which schedule functions with the same name. At the moment, this is not
caught. I propose that this should be a fatal error, as there is no way
to predict which function will be called eventually.
This will solve the problem in some cases, but not in the case where there
are instances of duplicate function names which are not scheduled. It
should be possible to scan the object/library files using standard tools
(nm etc) to determine if there are multiple globally visible symbols with
the same name. There might even be standard tools for this purpose.
Doing this in a portable way might not be straightforward, but having an
implementation for Linux, for example, would catch the majority of cases.
--
Ticket URL: <https://trac.einsteintoolkit.org/ticket/456>
Einstein Toolkit <http://einsteintoolkit.org>
The Einstein Toolkit
#447: simfactory 1.0 always uses -L 3
----------------------------------------------+-----------------------------
Reporter: alexander.beck-ratzka@… | Owner: eschnett
Type: defect | Status: new
Priority: major | Milestone:
Component: SimFactory | Version:
Keywords: |
----------------------------------------------+-----------------------------
The perl version of simfactory always uses the debugging loglevel for
simulations. The loglevel of a cactus simulation can be specified by
setting -L to a value between 0 (none) and 3 (debug). While the cactus
default is 0, simfactory sets it to 3. The debug loglevel could lead to
huge output files.
I would suggest to set it to the cactus default, and allow a user to
increase it.
--
Ticket URL: <https://trac.einsteintoolkit.org/ticket/447>
Einstein Toolkit <http://einsteintoolkit.org>
The Einstein Toolkit
#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