#465: Hydro_InitExcision test cases take a long time
-----------------------------------+----------------------------------------
Reporter: eschnett | Owner:
Type: defect | Status: new
Priority: major | Milestone:
Component: EinsteinToolkit thorn | Version:
Keywords: |
-----------------------------------+----------------------------------------
I am just running all test cases with an executable without optimisation,
and I find that Hydro_InitExcision takes a long time. While most other
test cases finish in a few minutes, Hydro_InitExcision takes two hours to
run. The test cases should be reduced in number, size, or duration.
--
Ticket URL: <https://trac.einsteintoolkit.org/ticket/465>
Einstein Toolkit <http://einsteintoolkit.org>
The Einstein Toolkit
#550: CarpetIOHDF5 too verbose while reading from checkpoint
-------------------------+--------------------------------------------------
Reporter: knarf | Owner: eschnett
Type: enhancement | Status: new
Priority: minor | Milestone:
Component: Carpet | Version:
Keywords: |
-------------------------+--------------------------------------------------
It is not that uncommon that I recover using a different number of
processors. Every time I do this I see the error file cluttered with
messages like
WARNING level 1 in thorn CarpetIOHDF5 processor 21 host
c312-313.ls4.tacc.utexas.edu
(line 640 of
/work/00920/tg459479/Cactus/arrangements/Carpet/CarpetIOHDF5/src/Input.cc):
-> Variable AHFINDERDIRECT::ahmask on rl 0 and tl 0 not read completely.
Will have to look for it in other files
I expect this, this is not an error and not really something to warn
about. I acknowledge that this might have been introduced when recovering
using the same number of processors was a problem and caused reading all
files, but I don't think this is an issue anymore.
I propose to change the warnlevel for this message to CCTK_WARN_DEBUG(4).
In addition it would be good to have _one_ separate message with level
CCTK_WARN_PICKY(3) if any variable/reflevel/timelevel could not be read
completely (but not one for each of these), ideally only once for all
processors. This would not clutter the output of the default simfactory
runs (-L 3) too much, but would indicate that this happened - and in case
this is a problem it's easy to enable -L 4.
--
Ticket URL: <https://trac.einsteintoolkit.org/ticket/550>
Einstein Toolkit <http://einsteintoolkit.org>
The Einstein Toolkit
#634: Riemann1D fails to compile on Kraken
-----------------------------------+----------------------------------------
Reporter: hinder | Owner:
Type: defect | Status: new
Priority: minor | Milestone:
Component: EinsteinToolkit thorn | Version:
Keywords: GRHydro |
-----------------------------------+----------------------------------------
I'm unable to compile the Riemann1D utility on Kraken. It gives the
following error message.
{{{
Creating Riemann1d in /nics/d/home/hinder/Cactus/EinsteinToolkit/exe/sim
from
/nics/d/home/hinder/Cactus/EinsteinToolkit/configs/sim/build/GRHydro/Riemann1d.o
/nics/d/home/hinder/Cactus/EinsteinToolkit/configs/sim/build/GRHydro/Riemann1d.o:
In function `riemann1d':
/nics/d/home/hinder/Cactus/EinsteinToolkit/arrangements/EinsteinEvolve/GRHydro/src/util/Riemann1d.f90:10:
undefined reference to `__kmpc_begin'
/nics/d/home/hinder/Cactus/EinsteinToolkit/arrangements/EinsteinEvolve/GRHydro/src/util/Riemann1d.f90:374:
undefined reference to `__kmpc_end'
/usr/bin/ld: link errors found, deleting executable
`/nics/d/home/hinder/Cactus/EinsteinToolkit/exe/sim/Riemann1d'
make[1]: ***
[/nics/d/home/hinder/Cactus/EinsteinToolkit/exe/sim/Riemann1d] Error 1
make: *** [sim-utils] Error 2
}}}
I think that this needs an Intel library to be linked in, but I'm not sure
which one or how to add it.
--
Ticket URL: <https://trac.einsteintoolkit.org/ticket/634>
Einstein Toolkit <http://einsteintoolkit.org>
The Einstein Toolkit
#625: CapretIOHDF5 sliced output does not output symmetry points unless it also
outputs buffer points
--------------------------+-------------------------------------------------
Reporter: hinder | Owner: eschnett
Type: defect | Status: new
Priority: major | Milestone:
Component: Carpet | Version:
Keywords: CarpetIOHDF5 |
--------------------------+-------------------------------------------------
The parameter CarpetIOHDF5::output_symmetry_points = yes does not work
when CarpetIOHDF5::output_buffer_points = no (the default). This is
probably due to the line
if (not output_buffer_points) {
exts &= allactive;
}
near line 1071 in OutputSlice.cc. I suspect that allactive does not
include the symmetry points. The attached parameter file should be run on
one processor. You can then use
h5dump -d '/GRID::x it=0 tl=0 rl=0' output_symmetry/x.x.h5
Near the top you will see
DATASET "/GRID::x it=0 tl=0 rl=0" {
DATATYPE H5T_IEEE_F64LE
DATASPACE SIMPLE { ( 5 ) / ( 5 ) }
DATA {
(0): 0, 0.1, 0.2, 0.3, 0.4
}
i.e. the first point output is x = 0. For this parameter file, there
should be a symmetry point at x = -0.1. If you modify the parameter file
to use CarpetIOHDF5::output_buffer_points = yes, then the symmetry point
appears in the output.
The workaround is to always use
CarpetIOHDF5::output_buffer_points = yes
if you want to output symmetry points.
--
Ticket URL: <https://trac.einsteintoolkit.org/ticket/625>
Einstein Toolkit <http://einsteintoolkit.org>
The Einstein Toolkit
#350: Autogenerating cctk_Loop.h
-------------------------+--------------------------------------------------
Reporter: eschnett | Owner:
Type: enhancement | Status: new
Priority: minor | Milestone:
Component: Cactus | Version:
Keywords: |
-------------------------+--------------------------------------------------
I wrote a perl script to auto-generate the Cactus header file
Cactus/src/include/cctk_Loop.h.The script writes the code to stdout. I
attach it to this ticket, as well as the output it generates.
I suggest to keep this perl script next to its output in the include
directory, and to run it manually whenever required.
--
Ticket URL: <https://trac.einsteintoolkit.org/ticket/350>
Einstein Toolkit <http://einsteintoolkit.org>
The Einstein Toolkit
#215: Driscoll&Healy integration for Multipole
-------------------------+--------------------------------------------------
Reporter: eschnett | Owner:
Type: enhancement | Status: new
Priority: major | Milestone:
Component: Cactus | Version:
Keywords: |
-------------------------+--------------------------------------------------
The attached patch implements a more accurate integration over the sphere,
using an algorithm by Driscoll & Healy. This algorithm uses Gaussian
integration weights, leading (almost) to exponential convergence.
--
Ticket URL: <https://trac.einsteintoolkit.org/ticket/215>
Einstein Toolkit <http://einsteintoolkit.org>
The Einstein Toolkit
#512: Run testsuite in "distribute" script
-------------------------+--------------------------------------------------
Reporter: eschnett | Owner: eschnett
Type: enhancement | Status: new
Priority: minor | Milestone:
Component: SimFactory | Version:
Keywords: |
-------------------------+--------------------------------------------------
Run the testsuite in the distribute script.
--
Ticket URL: <https://trac.einsteintoolkit.org/ticket/512>
Einstein Toolkit <http://einsteintoolkit.org>
The Einstein Toolkit
#515: Silently overrides DEBUG and OPTIMISE options
---------------------------+------------------------------------------------
Reporter: barry.wardell | Owner: eschnett
Type: defect | Status: new
Priority: major | Milestone:
Component: SimFactory | Version:
Keywords: |
---------------------------+------------------------------------------------
When building a configuration with SimFactory, no matter what is set in
the OptionList it sets the DEBUG and OPTIMISE options based on its own
--optimise and --debug options, which default to enabling optimisation and
disabling debug. This means that even if I have an OptionList with
DEBUG="yes", SimFactory will silently change this to DEBUG="no". This is
very unexpected and should not happen.
I think SimFactory should respect what is set in the OptionList and never
change it. The attached patch disables the overriding of all OptionList
settings.
--
Ticket URL: <https://trac.einsteintoolkit.org/ticket/515>
Einstein Toolkit <http://einsteintoolkit.org>
The Einstein Toolkit
#429: Parallelising AEILocalInterp
-----------------------------------+----------------------------------------
Reporter: eschnett | Owner:
Type: enhancement | Status: new
Priority: major | Milestone:
Component: EinsteinToolkit thorn | Version:
Keywords: |
-----------------------------------+----------------------------------------
The enclosed patch parallelises AEILocalInterp via OpenMP.
This leads to a slight change in behaviour. Currently, AEILocalInterp
traverses the list of points sequentially, and aborts when the first error
is encountered. After parallelisation, there is no fixed order in which
the points are traversed, and if several errors are encountered, any one
of the errors may be returned, not necessarily the first. I am not aware
of any thorn that would or should rely on such an ordering.
This patch also adds "restrict" and "const" statements that may improve
performance as it gives the compiler more information about dependencies
between pointers.
--
Ticket URL: <https://trac.einsteintoolkit.org/ticket/429>
Einstein Toolkit <http://einsteintoolkit.org>
The Einstein Toolkit