Trac June 2012

trac@lists.einsteintoolkit.org

1 participants
175 discussions

[Einstein Toolkit] #933: add test suite to EOS_Omni table reader
by Einstein Toolkit 22 Jun '12

22 Jun '12

#933: add test suite to EOS_Omni table reader -------------------+-------------------------------------------------------- Reporter: rhaas | Type: enhancement Status: new | Priority: minor Milestone: | Component: EinsteinToolkit thorn Version: | Keywords: EOS_Omni -------------------+-------------------------------------------------------- the attached patch to EOS Omni (plus attached sample hdf5 table) adds a small routine EOS_OMNI_dumptable to output the read in data as ASCII into a user selected file. It can be used to test the low level table reader facility (adding options to make an EOS call would also be possible but is not implemented right now). Code and table kindly provided by Evan O'Connor. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/933> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 3

[Einstein Toolkit] #962: parallelize Multipole using OpenMP and MPI
by Einstein Toolkit 21 Jun '12

21 Jun '12

#962: parallelize Multipole using OpenMP and MPI -----------------------------------+---------------------------------------- Reporter: rhaas | Owner: Type: enhancement | Status: new Priority: minor | Milestone: Component: EinsteinToolkit thorn | Version: Keywords: Multipole | -----------------------------------+---------------------------------------- The attached patch parallelizes each extraction sphere in multipole using OpenMP and distributes the spheres across processors using MPI. It contains threadprivate OMP pragmas for some memory that is allocated by simpson integration rule which will mean that more memory is allocated than would be for the non-openmp case. The alternative would be to allocate and free the memory each time the function is called (this would be much cleaner). -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/962> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 6

[Einstein Toolkit] #941: CCTK_ActiveTimeLevels returns "wrong" number
by Einstein Toolkit 20 Jun '12

20 Jun '12

#941: CCTK_ActiveTimeLevels returns "wrong" number ----------------------------------------+----------------------------------- Reporter: reisswig@… | Type: enhancement Status: new | Priority: optional Milestone: | Component: Cactus Version: | Keywords: CCTK_ActiveTimeLevels ----------------------------------------+----------------------------------- CCTK_ActiveTimeLevels is supposed to return the current number of active timelevels for a given grid function. Currently, however, with multiple reflevels (and also maps), CCTK_ActiveTimeLevels returns "number of active time levels"*"number of reflevels"*"number of maps". Unfortunately, e.g. CarpetInterp can get confused when asked to time interpolate. A grid function, which technically only has one level per reflevel active, will have 3 levels active according to CCTK_ActiveTimeLevels when there are 3 reflevels. CarpetInterp may then think that indeed there are enough active time levels to time interpolate even though there are not. This previously led to segfaults in CarpetInterp in certain circumstances (now fixed by avoiding to call CCTK_ActiveTimeLevels). CCTK_ActiveTimeLevels really calls GroupStorageCrease in Carpet/src/Storage.cc. At line, 207, the total number of timelevels is computed. Instead of making this a product between number of reflevels, timelevels, and maps, would it be possible to instead compute the minimum over reflevels, maps? According to Erik, different reflevels/maps can have different number of active timelevels. If we return the minimum, then we are on the safe side and CCTK_ActiveTimeLevels would return a correct number. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/941> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 1

[Einstein Toolkit] #904: Compiling with -DDEBUG causes problems for CactusBase/Boundary
by Einstein Toolkit 20 Jun '12

20 Jun '12

#904: Compiling with -DDEBUG causes problems for CactusBase/Boundary ---------------------+------------------------------------------------------ Reporter: sbrandt | Owner: Type: defect | Status: new Priority: minor | Milestone: ET_2012_11 Component: Cactus | Version: Keywords: | ---------------------+------------------------------------------------------ Variable names were changed, but code inside #ifdef DEBUG's was not updated. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/904> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 3

[Einstein Toolkit] #625: CapretIOHDF5 sliced output does not output symmetry points unless it also outputs buffer points
by Einstein Toolkit 20 Jun '12

20 Jun '12

#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

1 11

[Einstein Toolkit] #800: inconsistent boxes during refluxing very late in the run
by Einstein Toolkit 20 Jun '12

20 Jun '12

#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

1 6

[Einstein Toolkit] #961: Add an option for enabling floating point exceptions
by Einstein Toolkit 20 Jun '12

20 Jun '12

#961: Add an option for enabling floating point exceptions -------------------------+-------------------------------------------------- Reporter: hinder | Owner: Type: enhancement | Status: new Priority: minor | Milestone: Component: Cactus | Version: Keywords: | -------------------------+-------------------------------------------------- Cactus disables floating point exceptions, so that NaNs and Infs can be generated by numerical code. When debugging, it is sometimes very helpful to use these exceptions, as a debugger will tell you exactly which piece of code generates them. I propose that Cactus should have a run-time parameter, defaulting to "no", which enables floating point exceptions. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/961> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 1

[Einstein Toolkit] #755: Provide better support for implementing boundary conditions
by Einstein Toolkit 20 Jun '12

20 Jun '12

#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

1 8

[Einstein Toolkit] #955: Don't #define restrict in thorns
by Einstein Toolkit 19 Jun '12

19 Jun '12

#955: Don't #define restrict in thorns -----------------------------------+---------------------------------------- Reporter: eschnett | Owner: Type: defect | Status: new Priority: minor | Milestone: Component: EinsteinToolkit thorn | Version: Keywords: | -----------------------------------+---------------------------------------- The following thorns #define restrict. This is now handled by the flesh, so the thorns should not do that any more: arrangements/CactusNumerical/Slab/src/slab.cc:53:# define restrict CCTK_CXX_RESTRICT arrangements/CactusUtils/OpenCLRunTime/src/defs.hh:11:# define restrict CCTK_CXX_RESTRICT arrangements/EinsteinEvolve/NewRad/src/extrap.cc:8:# define restrict CCTK_CXX_RESTRICT arrangements/EinsteinEvolve/NewRad/src/newrad.cc:8:# define restrict CCTK_CXX_RESTRICT -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/955> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 6

[Einstein Toolkit] #768: Change per thorn -DTHORN_IS_xxx to a per thorn -I bindings/include/xxx
by Einstein Toolkit 18 Jun '12

18 Jun '12

#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

1 15

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

Trac June 2012