#394: Testsuite log file should contain more information
-------------------------+--------------------------------------------------
Reporter: hinder | Owner:
Type: enhancement | Status: new
Priority: minor | Milestone:
Component: Cactus | Version:
Keywords: testsuites |
-------------------------+--------------------------------------------------
It is useful to look at the testsuite log file for information about how
the tests were run. For example, which compiler was used, and with what
compiler options. We need to balance this against providing information
which will always change, making diffs hard to read.
The most extreme case would be to output all make variables. Maybe better
would be to output CC, CFLAGS, CXX, etc. Another option would be to parse
these and say "intel compiler", "gcc", "pgi" etc.
--
Ticket URL: <https://trac.einsteintoolkit.org/ticket/394>
Einstein Toolkit <http://einsteintoolkit.org>
The Einstein Toolkit
#382: SimFactory home directory on Kraken is too specific
------------------------+---------------------------------------------------
Reporter: hinder | Owner: mthomas
Type: defect | Status: new
Priority: major | Milestone: ET_2011_05
Component: SimFactory | Version:
Keywords: |
------------------------+---------------------------------------------------
The mdb entry for Kraken in SimFactory has
'sourcebasedir' => '/nics/b/home/@USER@',
My home directory is
'/nics/d/home/@USER@'
Either we could leave the source base dir as unset to force the user to
set it, or we could automatically detect the location of the user's home
directory (better).
--
Ticket URL: <https://trac.einsteintoolkit.org/ticket/382>
Einstein Toolkit <http://einsteintoolkit.org>
The Einstein Toolkit
#584: Use of uninitialized value in concatenation
------------------------+---------------------------------------------------
Reporter: hinder | Owner: eschnett
Type: defect | Status: new
Priority: major | Milestone:
Component: SimFactory | Version:
Keywords: |
------------------------+---------------------------------------------------
After failing to check out a thornlist (the current einsteintoolkit.th)
the automated build and test system re-runs GetComponents with --update.
On 27-Sep-2011, this gave the error:
{{{
Use of uninitialized value in concatenation (.) or string at
./GetComponents line 2514.
}}}
This line seems to be
{{{
$url = "(".$component{"URL"}.")|(".$component{"AUTH_URL"}.")";
}}}
Is the problem that SimFactory doesn't have an AUTH_URL?
I'm attaching the log of the testsuite script. I don't know if the error
is serious or not, since the checkout has already failed.
--
Ticket URL: <https://trac.einsteintoolkit.org/ticket/584>
Einstein Toolkit <http://einsteintoolkit.org>
The Einstein Toolkit
#641: Parameter files and thornlists could be tested as part of the release
process
-------------------------+--------------------------------------------------
Reporter: hinder | Owner:
Type: enhancement | Status: new
Priority: minor | Milestone: ET_2012_05
Component: Other | Version:
Keywords: |
-------------------------+--------------------------------------------------
There are a number of parameter files and thornlists included as examples
with thorns in the ET, and in Cactus. Would it be feasible to have these
tested as part of the release process? For example, they should run
without crashing or missing thorns, should not trigger NaNs etc, and we
should minimise any warnings that are emitted. It would be nice to
automate this, though it probably requires a cluster, so would be distinct
from the usual test suite procedure, due to requiring more memory than
tests.
Something to think about for the next release.
--
Ticket URL: <https://trac.einsteintoolkit.org/ticket/641>
Einstein Toolkit <http://einsteintoolkit.org>
The Einstein Toolkit
#241: Thorns should be able to specify implementation versions, and other thorns
should be able to depend on those
-------------------------+--------------------------------------------------
Reporter: knarf | Owner:
Type: enhancement | Status: new
Priority: minor | Milestone:
Component: Cactus | Version:
Keywords: |
-------------------------+--------------------------------------------------
Cactus thorns implement 'implementations', and other thorns can then
depend on particular implementations being present. However, quite often
those are updated, and incompatibilities occur. Usually this is resolved
by the developer in both thorns - the implementing and the using thorn.
However, a user might just update one of them, and Cactus would not catch
this error. Thus, I suggest to think about, and implement how to:
- specify implementation versions
e.g. IMPLEMENTS: Cactus (4.0)
The version string within () would have be sorted in an intelligent way
to allow
comparisons [1].
- specify dependencies on particular versions of other implementations
In particular I suggest the following dependencies: depends, and
conflicts, both
with comparisons < <= == >= > !=
e.g. DEPENDS: Cactus (>= 4.0)
DEPENDS: BadImplementation (!=3.14) <-- this introduces a
dependency
CONFLICTS: BadImplementation (==3.14) <-- this doesn't introduce
a depencency
[1] First the initial part of each string consisting entirely of non-digit
characters is determined. These two parts (one of which may be empty) are
compared lexically. If a difference is found it is returned. The lexical
comparison is a comparison of ASCII values modified so that all the
letters sort earlier than all the non-letters. Then the initial part of
the remainder of each string which consists entirely of digit characters
is determined. The numerical values of these two parts are compared, and
any difference found is returned as the result of the comparison. For
these purposes an empty string (which can only occur at the end of one or
both version strings being compared) counts as zero.
These two steps (comparing and removing initial non-digit strings and
initial digit strings) are repeated until a difference is found or both
strings are exhausted.
--
Ticket URL: <https://trac.einsteintoolkit.org/ticket/241>
Einstein Toolkit <http://einsteintoolkit.org>
The Einstein Toolkit
#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
#649: simfactory should create the "simulations" directory
------------------------+---------------------------------------------------
Reporter: rhaas | Owner: eschnett
Type: defect | Status: new
Priority: minor | Milestone:
Component: SimFactory | Version:
Keywords: |
------------------------+---------------------------------------------------
when following the new users tutorial one gets:
{{{
[rhaas@qb1 Cactus]$ ./simfactory/bin/sim submit static_tov
--parfile=par/static_tov.par --procs=32 --walltime=8:0:0
Parameter file: /home/rhaas/Cactus/par/static_tov.par
Error: could not access simulation base directory
/scratch/rhaas/simulations for reading and writing
Aborting Simfactory.
[137450 refs]
}}}
This happens each time I set up a fresh simfactory on a machine. It might
be useful if simfactory would create the simulation base directory if it
does not exist.
--
Ticket URL: <https://trac.einsteintoolkit.org/ticket/649>
Einstein Toolkit <http://einsteintoolkit.org>
The Einstein Toolkit
#428: Forbid configuration names ending in -reconfig
----------------------+-----------------------------------------------------
Reporter: eschnett | Owner:
Type: defect | Status: new
Priority: minor | Milestone:
Component: Cactus | Version:
Keywords: |
----------------------+-----------------------------------------------------
I accidentally created a Cactus configuration with a name like "sim-
reconfig". This confuses Cactus, because the command "make sim-reconfig"
can then mean either to build the "sim-reconfig" configuration, or to
reconfigure the "sim" configuration.
Cactus should catch and forbid these cases.
This is probably most cleanly handled by using a script instead of a
Makefile to interpret the user commands.
--
Ticket URL: <https://trac.einsteintoolkit.org/ticket/428>
Einstein Toolkit <http://einsteintoolkit.org>
The Einstein Toolkit
#582: Semi-automatically split McLachlan's calculations
-----------------------------------+----------------------------------------
Reporter: eschnett | Owner:
Type: enhancement | Status: new
Priority: major | Milestone:
Component: EinsteinToolkit thorn | Version:
Keywords: |
-----------------------------------+----------------------------------------
Split McLachlan's calculations semi-automatically in two ways: (a) by
variable, so that e.g. dot[g] and dot[K] are calculated separately, and
(b) by pattern, so that advection terms, dissipation, and "everything
else" are calculated separately. Also introduce parameters to choose which
routines are called at run time.
This is somewhat a work in progress, in that the patch is good, but the
API defined to split kernels is more complex and less failsafe than it
should be.
--
Ticket URL: <https://trac.einsteintoolkit.org/ticket/582>
Einstein Toolkit <http://einsteintoolkit.org>
The Einstein Toolkit
#499: Prolongation fails with vectorisation enabled
--------------------+-------------------------------------------------------
Reporter: hinder | Owner: eschnett
Type: defect | Status: new
Priority: major | Milestone:
Component: Carpet | Version:
Keywords: |
--------------------+-------------------------------------------------------
The development version of Carpet uses vectorisation to speed-up
prolongation. This fails with various errors, including corruption of the
malloc heap.
--
Ticket URL: <https://trac.einsteintoolkit.org/ticket/499>
Einstein Toolkit <http://einsteintoolkit.org>
The Einstein Toolkit