#207: Cactus should have an option to store the mpirun command needed to run test
cases
-------------------------+--------------------------------------------------
Reporter: eschnett | Owner:
Type: enhancement | Status: new
Priority: minor | Milestone:
Component: Cactus | Version:
Keywords: |
-------------------------+--------------------------------------------------
Cactus should be able to remember from configuration the mpirun command
syntax needed to run test cases. This would simplify running test cases,
which could then probably even be automated.
--
Ticket URL: <https://trac.einsteintoolkit.org/ticket/207>
Einstein Toolkit <http://einsteintoolkit.org>
The Einstein Toolkit
#333: The ADMBase variables are not initialized after regridding
--------------------+-------------------------------------------------------
Reporter: knarf | Owner:
Type: defect | Status: new
Priority: major | Milestone:
Component: Cactus | Version:
Keywords: |
--------------------+-------------------------------------------------------
Ian Hawke: The point is that no BCs are applied to ADMBase variables, so
they're never SYNC'd, so never initialized on refined grids.
Ian sent a patch which I extended at bit and attached to this ticket.
Please review.
--
Ticket URL: <https://trac.einsteintoolkit.org/ticket/333>
Einstein Toolkit <http://einsteintoolkit.org>
The Einstein Toolkit
#366: New thorn TestPar
-------------------------+--------------------------------------------------
Reporter: eschnett | Owner:
Type: enhancement | Status: new
Priority: minor | Milestone:
Component: Cactus | Version:
Keywords: |
-------------------------+--------------------------------------------------
I enclose a new thorn:
Test the parameter file parser in Cactus, in particular multi-line string
parameters and comments in these.
--
Ticket URL: <https://trac.einsteintoolkit.org/ticket/366>
Einstein Toolkit <http://einsteintoolkit.org>
The Einstein Toolkit
#63: create separate tracs on trac.cactuscode.org and trac.cfdtoolkit.org
--------------------+-------------------------------------------------------
Reporter: knarf | Owner:
Type: task | Status: new
Priority: minor | Milestone:
Component: Cactus | Version:
Keywords: |
--------------------+-------------------------------------------------------
We need separate tracs on trac.cactuscode.org and trac.cfdtoolkit.org,
including ssl certificates and the complete rest of the setup.
--
Ticket URL: <https://trac.einsteintoolkit.org/ticket/63>
Einstein Toolkit <http://einsteintoolkit.org>
The Einstein Toolkit
#233: Unable to complete an ET checkout without SVN network errors
--------------------+-------------------------------------------------------
Reporter: hinder | Owner:
Type: defect | Status: new
Priority: major | Milestone:
Component: Other | Version:
Keywords: |
--------------------+-------------------------------------------------------
I am running an automated build and test system every night which attempts
to check out the Einstein Toolkit thornlist. Every night, I get error
messages from at least one thorn of the form:
Checking out module: CactusNumerical/Cartoon2D
from repository:
http://svn.cactuscode.org/arrangements/CactusNumerical/Cartoon2D/trunk
into: ./arrangements
svn: REPORT of '/arrangements/CactusNumerical/Cartoon2D/!svn/vcc/default':
Could not read response body: connection was closed by server.
(http://svn.cactuscode.org)
Typically, three or more thorns will exhibit this problem. All the
following repositories have exhibited this problem since 11th January
2011:
CactusArchive/ADM
CactusElliptic/EllBase
CactusNumerical/Cartoon2D
CactusNumerical/Dissipation
CactusNumerical/InterpToArray
CactusNumerical/RotatingSymmetry180
CactusNumerical/RotatingSymmetry90
EinsteinInitialData/Exact
EinsteinInitialData/IDAnalyticBH
EinsteinInitialData/TOVSolver
EinsteinInitialData/TwoPunctures
LSUThorns/QuasiLocalMeasures
manifest
simfactory
I assume that there is some problem with the SVN server or our network
connection to it that is making it so unreliable. Am I the only one?
--
Ticket URL: <https://trac.einsteintoolkit.org/ticket/233>
Einstein Toolkit <http://einsteintoolkit.org>
The Einstein Toolkit
#317: Unproper bevaviour of sim submit when changing the parfile
----------------------------------------------+-----------------------------
Reporter: alexander.beck-ratzka@… | Owner: mthomas
Type: defect | Status: new
Priority: major | Milestone:
Component: SimFactory | Version: ET_2010_11
Keywords: |
----------------------------------------------+-----------------------------
If I make changes to the parfile of my simulation, and call then
simfactory submit with the option --parfile=newpar, simfactory does not
take this parfile. Instead of this, simfactory uses an old parfile from
the old output-xxxx directory in my simualations direrctory.
This usage of the old parfile might be wished. However, if this is the
case, simfactory must complain if invoked with the option "parfile=...".
But simfactory does not complain.
In my case, the parfile has been modfied, but I am using the same name.
--
Ticket URL: <https://trac.einsteintoolkit.org/ticket/317>
Einstein Toolkit <http://einsteintoolkit.org>
The Einstein Toolkit
#370: New TRAC status "please commit"
----------------------------------+-----------------------------------------
Reporter: eschnett | Owner:
Type: enhancement | Status: new
Priority: major | Milestone:
Component: EinsteinToolkit trac | Version:
Keywords: |
----------------------------------+-----------------------------------------
We seem to have tickets stuck in the "review" stage that effectively have
been reviewed, but have not been applied yet. We may want to introduce a
new status for that.
--
Ticket URL: <https://trac.einsteintoolkit.org/ticket/370>
Einstein Toolkit <http://einsteintoolkit.org>
The Einstein Toolkit
#123: Run a syntax checker in a pre-commit hook
------------------------+---------------------------------------------------
Reporter: eschnett | Owner: mthomas
Type: defect | Status: new
Priority: major | Milestone:
Component: SimFactory | Version:
Keywords: |
------------------------+---------------------------------------------------
I am getting annoyed by the frequent syntax errors in SimFactory that used
to be caught by Perl and are now not caught by Python. It would be ideal
if syntax checking could be built into SimFactory, so that it executes
automatically during startup if that isn't too slow.
--
Ticket URL: <https://trac.einsteintoolkit.org/ticket/123>
Einstein Toolkit <http://einsteintoolkit.org>
The Einstein Toolkit
#124: Implement a testing mechanism for simfactory
-------------------------+--------------------------------------------------
Reporter: hinder | Owner: mthomas
Type: enhancement | Status: new
Priority: major | Milestone:
Component: SimFactory | Version:
Keywords: |
-------------------------+--------------------------------------------------
Currently there is no easy way to check that a change to simfactory hasn't
broken critical functionality. A system could be introduced to run
through each command and check that it does the right thing. It won't be
possible to check every single combination of possible options, but the
most commonly used options should be tested.
A first attempt could involve testing that the commands work locally on
the current machine. This would involve submitting jobs and testing that
they have the expected behaviour. On busy machines, this means that the
tests could potentially take a long time to complete.
Remote submission could be tested by running these tests from a central
location (e.g. the developer's workstation or laptop).
We could also include a python correctness checking step in these tests
(e.g. using pychecker or pylint).
--
Ticket URL: <https://trac.einsteintoolkit.org/ticket/124>
Einstein Toolkit <http://einsteintoolkit.org>
The Einstein Toolkit
#180: Reduce disk space used by checkpoints
-------------------------+--------------------------------------------------
Reporter: hinder | Owner: mthomas
Type: enhancement | Status: new
Priority: major | Milestone:
Component: SimFactory | Version:
Keywords: |
-------------------------+--------------------------------------------------
Currently simfactory stores the checkpoints for each restart in their own
directory. This means that the Cactus mechanism for deleting all but the
most recent N checkpoints does not see the previous checkpoints. This
means that you can easily run out of quota space when doing very long
simulations.
One solution to this would be for SimFactory to store the checkpoints in a
directory above the output-NNNN directories and make the current
checkpoints directories under output-NNNN symbolic links to the common
directory. This way, all restarts would see the same directory for
checkpoint files, and Cactus could clean up the old checkpoints. The
current hardlinking mechanism would not be required any more. This
solution might be undesirable because it means that each restart is no
longer independent.
Another solution would be to give simfactory an option to delete old
checkpoint files from previous restarts when a job starts. This would
duplicate the functionality already available in Cactus.
--
Ticket URL: <https://trac.einsteintoolkit.org/ticket/180>
Einstein Toolkit <http://einsteintoolkit.org>
The Einstein Toolkit