#1974: Add WVUThorns_Diagnostics to the ET
--------------------------------+-------------------------------------------
Reporter: zachetie@… | Owner:
Type: enhancement | Status: new
Priority: unset | Milestone:
Component: Other | Version: development version
Keywords: |
--------------------------------+-------------------------------------------
I have open-sourced a very useful set of diagnostic routines for GRMHD,
GRHD, and even vacuum simulations.
The thorns are available here:
https://bitbucket.org/zach_etienne/wvuthorns_diagnostics
Here's a brief description of each thorn:
Brief description of included thorns
'''Seed_Magnetic_Fields-modified''' Extended Seed_Magnetic_Fields thorn
for binary neutron stars. Supercedes Seed_Magnetic_Fields thorn.
'''Meudon_Bin_NS-modified''' Modifications to Meudon BNS initial data
thorn to disable the overwriting of initial lapse/shift, which acts to
significantly reduce coordinate eccentricity. Supercedes Meudon_Bin_NS
thorn.
'''VolumeIntegrals_GRMHD''' Nice GRMHD volume integration thorn, currently
depends on IllinoisGRMHD and Carpet. Performs volume integrals on
arbitrary "Swiss-cheese"-like topologies, and even interoperates with
Carpet to track NS centers of mass.
'''VolumeIntegrals_vacuum''' Nice GRMHD volume integration thorn,
currently depends on ML_BSSN. There is a bit of code duplication and
duplicated functionality between VI_GRMHD and VI_vacuum, to ensure that
VI_vacuum can be used without enabling a GRMHD code. There is probably a
better way of doing this, but I haven't had the time to think deeply about
this.
'''particle_tracerET''' Solves the ODE \partial_t x^i = v^i for typically
thousands of tracer particles, using an RK4 integration atop the current
timestepping. E.g., one RK4 substep in the particle integration might
occur every 16 RK4 substeps in the GRMHD evolution. These tracer particle
positions are quite useful for visualizing magnetic field lines in a
consistent way from frame-to-frame in a movie (recall that in the GRMHD
approximation, the magnetic field lines stay attached the fluid elements
they thread ["Flux Freezing"]). Note that the velocity must be consistent
with the velocity appearing in the GRMHD induction equation. This thorn
reads in the HydroBase vel[] vector gridfunction, which assumes the
Valencia formalism, and converts it into the induction equation velocity.
'''smallbPoynET''' Computes b^i^, b^2^, and three spatial components of
Poynting flux. It also computes (-1-u,,0,,), which is useful for tracking
unbound matter.
--
Ticket URL: <https://trac.einsteintoolkit.org/ticket/1974>
Einstein Toolkit <http://einsteintoolkit.org>
The Einstein Toolkit
#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
#1889: correct finding normalization value for relerr compuation
--------------------+-------------------------------------------------------
Reporter: rhaas | Owner:
Type: defect | Status: new
Priority: major | Milestone:
Component: Cactus | Version: development version
Keywords: |
--------------------+-------------------------------------------------------
Before it would have taken the larger of the abs value of the new and
old data of the last data set rather than the largest abs value of the
new and old data of all the datasets.
This will make relative errros smaller and will be particularly
noticeable in cases where the last dataset was small or zero.
This should get rid of the "Error, how did I get here" warnings (that
really indicated an logic error).
--
Ticket URL: <https://trac.einsteintoolkit.org/ticket/1889>
Einstein Toolkit <http://einsteintoolkit.org>
The Einstein Toolkit
#1885: support bibtex in thorn documenation files
-------------------------+--------------------------------------------------
Reporter: rhaas | Owner:
Type: enhancement | Status: new
Priority: optional | Milestone:
Component: Cactus | Version: development version
Keywords: |
-------------------------+--------------------------------------------------
The pull request
https://bitbucket.org/cactuscode/cactus/pull-requests/new?source=rhaas
/docs-bibtex&t=1
adds support for bibtex to Cactus' documentation system.
--
Ticket URL: <https://trac.einsteintoolkit.org/ticket/1885>
Einstein Toolkit <http://einsteintoolkit.org>
The Einstein Toolkit
#2008: NaNs when running static tov on >40 cores
-----------------------------------+----------------------------------------
Reporter: allgwy001@… | Owner:
Type: defect | Status: new
Priority: unset | Milestone:
Component: Other | Version: ET_2016_05
Keywords: |
-----------------------------------+----------------------------------------
I've been trying to run the static tov example parameter file on an HPC
cluster using >40 cores, but this results in NaNs in the data. I can't
remember whether the issue first appears at 40 or 41 cores (and won't be
able to check this for the next few days), but using 41+ cores definitely
gives me NaNs. I remember testing with 39 cores and several other lower
values (down to 4), but these runs all seemed fine.
So far, I've been able to run larger simulations (e.g. BBHs) on more than
40 cores (same cluster) without any apparent issues.
I'll attach the static tov parameter file I used (I think I changed one or
two outdated parameters), as well as the PBS script and error/output files
from a static tov run on 44 cores.
The static tov runs were intended for speed test purposes. The results of
the speed tests I've run so far (on fewer than 40 cores) seem quite
strange to me, so I'm going to attach a text file with walltimes and CPU
times for these runs, too. Any comments would be appreciated!
--
Ticket URL: <https://trac.einsteintoolkit.org/ticket/2008>
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