Trac February 2012

trac@lists.einsteintoolkit.org

1 participants
150 discussions

[Einstein Toolkit] #550: CarpetIOHDF5 too verbose while reading from checkpoint
by Einstein Toolkit 02 Aug '12

02 Aug '12

#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

1 13

[Einstein Toolkit] #634: Riemann1D fails to compile on Kraken
by Einstein Toolkit 08 Jul '12

08 Jul '12

#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

1 4

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

[Einstein Toolkit] #215: Driscoll&Healy integration for Multipole
by Einstein Toolkit 16 Jun '12

16 Jun '12

#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

1 7

[Einstein Toolkit] #512: Run testsuite in "distribute" script
by Einstein Toolkit 15 Jun '12

15 Jun '12

#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

1 5

[Einstein Toolkit] #515: Silently overrides DEBUG and OPTIMISE options
by Einstein Toolkit 15 Jun '12

15 Jun '12

#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

1 9

← Newer
1
...
6
7
8
9
10
11
12
...
15
Older →

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

Trac February 2012