Trac May 2012

trac@lists.einsteintoolkit.org

2 participants
239 discussions

[Einstein Toolkit] #751: Carpet fails when running qc0-mclachlan.par
by Einstein Toolkit 08 Jul '12

08 Jul '12

#751: Carpet fails when running qc0-mclachlan.par --------------------+------------------------------------------------------- Reporter: rhaas | Owner: eschnett Type: defect | Status: new Priority: major | Milestone: Component: Carpet | Version: Keywords: | --------------------+------------------------------------------------------- this is due to ggf::transfer_from_all line 613 (dst->transfer_from) where dst is NULL: {{{ 03 assert (lc1>=0 or lc2>=0); 604 605 // Source and destination data 606 gdata * const dst = 607 lc1>=0 ? storage.AT(ml1).AT(rl1).AT(lc1).AT(tl1) : NULL; 608 cdata const & srcs = srcstorage.AT(ml2).AT(rl2); 609 for (int i=0; i<(int)gsrcs.size(); ++i) { 610 gsrcs.AT(i) = lc2>=0 ? srcs.AT(lc2).AT(tl2s.AT(i)) : NULL; 611 } 612 613 dst->transfer_from 614 (state, gsrcs, times, recv, send, slabinfo, p1, p2, time, pos, pot); }}} which causes a segfault in line 613. lc1 is -1 in this case and passes the assert in line 603. Since dst is used as a pointer it may never be NULL. It can be reproduced with the qc0-mclachlan.par example from simfactory. Tested on Caltech's bethe workstation with 12 MPI processes and no OpenMP. hg blames commit 5418b354a3ab which seems to be the original Carpet import into mercurial so this seems to be caused by something else. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/751> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 4

[Einstein Toolkit] #813: Fix all thorns that attempt reductions in local mode
by Einstein Toolkit 06 Jul '12

06 Jul '12

#813: Fix all thorns that attempt reductions in local mode -----------------------------------+---------------------------------------- Reporter: rhaas | Owner: Type: task | Status: new Priority: major | Milestone: Component: EinsteinToolkit thorn | Version: Keywords: | -----------------------------------+---------------------------------------- Recently these produce a level three warning (simfactorie's default) whenever they attempt to do so and clutter the log files. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/813> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 16

[Einstein Toolkit] #732: qc0-mclachlan example parameter file should be more functional
by Einstein Toolkit 22 Jun '12

22 Jun '12

#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

1 4

[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] #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] #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] #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

[Einstein Toolkit] #350: Autogenerating cctk_Loop.h
by Einstein Toolkit 17 Jun '12

17 Jun '12

#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

1 17

← Newer
1
...
10
11
12
13
14
15
16
...
24
Older →

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

Trac May 2012