#1718: MemSpeed: Re-use allocated memory
-----------------------------------+----------------------------------------
Reporter: eschnett | Owner:
Type: enhancement | Status: new
Priority: minor | Milestone:
Component: EinsteinToolkit thorn | Version: development version
Keywords: |
-----------------------------------+----------------------------------------
Allocating memory is slow. In thorn MemSpeed, we should re-use memory that
has been allocated instead of allocating new memory for each benchmark.
--
Ticket URL: <https://trac.einsteintoolkit.org/ticket/1718>
Einstein Toolkit <http://einsteintoolkit.org>
The Einstein Toolkit
#331: SimFactory does not abort if it has been given a nonexistent optionlist
------------------------+---------------------------------------------------
Reporter: hinder | Owner: mthomas
Type: defect | Status: new
Priority: major | Milestone:
Component: SimFactory | Version:
Keywords: |
------------------------+---------------------------------------------------
If I specify a nonexistent optionlist in a machine's .ini file, I get the
warning
Info: optionlist is: None
Warning: no option list specified, using blank option list
This is incorrect. I have specified an optionlist, but it has not been
found, which indicates an error. In this case I would expect a fatal
error.
--
Ticket URL: <https://trac.einsteintoolkit.org/ticket/331>
Einstein Toolkit <http://einsteintoolkit.org>
The Einstein Toolkit
#228: Make it easier for users to create accounts on TRAC
----------------------------------+-----------------------------------------
Reporter: hinder | Owner:
Type: enhancement | Status: new
Priority: major | Milestone:
Component: EinsteinToolkit trac | Version:
Keywords: |
----------------------------------+-----------------------------------------
Currently, in order to interact fully with TRAC, it is necessary to have a
CCT account. I would prefer that all potential users of the ET/Cactus
TRAC could create accounts. This way, it would be possible for all bug
reporters to be notified of changes to the tickets they create, and makes
it more likely that they will respond to requests for further information
and confirmations of fixes.
--
Ticket URL: <https://trac.einsteintoolkit.org/ticket/228>
Einstein Toolkit <http://einsteintoolkit.org>
The Einstein Toolkit
#270: Need web instructions for building on a new machine
-------------------------------------+--------------------------------------
Reporter: eschnett | Owner:
Type: defect | Status: new
Priority: major | Milestone:
Component: EinsteinToolkit website | Version:
Keywords: |
-------------------------------------+--------------------------------------
We should have instructions on the web that explain how to build the
Einstein Toolkit on a new machine, i.e. a machine for which we don't have
a SimFactory entry already. This seems to be a fairly common case for new
users, who rather want to build on their own machine instead of on Queen
Bee.
This should probably concentrate on configuring Cactus first, i.e. on
configuring SimFactory for building a configuration. Job submission etc.
should come later.
--
Ticket URL: <https://trac.einsteintoolkit.org/ticket/270>
Einstein Toolkit <http://einsteintoolkit.org>
The Einstein Toolkit
#1804: Provide an Einstein Toolkit User Guide
-------------------------+--------------------------------------------------
Reporter: hinder | Owner:
Type: enhancement | Status: new
Priority: minor | Milestone:
Component: Other | Version: development version
Keywords: |
-------------------------+--------------------------------------------------
We currently have documentation for individual thorns, but there is no
documentation for the toolkit as a whole, describing how best to
accomplish certain tasks. The [http://arxiv.org/abs/1111.3344 Einstein
Toolkit paper] is a good starting point, but it is a static document, and
is not quite at the level of documentation. I propose to take the paper
and convert it into a user guide for the ET. It should not replicate
detailed information already available in thorn documentation (rather it
should link to it), but should provide a high level overview. It should
also contain best practices for working with the ET. This would be the
first point of reference for new users of the toolkit.
--
Ticket URL: <https://trac.einsteintoolkit.org/ticket/1804>
Einstein Toolkit <http://einsteintoolkit.org>
The Einstein Toolkit
#1263: Multipole does not handle variable names correctly
-----------------------------------+----------------------------------------
Reporter: hinder | Owner:
Type: defect | Status: new
Priority: major | Milestone:
Component: EinsteinToolkit thorn | Version:
Keywords: Multipole |
-----------------------------------+----------------------------------------
When you specify variables for Multipole to decompose, you have the option
of giving it a "name" for the variable to be used in the output filename.
This is useful if you are decomposing Psi4r, with imaginary part Psi4i,
and want the file to just be named "Psi4". If you don't specify a name,
it is supposed to use the original variable name. However, at the moment,
this last part seems to be broken.
--
Ticket URL: <https://trac.einsteintoolkit.org/ticket/1263>
Einstein Toolkit <http://einsteintoolkit.org>
The Einstein Toolkit
#1201: Incorrect dtshift in Exact with shift_add_{x,y,z} parameters
-----------------------------------+----------------------------------------
Reporter: barry.wardell | Owner:
Type: defect | Status: new
Priority: major | Milestone:
Component: EinsteinToolkit thorn | Version:
Keywords: |
-----------------------------------+----------------------------------------
The Exact thorn has shift_add_{x,y,z} parameters for adding a constant to
the shift. Considering these as a coordinate transformation using a vector
v^i = [shift_add_x, shift_add_y, shift_add_z], such a transformation
should affect both the shift and its time derivative. This is because the
time derivative in the new coordinates differs from the time derivative in
the old coordinates by a term v^j d(beta^i)/dx^j. This is correctly
implemented as a 4D coordinate transformation in the EinsteinExact thorns
and I have verified that the difference relative to the Exact thorn is
given by this missing term.
--
Ticket URL: <https://trac.einsteintoolkit.org/ticket/1201>
Einstein Toolkit <http://einsteintoolkit.org>
The Einstein Toolkit
#1097: Describe Tmunu in GRHydro
-----------------------------------+----------------------------------------
Reporter: eschnett | Owner:
Type: defect | Status: new
Priority: major | Milestone:
Component: EinsteinToolkit thorn | Version:
Keywords: |
-----------------------------------+----------------------------------------
Describe in GRHydro's documentation how Tmunu is defined
--
Ticket URL: <https://trac.einsteintoolkit.org/ticket/1097>
Einstein Toolkit <http://einsteintoolkit.org>
The Einstein Toolkit
#660: Make MHD multipatch-aware
-----------------------------------+----------------------------------------
Reporter: tbode | Owner: tbode
Type: defect | Status: new
Priority: major | Milestone:
Component: EinsteinToolkit thorn | Version: development version
Keywords: |
-----------------------------------+----------------------------------------
At least the Con2PrimM routines need to be multipatch-aware.
--
Ticket URL: <https://trac.einsteintoolkit.org/ticket/660>
Einstein Toolkit <http://einsteintoolkit.org>
The Einstein Toolkit
#1690: The test system should treat a nonzero exit code from Cactus as a failure
--------------------+-------------------------------------------------------
Reporter: hinder | Owner:
Type: defect | Status: new
Priority: minor | Milestone:
Component: Cactus | Version: development version
Keywords: |
--------------------+-------------------------------------------------------
The test system seems to ignore the fact that Cactus exits with a nonzero
exit code. It displays
Cactus exited with error code 1
Please check the logfile...
No files created in test directory
Success: 0 files identical
And in the summary at the end, it treats this as a passing test. In this
case, there were no test reference files and no files output, because the
test (by design) does not produce any data, it just aborts if the test
fails.
--
Ticket URL: <https://trac.einsteintoolkit.org/ticket/1690>
Einstein Toolkit <http://einsteintoolkit.org>
The Einstein Toolkit