Trac September 2012

trac@lists.einsteintoolkit.org

1 participants
182 discussions

[Einstein Toolkit] #1085: GetComponents link on Download page is broken
by Einstein Toolkit 13 Sep '12

13 Sep '12

#1085: GetComponents link on Download page is broken -------------------------------------+-------------------------------------- Reporter: hinder | Owner: Type: defect | Status: new Priority: major | Milestone: Component: EinsteinToolkit website | Version: Keywords: | -------------------------------------+-------------------------------------- http://einsteintoolkit.org/download/ First GetComponents link is broken. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/1085> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 3

[Einstein Toolkit] #1086: Cactus REQUIRES should not introduce a build order
by Einstein Toolkit 12 Sep '12

12 Sep '12

#1086: Cactus REQUIRES should not introduce a build order ----------------------+----------------------------------------------------- Reporter: eschnett | Owner: Type: defect | Status: new Priority: optional | Milestone: Component: Cactus | Version: Keywords: | ----------------------+----------------------------------------------------- If thorn A requires B, then thorn A needs to be configured after B, and its libraries need to be listed before B. However, there is no reason why A should be built after B. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/1086> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 2

[Einstein Toolkit] #1083: Cactus doesn't like switching thorns between arrangements
by Einstein Toolkit 10 Sep '12

10 Sep '12

#1083: Cactus doesn't like switching thorns between arrangements ----------------------+----------------------------------------------------- Reporter: eschnett | Owner: Type: defect | Status: new Priority: minor | Milestone: Component: Cactus | Version: Keywords: | ----------------------+----------------------------------------------------- When I have two thorns with the same name in different arrangements, e.g. EinsteinEvolve/GRHydro and Zelmani/GRHydro, and then modify my thorn list (which contains one of these) to instead contain the other, Cactus has strange build problems. The root of the problem seems to be that Cactus does not recognise that these are different thorns with different source files, and e.g. the dependency information is not updated. This leads to strange build problems that force me to delete the build directories for GRHydro manually after switching. One way out could be to include the arrangement name when constructing the build directory name, or to remember the arrangement name and to delete the build directory when the arrangement name changes. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/1083> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 0

[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

[Einstein Toolkit] #1072: User guide does not explain how to use boolean parameters from Fortran.
by Einstein Toolkit 05 Sep '12

05 Sep '12

#1072: User guide does not explain how to use boolean parameters from Fortran. ---------------------------+------------------------------------------------ Reporter: hinder | Owner: Type: defect | Status: new Priority: minor | Milestone: Component: Cactus | Version: Keywords: documentation | ---------------------------+------------------------------------------------ The Cactus user guide does not explain how to use boolean parameters from Fortran. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/1072> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 0

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

Trac September 2012