#342: Add CCTK_POINTER_SIZE make variable
-------------------------+--------------------------------------------------
Reporter: hinder | Owner:
Type: enhancement | Status: new
Priority: minor | Milestone:
Component: Cactus | Version:
Keywords: flesh |
-------------------------+--------------------------------------------------
It is sometimes necessary to know in a thorn's configuration script
whether 32 bit or 64 bit code is to be generated. See the discussion in
ticket #339.
The attached patch adds a CCTK_POINTER_SIZE make variable to
make.config.defn which is accessible as a shell variable to configuration
scripts. This will be 4 when compiling for 32 bit, and 8 when compiling
for 64 bit.
I am not very expert in autoconf, so the patch might have to be modified.
It seems to work, however.
I have not included the generated configure script - this should be
generated by the person who commits the final patch.
--
Ticket URL: <https://trac.einsteintoolkit.org/ticket/342>
Einstein Toolkit <http://einsteintoolkit.org>
The Einstein Toolkit
#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