#732: qc0-mclachlan example parameter file should be more functional
-------------------------+--------------------------------------------------
Reporter: hinder | Owner:
Type: enhancement | Status: new
Priority: minor | Milestone:
Component: Other | Version:
Keywords: |
-------------------------+--------------------------------------------------
I propose adding wave extraction (using WeylScal4 and Multipole), as well
as puncture tracking using PunctureTracker, to qc0-mclachlan.par.
--
Ticket URL: <https://trac.einsteintoolkit.org/ticket/732>
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
#800: inconsistent boxes during refluxing very late in the run
-----------------------+----------------------------------------------------
Reporter: rhaas | Owner:
Type: defect | Status: new
Priority: major | Milestone:
Component: Other | Version:
Keywords: Refluxing |
-----------------------+----------------------------------------------------
this is the second half of #797. Same parameter files but using the
Refluxing thorn. Eventually I get:
{{{
srcbbox:
([25248,27424,26272]:[28704,30432,29088]:[64,64,64]/[394,428,410]:[448,475,454]/[55,48,45]/118800)
dstbbox:
([28736,27840,26688]:[28736,28096,28992]:[128,128,128]/[224,217,208]:[224,219,226]/[1,3,19]/57)
regbbox:
([28736,27840,26688]:[28736,28096,28992]:[128,128,128]/[224,217,208]:[224,219,226]/[1,3,19]/57)
srcbbox: ([25248,27424,31328]:[28704,30432,34144]:[64,WARNING level 0 in
thorn CarpetLib processor 80 host shc054
(line 174 of
/home/rhaas/cactus/Zelmani/arrangements/Carpet/CarpetLib/src/restrict_3d_vc_rf2.cc):
-> Internal error: region extent is not contained in array extent
srcbbox:
([25248,27424,23712]:[28704,30432,26592]:[64,64,64]/[394,428,370]:[448,475,415]/[55,48,46]/121440)
dstbbox:
([28736,27840,24512]:[28736,28096,25792]:[128,128,128]/[224,217,191]:[224,219,201]/[1,3,11]/33)
regbbox:
([28736,27840,24512]:[28736,28096,25792]:[128,128,128]/[224,217,191]:[224,219,201]/[1,3,11]/33)
64,64]/[394,428,489]:[448,475,533]/[55,48,45]/118800)
dstbbox:
([28736,27840,31680]:[28736,28096,33344]:[128,128,128]/[224,217,247]:[224,219,260]/[1,3,14]/42)
regbbox:
([28736,27840,31680]:[28736,28096,33344]:[128,128,128]/[224,217,247]:[224,219,260]/[1,3,14]/42)
WARNING level 0 in thorn CarpetLib processor 82 host shc053
(line 174 of
/home/rhaas/cactus/Zelmani/arrangements/Carpet/CarpetLib/src/restrict_3d_vc_rf2.cc):
-> Internal error: region extent is not contained in array extent
WARNING level 0 in thorn CarpetLib processor 79 host shc055
(line 174 of
/home/rhaas/cactus/Zelmani/arrangements/Carpet/CarpetLib/src/restrict_3d_vc_rf2.cc):
-> Internal error: region extent is not contained in array extent
srcbbox:
([25248,27424,28768]:[28704,30432,31648]:[64,64,64]/[394,428,449]:[448,475,494]/[55,48,46]/121440)
dstbbox:
([28736,27840,29120]:[28736,28096,29888]:[128,128,128]/[224,217,227]:[224,219,233]/[1,3,7]/21)
regbbox:
([28736,27840,29120]:[28736,28096,29888]:[128,128,128]/[224,217,227]:[224,219,233]/[1,3,7]/21)
WARNING level 0 in thorn CarpetLib processor 81 host shc054
(line 174 of
/home/rhaas/cactus/Zelmani/arrangements/Carpet/CarpetLib/src/restrict_3d_vc_rf2.cc):
-> Internal error: region extent is not contained in array extent
}}}
which happens during refluxing
{{{
INFO (Carpet): [ml=0][rl=2][tl=0] Evolution/PostRestrict at iteration
83712 time 196.2
INFO (Carpet): [ml=0][rl=2][tl=0] Scheduling CCTK_POSTRESTRICT
INFO (Carpet): [ml=0][rl=2][tl=0] Level mode call at CCTK_POSTRESTRICT to
Refluxing::Refluxing_CorrectState
INFO (Refluxing): Refluxing at iteration 83712 on level 2 of 4
INFO (Refluxing): Refluxing on level 2:
INFO (Carpet): [ml=0][rl=2][tl=0] Entering singlemap mode
INFO (Carpet): [ml=0][rl=2][m=0][tl=0] Entering local mode
INFO (Carpet): [ml=0][rl=2][m=0][c=0,lc=0][tl=0] Leaving local mode
INFO (Carpet): [ml=0][rl=2][m=0][tl=0] Leaving singlemap mode
INFO (Carpet): [ml=0][rl=2][tl=0] Leaving level mode
INFO (Carpet): [ml=0][tl=0] Entering level mode
INFO (Carpet): [ml=0][rl=3][tl=0] Entering singlemap mode
INFO (Carpet): [ml=0][rl=3][m=0][tl=0] Entering local mode
INFO (Carpet): [ml=0][rl=3][m=0][c=0,lc=0][tl=0] Leaving local mode
INFO (Carpet): [ml=0][rl=3][m=0][tl=0] Leaving singlemap mode
INFO (Carpet): [ml=0][rl=3][tl=0] Leaving level mode
INFO (Carpet): [ml=0][tl=0] Entering level mode
INFO (CarpetLib): About to MPI_Isend to processor 1 for type double
INFO (CarpetLib): Finished MPI_Isend
INFO (CarpetLib): About to MPI_Isend to processor 2 for type double
INFO (CarpetLib): Finished MPI_Isend
INFO (CarpetLib): About to MPI_Isend to processor 3 for type double
INFO (CarpetLib): Finished MPI_Isend
INFO (CarpetLib): About to MPI_Isend to processor 7 for type double
INFO (CarpetLib): Finished MPI_Isend
INFO (CarpetLib): About to MPI_Isend to processor 8 for type double
INFO (CarpetLib): Finished MPI_Isend
INFO (CarpetLib): About to MPI_Isend to processor 9 for type double
INFO (CarpetLib): Finished MPI_Isend
INFO (CarpetLib): About to MPI_Waitall
INFO (CarpetLib): Finished MPI_Waitall
INFO (CarpetLib): About to MPI_Waitall
INFO (CarpetLib): Finished MPI_Waitall
INFO (Carpet): [ml=0][rl=2][tl=0] Entering singlemap mode
INFO (Carpet): [ml=0][rl=2][m=0][tl=0] Entering local mode
INFO (Refluxing): Refluxing on level 2 map 0 component 0 direction 0 face
0: [25,25,25]:[25,31,35]
INFO (Refluxing): Refluxing on level 2 map 0 component 0 direction 1 face
0: [25,25,25]:[33,25,35]
INFO (Refluxing): Refluxing on level 2 map 0 component 0 direction 2 face
0: [25,25,25]:[33,31,25]
INFO (Carpet): [ml=0][rl=2][m=0][c=0,lc=0][tl=0] Leaving local mode
INFO (Carpet): [ml=0][rl=2][m=0][tl=0] Leaving singlemap mode
INFO (Carpet): [ml=0][rl=2][tl=0] Leaving level mode
INFO (Carpet): [ml=0][tl=0] Entering level mode
INFO (Carpet): [ml=0][rl=3][tl=0] Entering singlemap mode
INFO (Carpet): [ml=0][rl=3][m=0][tl=0] Entering local mode
INFO (Carpet): [ml=0][rl=3][m=0][c=0,lc=0][tl=0] Leaving local mode
INFO (Carpet): [ml=0][rl=3][m=0][tl=0] Leaving singlemap mode
INFO (Carpet): [ml=0][rl=3][tl=0] Leaving level mode
INFO (Carpet): [ml=0][tl=0] Entering level mode
INFO (Carpet): [ml=0][rl=2][tl=0] Entering singlemap mode
INFO (Carpet): [ml=0][rl=2][m=0][tl=0] Entering local mode
INFO (Carpet): [ml=0][rl=2][m=0][c=0,lc=0][tl=0] Leaving local mode
INFO (Carpet): [ml=0][rl=2][m=0][tl=0] Leaving singlemap mode
INFO (Carpet): [ml=0][rl=2][tl=0] SyncGroup "GRHYDRO::DENS"
iteration=83712 time=196.2
INFO (Carpet): [ml=0][rl=2][tl=0] SyncGroup "GRHYDRO::SCON"
iteration=83712 time=196.2
INFO (Carpet): [ml=0][rl=2][tl=0] SyncGroup "GRHYDRO::TAU" iteration=83712
time=196.2
INFO (Carpet): [ml=0][rl=2][tl=0] ProlongateGroups
INFO (CarpetLib): About to MPI_Irecv from processor 1 for type double
INFO (CarpetLib): Finished MPI_Irecv
INFO (CarpetLib): About to MPI_Irecv from processor 6 for type double
INFO (CarpetLib): Finished MPI_Irecv
INFO (CarpetLib): About to MPI_Irecv from processor 36 for type double
INFO (CarpetLib): Finished MPI_Irecv
INFO (CarpetLib): About to MPI_Irecv from processor 39 for type double
INFO (CarpetLib): Finished MPI_Irecv
INFO (CarpetLib): About to MPI_Irecv from processor 48 for type double
INFO (CarpetLib): Finished MPI_Irecv
INFO (CarpetLib): About to MPI_Waitall
INFO (CarpetLib): Finished MPI_Waitall
INFO (CarpetLib): About to MPI_Waitall
INFO (CarpetLib): Finished MPI_Waitall
INFO (Carpet): [ml=0][rl=2][tl=0] SyncGroups
INFO (CarpetLib): About to MPI_Irecv from processor 1 for type double
INFO (CarpetLib): Finished MPI_Irecv
INFO (CarpetLib): About to MPI_Irecv from processor 2 for type double
INFO (CarpetLib): Finished MPI_Irecv
INFO (CarpetLib): About to MPI_Irecv from processor 3 for type double
INFO (CarpetLib): Finished MPI_Irecv
INFO (CarpetLib): About to MPI_Irecv from processor 7 for type double
INFO (CarpetLib): Finished MPI_Irecv
INFO (CarpetLib): About to MPI_Irecv from processor 8 for type double
INFO (CarpetLib): Finished MPI_Irecv
INFO (CarpetLib): About to MPI_Irecv from processor 9 for type double
INFO (CarpetLib): Finished MPI_Irecv
INFO (CarpetLib): About to MPI_Irecv from processor 10 for type double
INFO (CarpetLib): Finished MPI_Irecv
INFO (CarpetLib): About to MPI_Isend to processor 1 for type double
INFO (CarpetLib): Finished MPI_Isend
INFO (CarpetLib): About to MPI_Isend to processor 2 for type double
INFO (CarpetLib): Finished MPI_Isend
INFO (CarpetLib): About to MPI_Isend to processor 3 for type double
INFO (CarpetLib): Finished MPI_Isend
INFO (CarpetLib): About to MPI_Isend to processor 7 for type double
INFO (CarpetLib): Finished MPI_Isend
INFO (CarpetLib): About to MPI_Isend to processor 8 for type double
INFO (CarpetLib): Finished MPI_Isend
INFO (CarpetLib): About to MPI_Isend to processor 9 for type double
INFO (CarpetLib): Finished MPI_Isend
INFO (CarpetLib): About to MPI_Isend to processor 10 for type double
INFO (CarpetLib): Finished MPI_Isend
INFO (CarpetLib): About to MPI_Waitall
INFO (CarpetLib): Finished MPI_Waitall
INFO (CarpetLib): About to MPI_Waitall
INFO (CarpetLib): Finished MPI_Waitall
INFO (Carpet): [ml=0][rl=2][tl=0] Level mode call at MoL_PostStep to
ADMBase::ADMBase_Boundaries
INFO (Carpet): [ml=0][rl=2][tl=0] SyncGroup "ADMBASE::LAPSE"
iteration=83712 time=196.2
INFO (Carpet): [ml=0][rl=2][tl=0] SyncGroup "ADMBASE::DTLAPSE"
iteration=83712 time=196.2
INFO (Carpet): [ml=0][rl=2][tl=0] SyncGroup "ADMBASE::SHIFT"
iteration=83712 time=196.2
INFO (Carpet): [ml=0][rl=2][tl=0] SyncGroup "ADMBASE::DTSHIFT"
iteration=83712 time=196.2
INFO (Carpet): [ml=0][rl=2][tl=0] SyncGroup "ADMBASE::METRIC"
iteration=83712 time=196.2
INFO (Carpet): [ml=0][rl=2][tl=0] SyncGroup "ADMBASE::CURV"
iteration=83712 time=196.2
INFO (Carpet): [ml=0][rl=2][tl=0] ProlongateGroups
INFO (CarpetLib): About to MPI_Irecv from processor 1 for type double
INFO (CarpetLib): Finished MPI_Irecv
INFO (CarpetLib): About to MPI_Irecv from processor 6 for type double
INFO (CarpetLib): Finished MPI_Irecv
INFO (CarpetLib): About to MPI_Irecv from processor 36 for type double
INFO (CarpetLib): Finished MPI_Irecv
INFO (CarpetLib): About to MPI_Irecv from processor 39 for type double
INFO (CarpetLib): Finished MPI_Irecv
INFO (CarpetLib): About to MPI_Irecv from processor 48 for type double
INFO (CarpetLib): Finished MPI_Irecv
INFO (CarpetLib): About to MPI_Waitall
}}}
The full stdout and stderr files are about 250MB for this (because of all
the verbosity).
I agree that this is not a very helpful error report. Unfortunately I
don't know how to distill more useful information out of it :-(
--
Ticket URL: <https://trac.einsteintoolkit.org/ticket/800>
Einstein Toolkit <http://einsteintoolkit.org>
The Einstein Toolkit
#755: Provide better support for implementing boundary conditions
-------------------------+--------------------------------------------------
Reporter: hinder | Owner:
Type: enhancement | Status: new
Priority: major | Milestone:
Component: Cactus | Version:
Keywords: |
-------------------------+--------------------------------------------------
Whenever an application thorn wants to apply a boundary condition (i.e.
not using the hard-coded boundary conditions from thorn Boundary), it is
necessary to identify which points on the local component correspond to
physical (as opposed to symmetry, inter-process or refinement boundaries).
This functionality is available in KrancNumericalTools/GenericFD. The
function is GenericFD_GetBoundaryInfo in
https://github.com/ianhinder/Kranc/blob/master/Auxiliary/Cactus/KrancNumeri…
The function takes various Cactus variables as input and outputs arrays
indicating the nature of each boundary: bounding box and whether the face
is a symmetry, physical or interprocessor boundary (including refinement
boundaries).
There is also a function GenericFD_LoopOverBoundary which splits the
domain into the 26 different regions (6 faces, 12 edges and 8 corners) and
calls a function (passed by pointer) on each region that corresponds to a
physical boundary. Input parameters to the function identify the boundary
normal, face, direction, etc. This calls GenericFD_GetBoundaryInfo to
identify this information. This functionality is obviously core to
implementing boundary conditions.
I propose that this functionality be included in Cactus. Thorn Boundary
would be a logical place, since GenericFD_GetBoundaryInfo calls aliased
functions usually provided by CoordBase or multipatch thorns, so I don't
think this belongs in the flesh. The function-pointer interface might not
be the right one - perhaps we could refactor the code so that there was a
macro similar to the flesh CCTK_LOOP macros. The user would write
BEGIN_BOUNDARY_LOOP(args...)
...
END_BOUNDARY_LOOP
where args gave names for the local variables indicating the normal
direction, face number etc. This macro would evaluate whatever was inside
it on each of the physical boundaries with appropriate values for the
arguments.
--
Ticket URL: <https://trac.einsteintoolkit.org/ticket/755>
Einstein Toolkit <http://einsteintoolkit.org>
The Einstein Toolkit
#768: Change per thorn -DTHORN_IS_xxx to a per thorn -I bindings/include/xxx
--------------------------+-------------------------------------------------
Reporter: sbrandt | Owner:
Type: enhancement | Status: new
Priority: optional | Milestone: Cactus_4.1.0
Component: Cactus | Version: Cactus_4.0.0
Keywords: build system |
--------------------------+-------------------------------------------------
It is not possible for Mojave to display many include files correctly
because the way they should be viewed depends on context. E.g. what
THORN_IS_ construct should not be greyed out when viewing
definethisthorn.h?
The plan is to create many definethisthorn.h files in many directories.
Similar things need to be done with other files. A start, something that
compiles and splits up only definethisthorn.h and cctk_Functions.h is
attached.
--
Ticket URL: <https://trac.einsteintoolkit.org/ticket/768>
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
#821: avoid allocting temp memory twice in EOS Omni
-------------------+--------------------------------------------------------
Reporter: rhaas | Type: enhancement
Status: new | Priority: minor
Milestone: | Component: Other
Version: | Keywords:
-------------------+--------------------------------------------------------
instead of storing a copy of the data in the Fortran module store Fortran
pointers.
--
Ticket URL: <https://trac.einsteintoolkit.org/ticket/821>
Einstein Toolkit <http://einsteintoolkit.org>
The Einstein Toolkit