Trac October 2014

trac@lists.einsteintoolkit.org

1 participants
147 discussions

[Einstein Toolkit] #1617: Calls to Accelerator_NotifyDataModified should be paired with calls to Accelerator_RequireInvalidData
by Einstein Toolkit 25 Mar '15

25 Mar '15

#1617: Calls to Accelerator_NotifyDataModified should be paired with calls to Accelerator_RequireInvalidData -----------------------------------+---------------------------------------- Reporter: sbrandt | Owner: Type: defect | Status: new Priority: minor | Milestone: Cactus_4.3.0 Component: EinsteinToolkit thorn | Version: development version Keywords: | -----------------------------------+---------------------------------------- Calls to Accelerator_NotifyDataModified should be paired with calls to Accelerator_RequireInvalidData, otherwise there's a risk of seg fault in Accelerator_NotifyDataModified due to a missing accelerator data structure. MoL fails to do this in Operators.c. Patch attached. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/1617> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 3

[Einstein Toolkit] #1612: reace condition when building Cactus utilities
by Einstein Toolkit 24 Mar '15

24 Mar '15

#1612: reace condition when building Cactus utilities --------------------+------------------------------------------------------- Reporter: rhaas | Owner: Type: defect | Status: new Priority: minor | Milestone: Component: Cactus | Version: development version Keywords: | --------------------+------------------------------------------------------- I just compiled on bluewaters and received output {{{ Done creating cactus_simO3. All done ! Building utilities for simO3 Building utilities for simO3 ... Creating hdf5_recombiner in /mnt/a/u/sciteam/rhaas/ET_trunk/exe/simO3 from /mnt/a/u/sciteam/rhaas/ET_trunk/configs/simO3/build/CarpetIOHDF5/hdf5_recombiner.o mkdir: cannot create directory `/tmp/1399318629': File exists mkdir: cannot create directory `/tmp/1399318629': File exists }}} with the full (last part of) the log in the attached file. So it seems as if we have a race condition in the make system that causes it to try and build the utilities twice (in parallel). On bluewaters simfactory (which I used) builds Cactus using 16 processes. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/1612> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 7

[Einstein Toolkit] #1613: provide CCTK_VParamWarm
by Einstein Toolkit 22 Mar '15

22 Mar '15

#1613: provide CCTK_VParamWarm -------------------------+-------------------------------------------------- Reporter: rhaas | Owner: Type: enhancement | Status: new Priority: optional | Milestone: Component: Cactus | Version: development version Keywords: | -------------------------+-------------------------------------------------- it would be nice if there was a CCTK_VParamWarn along with CCTK_PARAMWARN, analogous to CCTK_VWarn and CCTK_WARN. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/1613> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 1

[Einstein Toolkit] #1326: running loopcontrol on strange number of threads fails
by Einstein Toolkit 22 Mar '15

22 Mar '15

#1326: running loopcontrol on strange number of threads fails -----------------------------------+---------------------------------------- Reporter: rhaas | Owner: Type: defect | Status: new Priority: minor | Milestone: Component: EinsteinToolkit thorn | Version: Keywords: LoopControl | -----------------------------------+---------------------------------------- my machine has 8 cores (according to /proc/cpuinfo). Running eg the trigger test with 3 threads fails inside of loopcontrol. To reproduce: {{{ export OMP_NUM_THREADS=3 mpirun -n 2 exe/cactus_bns_all arrangements/AEIThorns/Trigger/test/trigger.par }}} -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/1326> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 1

[Einstein Toolkit] #1361: disable hyperthreading in loopcontrol by default
by Einstein Toolkit 22 Mar '15

22 Mar '15

#1361: disable hyperthreading in loopcontrol by default -----------------------------------+---------------------------------------- Reporter: rhaas | Owner: Type: defect | Status: new Priority: major | Milestone: Component: EinsteinToolkit thorn | Version: Keywords: LoopControl | -----------------------------------+---------------------------------------- when running with both openmp and sufficiently many threads that hyperthreading threads are used, many tests using LoopControl (Cartoon, RotatingSymmety180, RotatingSymmetry90) fail. This can be tracked down to disabling hyperthreading support in LoopControl (ie. turning of hyperthreading makes things work). In particular on bethe with smt and 8 physical cores: The Cartoon/test_cartoon_2.par test shows differences from the recorded results when run with 16 threads (but not with 8 threads). If I then go ahead and disable OMP in all ML source files but ML_BSSN_enforce *and* comment out the #include "loopcontrol.h", then the difference goes away. Adding back #include "loopcontrol.h" brings back the error. Some further experimenting with LoopControl's options shows that indeed the use_smt_threads option is what causes problems. If I turn it off things work fine even with a vanilla source tree. Otherwise relative differences are on the order 1e-7 and absolute 1e-11 (in momx_z_[2][2].xg). Without smt the results are identical to the stored values. The issue only occurs in combination of OpenMP, vectorization and hyperthreading. The issue is independent of the compiler (both intel 13 and gcc 4.4 show the same behaviour), and vectorization (sse2) and many threads (up to 4 times the number of physical cores) works fine on non-smt machines. I propose to disable LoopControl::use_smt_threads by default. Note that we cannot completely remove it since apparently for Vesta (a Blue Gene/Q) smt is required to get and multi-threading at all. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/1361> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 4

[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] #1663: VisIT CarpetHDF5 plugin pseudocolor error
by Einstein Toolkit 20 Jan '15

20 Jan '15

#1663: VisIT CarpetHDF5 plugin pseudocolor error ---------------------------------------+------------------------------------ Reporter: bruno.giacomazzo@… | Owner: Type: defect | Status: new Priority: major | Milestone: Component: Other | Version: development version Keywords: visit | ---------------------------------------+------------------------------------ This problem has been present since the CarpetHDF5 plugin for VisIt became part of the standard VisIt distribution and it is still present in the current version of VisIt (2.8). When Pseudocolor is used in log scale and Centering is set to Original or Nodal, not all the values of the plotted quantity are shown (in particular lower values are not plotted at all). This does not happen if one sets Centering to Zonal, which instead shows the correct values. I have attached a couple of images showing the problem (they show hydrobase::rho for a BNS run). I do not know what may be causing it, but it may cause serious errors when analyzing data with VisIt (since one may miss some of the information on the low value regions). -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/1663> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 4

← 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 October 2014