Trac August 2014

trac@lists.einsteintoolkit.org

1 participants
127 discussions

[Einstein Toolkit] #1204: carpet bug
by Einstein Toolkit 22 Mar '15

22 Mar '15

#1204: carpet bug -------------------------------------+-------------------------------------- Reporter: abdik@… | Owner: eschnett Type: defect | Status: new Priority: major | Milestone: Component: Carpet | Version: Keywords: | -------------------------------------+-------------------------------------- The latest version of carpet seems to contain a bug that affects AMR+multipatch runs. My stderr and stdout and par file are attached. Found by Roland and Ernazar. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/1204> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 3

[Einstein Toolkit] #997: problem in appending output after recovery
by Einstein Toolkit 22 Mar '15

22 Mar '15

#997: problem in appending output after recovery ----------------------------------------+----------------------------------- Reporter: corvino.giovanni@… | Owner: eschnett Type: defect | Status: new Priority: major | Milestone: Component: Carpet | Version: Keywords: | ----------------------------------------+----------------------------------- I have a problem in appending output files from Carpet. I used to produce 3d HDF5 output of grid variables and write the output in the same directory also after recovery from checkpoint. The new output was automatically appended to the existing one. Now I am producing h5 output also on 2D slices but in this case the output is overwritten so I lost the data for all but the last recovery. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/997> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 3

[Einstein Toolkit] #1624: remove MOLDOESCOMPLEX from MoL
by Einstein Toolkit 02 Feb '15

02 Feb '15

#1624: remove MOLDOESCOMPLEX from MoL -----------------------------------+---------------------------------------- Reporter: knarf | Owner: Type: enhancement | Status: new Priority: optional | Milestone: Component: EinsteinToolkit thorn | Version: development version Keywords: | -----------------------------------+---------------------------------------- MOLDOESCOMPLEX is an old #define in MoL, and seems to be unused for quite some time now. It also comes with the comment "even using it probably doesn't work" in the commit. I suggest to remove it (removing the code within). -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/1624> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 8

[Einstein Toolkit] #1518: Parameter parser and CCTK_ParameterSet interpret leading zeros in numbers differently
by Einstein Toolkit 28 Jan '15

28 Jan '15

#1518: Parameter parser and CCTK_ParameterSet interpret leading zeros in numbers differently --------------------+------------------------------------------------------- Reporter: rhaas | Owner: Type: defect | Status: new Priority: minor | Milestone: Component: Cactus | Version: development version Keywords: | --------------------+------------------------------------------------------- the parameter parser allows things like: {{{ thorn::param1 = 011 thorn::param2 = 012.34 }}} in parameter files. For floating point values this is a bit unexpected but otherwise mostly harmless. For integers the situation is a bit more complex since in C a leading zero is used to indicate a octal number. And (worse) while the parameter file parser converts the string "011" to the number 11 the Cactus call CCTK_ParameterSet will convert it to 9. The difference is ultimately the difference between calling atof (Parser) and strtol (CCTK_ParameterSet). To avoid confusion it would likely be good to change CCTK_ParameterSet to behave the way the Parameter parser does. This is a change in behaviour compared to the pre-Piraha parser, however I suspect the number of users that actually used octal (or hexedecimal) notation in their parameter files is small. The change is to change {{{inval = strtol (value, &endptr, 0);}}} to {{{inval = strtol (value, &endptr, 10);}}} in line 2209 of src/main/Parameters.c and similar in line 2270. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/1518> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 27

[Einstein Toolkit] #1635: hwloc requires a certain minimum version, but does not check for it
by Einstein Toolkit 20 Jan '15

20 Jan '15

#1635: hwloc requires a certain minimum version, but does not check for it --------------------+------------------------------------------------------- Reporter: knarf | Owner: Type: defect | Status: new Priority: major | Milestone: ET_2014_11 Component: Cactus | Version: development version Keywords: | --------------------+------------------------------------------------------- Currently, hwloc's configuration.sh searched for any hwloc library and uses it. However, it requires a pretty new version within some of its own files, which leads to build failure on, e.g. Debian stable systems. The attached patch uses pkg-config to get the version of the installed hwloc library and if that version is older than 1.6 (educated guess, but see http://lists.einsteintoolkit.org/pipermail/users/2013-February/002860.html), builds the bundled version even if another version is installed (but too old). Note that this is done (intentionally) only if no library was specified, and the script was looking for it by itself. This allows users to specify something which will not be overwritten by this mechanism. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/1635> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 14

[Einstein Toolkit] #428: Forbid configuration names ending in -reconfig
by Einstein Toolkit 12 Jan '15

12 Jan '15

#428: Forbid configuration names ending in -reconfig ----------------------+----------------------------------------------------- Reporter: eschnett | Owner: Type: defect | Status: new Priority: minor | Milestone: Component: Cactus | Version: Keywords: | ----------------------+----------------------------------------------------- I accidentally created a Cactus configuration with a name like "sim- reconfig". This confuses Cactus, because the command "make sim-reconfig" can then mean either to build the "sim-reconfig" configuration, or to reconfigure the "sim" configuration. Cactus should catch and forbid these cases. This is probably most cleanly handled by using a script instead of a Makefile to interpret the user commands. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/428> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 12

[Einstein Toolkit] #1610: Switch Cactus to 64 bits
by Einstein Toolkit 29 Dec '14

29 Dec '14

#1610: Switch Cactus to 64 bits -------------------------+-------------------------------------------------- Reporter: eschnett | Owner: Type: enhancement | Status: new Priority: major | Milestone: Component: Cactus | Version: development version Keywords: | -------------------------+-------------------------------------------------- Although pointers can have 64 bits, integers in Cactus are de facto (since we use "int" in many places) restricted to 32 bits. This limit is easily reached, and this has in fact been a problem on at least two occasions. One issue comes from Carpet's numbering of grid points. With 25 refinement levels, the coarse grid can be at most 127^3, and this limit was reached in production simulations years ago. Another issue comes from large 1D arrays. It is easily possible to have a 1D array with 10M (10^7) elements that is replicated across processes (distrib=const). In this case, one can use at most 200 MPI processes. We should devise a plan to switch Cactus to 64 bits. One option would be to replace most "int" by "CCTK_INT", so that those affected can switch these to 64 bits. I want to note that using 64-bit loop counters is often slightly faster than using 32-bit loop counters (on 64-bit architectures), since the 32->64 bit conversion for array indexing can be omitted. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/1610> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 3

[Einstein Toolkit] #1565: change default of IOUtil::out_save_parameters to true
by Einstein Toolkit 15 Dec '14

15 Dec '14

#1565: change default of IOUtil::out_save_parameters to true -------------------------+-------------------------------------------------- Reporter: rhaas | Owner: Type: enhancement | Status: new Priority: optional | Milestone: Component: Cactus | Version: development version Keywords: | -------------------------+-------------------------------------------------- it would be useful of HDF5 files contained the full set of parameter values. This can be used by postprocessing scripts to find out eg about the symmetry conditions or some of the grid structure parameters as well as atmosphere settings. IOUtil::out_save_parameters controls whether the full set of parameters or only those that have been steered are written to file (for regular output, checkpoints always write all parameters). I would like to change the default so that all parameters are always written. If feasible I would even want to write all parameter changes to file (either as full parameter dumps for each output or as a full dump when the simulation starts then deltas afterwards). -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/1565> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 19

[Einstein Toolkit] #1628: Enable padding by default
by Einstein Toolkit 09 Dec '14

09 Dec '14

#1628: Enable padding by default -----------------------------------+---------------------------------------- Reporter: eschnett | Owner: Type: enhancement | Status: new Priority: major | Milestone: Component: EinsteinToolkit thorn | Version: development version Keywords: | -----------------------------------+---------------------------------------- Enable padded allocation in Carpet by default. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/1628> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 2

[Einstein Toolkit] #1630: ML_BSSN harmonic shift is ill-posed
by Einstein Toolkit 09 Dec '14

09 Dec '14

#1630: ML_BSSN harmonic shift is ill-posed -----------------------------------+---------------------------------------- Reporter: eschnett | Owner: Type: defect | Status: new Priority: major | Milestone: Component: EinsteinToolkit thorn | Version: development version Keywords: | -----------------------------------+---------------------------------------- The implementation of the ML_BSSN harmonic shift is ill-posed. It should use the evolved Gamma variables instead of taking metric derivatives. A robust stability test clearly shows an instability: higher resolutions have faster growing errors. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/1630> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 1

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

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

Trac August 2014