Trac August 2012

trac@lists.einsteintoolkit.org

1 participants
206 discussions

[Einstein Toolkit] #1067: Do not interpolate from buffer zones
by Einstein Toolkit 16 Sep '12

16 Sep '12

#1067: Do not interpolate from buffer zones ----------------------+----------------------------------------------------- Reporter: eschnett | Owner: eschnett Type: defect | Status: new Priority: major | Milestone: Component: Carpet | Version: Keywords: | ----------------------+----------------------------------------------------- When interpolating, Carpet currently results results using information from buffer points. This should not be the case. To remedy this, in gh.cc::locate_position, after searching the superregions, check with dh.hh:level_dboxes::active whether the point is within a buffer region, and if so, use the next coarser grid instead. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/1067> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 1

[Einstein Toolkit] #832: ExternalLibraries/zlib gives bad error message if "patch" is not available
by Einstein Toolkit 16 Sep '12

16 Sep '12

#832: ExternalLibraries/zlib gives bad error message if "patch" is not available -----------------------------------+---------------------------------------- Reporter: hinder | Owner: Type: defect | Status: new Priority: minor | Milestone: Component: EinsteinToolkit thorn | Version: Keywords: | -----------------------------------+---------------------------------------- The PATCH variable is used in the zlib configuration script but there is no check that it has been set. It is also not declared in the configuration.ccl as being used. Should all environment variables used in the script be declared? PATCH is usually set by autoconf, unless it is unavailable, in which case it is not set. Replacing $PATCH with ${PATCH?} would be enough to give a sensible error message. I don't know if there are versions of bash that would not understand this. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/832> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 9

[Einstein Toolkit] #895: PITTNullCode does not work with Devel AEILocalInterp
by Einstein Toolkit 13 Sep '12

13 Sep '12

#895: PITTNullCode does not work with Devel AEILocalInterp ---------------------------------+------------------------------------------ Reporter: yosef@… | Type: defect Status: new | Priority: major Milestone: | Component: EinsteinToolkit thorn Version: | Keywords: CCE complex interpolation ---------------------------------+------------------------------------------ The CCE testsuite fails in the development version of ET. The interpolation calls in NullNews fail with the error WARNING[L1,P0] (AEILocalInterp): CCTK_InterpLocalUniform(): input datatype 111 not supported! (0-origin) input #in=0 The interpolation call is for a variable of type CCTK_VARIABLE_COMPLEX. The call works with the Maxwell version of AEILocalInterp -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/895> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 4

[Einstein Toolkit] #1023: Improve OpenMP parallelisation of SummationByParts
by Einstein Toolkit 13 Sep '12

13 Sep '12

#1023: Improve OpenMP parallelisation of SummationByParts -----------------------------------+---------------------------------------- Reporter: eschnett | Owner: Type: enhancement | Status: new Priority: major | Milestone: Component: EinsteinToolkit thorn | Version: Keywords: | -----------------------------------+---------------------------------------- The Intel compiler does not handle workshare constructs well. The attached patch replaces them by explicit loops, which execute faster. This makes a measurable difference on Hopper with 24 OpenMP threads. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/1023> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 3

[Einstein Toolkit] #1068: GRHydro: schedule GRHydro_Tmunu* only if there is Tmunu storage.
by Einstein Toolkit 06 Sep '12

06 Sep '12

#1068: GRHydro: schedule GRHydro_Tmunu* only if there is Tmunu storage. -----------------------------------+---------------------------------------- Reporter: bmundim | Owner: Type: defect | Status: new Priority: major | Milestone: Component: EinsteinToolkit thorn | Version: Keywords: GRHydro Tmunu storage | -----------------------------------+---------------------------------------- The attached patch schedule GRHydro_Tmunu* only if there is Tmunu storage. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/1068> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 5

[Einstein Toolkit] #745: the flesh allows two implemantion of the same interface to have different default values for restricted parameters
by Einstein Toolkit 05 Sep '12

05 Sep '12

#745: the flesh allows two implemantion of the same interface to have different default values for restricted parameters --------------------+------------------------------------------------------- Reporter: rhaas | Owner: Type: defect | Status: new Priority: minor | Milestone: Component: Cactus | Version: Keywords: | --------------------+------------------------------------------------------- since the flesh creates paramters for all compiled in (rather than activated) thorns initially, this affects the default value that a thorn sees. Thorns seem to be initialized (and thus their parameter structures being created) in alphabetical order, which means that the thorn alphabetically '''last''' (How, I have no idea, the parameter handling logic seems a bit of a mess) will determine the default parameter value. Attached is a parameter file to demonstrate this with Carpet and PUGH who both declare parameters periodic and periodic_[xyz] but differ in their defaults. To demonstrate, create an executable with only Carpet compiled in and run the parameter file. Then look at the paramters in the checkpoint it creates eg. {{{ h5dump -r -d /Parameters\ and\ Global\ Attributes/All\ Parameters output/checkpoint.chkpt.it_0.h5 | grep periodic }}} Do the same with an executable that contains both PUGH and Carpet. Notice that parameter values are now PUGH's defaults. This can actually cause a runs to abort when recovering from a checkpoint when one switches from an executable with PUGH compiled in to one that does not. (Beyond the fact that some thorn might actually use it's parameters rather than the Carpet/PUGH pair where happily Carpet ignores these parameters and PUGH who actually used them gets to set the default). -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/745> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 13

[Einstein Toolkit] #1058: Add "lapsefactor" parameter to EinsteinExact
by Einstein Toolkit 05 Sep '12

05 Sep '12

#1058: Add "lapsefactor" parameter to EinsteinExact -----------------------------------+---------------------------------------- Reporter: eschnett | Owner: Type: enhancement | Status: new Priority: major | Milestone: Component: EinsteinToolkit thorn | Version: Keywords: | -----------------------------------+---------------------------------------- I suggest introducing a "lapsefactor" parameter to EinsteinExact. This defines a transformation for the time coordinate between the underlying metric and the metric as will be used by Cactus. For example, setting lapsefactor=1/2 will lead to alpha=0.5 for the Minkowski metric, with the other metric components unchanged. This complements the "shiftadd" parameters, and is very useful for testing. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/1058> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 5

[Einstein Toolkit] #1053: CarpetIOHDF5: it doesn't honor out3D_every parameter
by Einstein Toolkit 05 Sep '12

05 Sep '12

#1053: CarpetIOHDF5: it doesn't honor out3D_every parameter --------------------------------------+------------------------------------- Reporter: bmundim | Owner: eschnett Type: defect | Status: new Priority: major | Milestone: Component: Carpet | Version: Keywords: CarpetIOHDF5 out3D_every | --------------------------------------+------------------------------------- Hi, I have noticed a strange behaviour of CarpetIOHDF5 when running a bbh simulation with Lovelace release: it doesn't seem to follow the parameter out3D_every. I have attached a modified version of CarpetWaveToyCheckpointTest.par that reproduces this error. I tried to mimic a bbh simulation setup I am using in terms of number of refinement levels (it also helps to slow down the simulation a bit) and what I was interested to output. The experiment goes as follows: 1) create two directories, 000 and 001, where you can copy the attached par file to. Symlink a cactus executable for ET on each directory. Both development and lovelace releases will show this problem. You should have something like this: {{{ [bruno@frozenstar wavetoytest]$ ls 0* 000: cactus_einstein@ CarpetWaveToyCheckpointTest.par 001: cactus_einstein@ CarpetWaveToyCheckpointTest.par }}} 2) Run the executable on both directories. First on 000 and then on 001. {{{ ./cactus_einstein CarpetWaveToyCheckpointTest.par }}} 3) Analyze the results. Everything goes all right on the first directory, 000: {{{ [bruno@frozenstar CarpetWaveToyCheckpointTest]$ h5ls wavetoy::scalarevolve.xyz.h5 Parameters\ and\ Global\ Attributes Group WAVETOY::phi\ it=0\ tl=0\ rl=0 Dataset {43, 43, 43} WAVETOY::phi\ it=0\ tl=0\ rl=1 Dataset {41, 41, 41} WAVETOY::phi\ it=0\ tl=0\ rl=2 Dataset {33, 33, 33} WAVETOY::phi\ it=0\ tl=0\ rl=3 Dataset {33, 33, 33} WAVETOY::phi\ it=0\ tl=0\ rl=4 Dataset {33, 33, 33} WAVETOY::phi\ it=0\ tl=0\ rl=5 Dataset {33, 33, 33} WAVETOY::phi\ it=0\ tl=0\ rl=6 Dataset {33, 33, 33} WAVETOY::phi\ it=0\ tl=0\ rl=7 Dataset {33, 33, 33} WAVETOY::phi\ it=0\ tl=0\ rl=8 Dataset {33, 33, 33} WAVETOY::phi\ it=128\ tl=0\ rl=1 Dataset {41, 41, 41} WAVETOY::phi\ it=128\ tl=0\ rl=2 Dataset {33, 33, 33} WAVETOY::phi\ it=128\ tl=0\ rl=3 Dataset {33, 33, 33} WAVETOY::phi\ it=128\ tl=0\ rl=4 Dataset {33, 33, 33} WAVETOY::phi\ it=128\ tl=0\ rl=5 Dataset {33, 33, 33} WAVETOY::phi\ it=128\ tl=0\ rl=6 Dataset {33, 33, 33} WAVETOY::phi\ it=128\ tl=0\ rl=7 Dataset {33, 33, 33} WAVETOY::phi\ it=128\ tl=0\ rl=8 Dataset {33, 33, 33} WAVETOY::phi\ it=256\ tl=0\ rl=0 Dataset {43, 43, 43} WAVETOY::phi\ it=256\ tl=0\ rl=1 Dataset {41, 41, 41} WAVETOY::phi\ it=256\ tl=0\ rl=2 Dataset {33, 33, 33} WAVETOY::phi\ it=256\ tl=0\ rl=3 Dataset {33, 33, 33} WAVETOY::phi\ it=256\ tl=0\ rl=4 Dataset {33, 33, 33} WAVETOY::phi\ it=256\ tl=0\ rl=5 Dataset {33, 33, 33} WAVETOY::phi\ it=256\ tl=0\ rl=6 Dataset {33, 33, 33} WAVETOY::phi\ it=256\ tl=0\ rl=7 Dataset {33, 33, 33} WAVETOY::phi\ it=256\ tl=0\ rl=8 Dataset {33, 33, 33} }}} You can see above that all refinement levels were correctly output every 128 iterations as it was set on the par file. That doesn't happen anymore after recovery, ie on the second directory, 001: {{{ [bruno@frozenstar CarpetWaveToyCheckpointTest]$ h5ls wavetoy::scalarevolve.xyz.h5 Parameters\ and\ Global\ Attributes Group WAVETOY::phi\ it=262\ tl=0\ rl=7 Dataset {33, 33, 33} WAVETOY::phi\ it=262\ tl=0\ rl=8 Dataset {33, 33, 33} WAVETOY::phi\ it=390\ tl=0\ rl=7 Dataset {33, 33, 33} WAVETOY::phi\ it=390\ tl=0\ rl=8 Dataset {33, 33, 33} }}} neither 262 or 390 are multiples of 128! So something is going really wrong here. Note however that the respective 2D slice is correct: {{{ [bruno@frozenstar CarpetWaveToyCheckpointTest]$ h5ls wavetoy::scalarevolve.xy.h5 Parameters\ and\ Global\ Attributes Group WAVETOY::phi\ it=384\ tl=0\ rl=1 Dataset {41, 41} WAVETOY::phi\ it=384\ tl=0\ rl=2 Dataset {33, 33} WAVETOY::phi\ it=384\ tl=0\ rl=3 Dataset {33, 33} WAVETOY::phi\ it=384\ tl=0\ rl=4 Dataset {33, 33} WAVETOY::phi\ it=384\ tl=0\ rl=5 Dataset {33, 33} WAVETOY::phi\ it=384\ tl=0\ rl=6 Dataset {33, 33} WAVETOY::phi\ it=384\ tl=0\ rl=7 Dataset {33, 33} WAVETOY::phi\ it=384\ tl=0\ rl=8 Dataset {33, 33} }}} 384 is a multiple of 128 and as you can see all active refinement levels for that iteration were written down. Any idea on how to fix this? Thanks! -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/1053> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 29

[Einstein Toolkit] #1031: write index files for checkpoints
by Einstein Toolkit 05 Sep '12

05 Sep '12

#1031: write index files for checkpoints --------------------------+------------------------------------------------- Reporter: rhaas | Owner: eschnett Type: enhancement | Status: new Priority: minor | Milestone: Component: Carpet | Version: Keywords: CarpetIOHDF5 | --------------------------+------------------------------------------------- this patch writes index files for checkpoints if output_index is set. This is (only) useful if the checkpoints will be read in by a different number of processes than written. In that case, parsing the index files is faster than parsing the heavy data files. The two patches provide read and write functionality. The attached C code creates index files from existing HDF5 files (not necessary checkpoints). It is a modified copy of hdf5_extract from the HDF5 thorn. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/1031> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 11

[Einstein Toolkit] #1063: GRHydro_InitData update
by Einstein Toolkit 05 Sep '12

05 Sep '12

#1063: GRHydro_InitData update -----------------------------------+---------------------------------------- Reporter: rhaas | Owner: Type: defect | Status: new Priority: major | Milestone: Component: EinsteinToolkit thorn | Version: Keywords: GRHydro_InitData | -----------------------------------+---------------------------------------- attach please find patches to bring Zelmani and trunk GRhydro_InitData in sync again. Mostly they add hot EOS support, but also there is a fix for a double definition of initial_Bvec both as a restricted parameter in HydroBase and a private parameter in GRHydro. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/1063> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 3

← Newer
1
...
11
12
13
14
15
16
17
...
21
Older →

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

Trac August 2012