#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
#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
#1523: Use Piraha to Parse all CCL files
-------------------------+--------------------------------------------------
Reporter: sbrandt | Owner:
Type: enhancement | Status: new
Priority: optional | Milestone: Cactus_4.3.0
Component: Cactus | Version: development version
Keywords: |
-------------------------+--------------------------------------------------
Piraha should be used to parse all the CCL files. This would give us a
well-defined grammar and the ability to let other tools use the CCL files
in a reliable way.
--
Ticket URL: <https://trac.einsteintoolkit.org/ticket/1523>
Einstein Toolkit <http://einsteintoolkit.org>
The Einstein Toolkit
#2105: Gallery examples should be tested
----------------------------+-----------------------------------------------
Reporter: hinder | Owner:
Type: task | Status: new
Priority: major | Milestone: ET_2018_02
Component: Other | Version: development version
Keywords: ReleaseProcess |
----------------------------+-----------------------------------------------
The gallery examples at https://einsteintoolkit.org/gallery.html should be
tested to make sure they work with the upcoming release.
--
Ticket URL: <https://trac.einsteintoolkit.org/ticket/2105>
Einstein Toolkit <http://einsteintoolkit.org>
The Einstein Toolkit
#1949: provide floating branch to "current release" and links to it
-----------------------------+----------------------------------------------
Reporter: rhaas | Owner:
Type: enhancement | Status: new
Priority: minor | Milestone:
Component: Other | Version: development version
Keywords: EinsteinToolkit |
-----------------------------+----------------------------------------------
In order to not always have to update all websites with the correct ULRs
to the then current release it would be good if we were to provide a
"current release" branch of the ET which always points to the head of the
current release branch/tag. Ie right now it would be identical to 2016_05.
--
Ticket URL: <https://trac.einsteintoolkit.org/ticket/1949>
Einstein Toolkit <http://einsteintoolkit.org>
The Einstein Toolkit