Trac

trac@lists.einsteintoolkit.org

8708 discussions

[Einstein Toolkit] #1746: Index error in TwoPunctures function JFD_times_dv()
by Einstein Toolkit 23 Mar '15

23 Mar '15

#1746: Index error in TwoPunctures function JFD_times_dv() -----------------------------------+---------------------------------------- Reporter: ixr5289@… | Owner: Type: defect | Status: new Priority: minor | Milestone: Component: EinsteinToolkit thorn | Version: development version Keywords: TwoPunctures | -----------------------------------+---------------------------------------- In the TwoPunctures thorn, in the file FuncAndJacobian.c, the function JDF_times_dv() contains an index error. The (A,B,phi) coordinates are defined in terms of indices (i,j,k). The current version has phi = hp * j; The j index is used to define the B coordinate. The statement should be phi = hp * k; -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/1746> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 2

[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] #1726: GRHydro updates
by Einstein Toolkit 22 Mar '15

22 Mar '15

#1726: GRHydro updates -----------------------------------+---------------------------------------- Reporter: rhaas | Owner: Type: enhancement | Status: new Priority: major | Milestone: Component: EinsteinToolkit thorn | Version: development version Keywords: GRHydro | -----------------------------------+---------------------------------------- Pull request at: https://bitbucket.org/einsteintoolkit/einsteinevolve/pull-request/4 /grhydro-updates/diff The only major change is https://bitbucket.org/einsteintoolkit/einsteinevolve/commits/cc0a1d2cb89b6d… which add WENO reconstruction for polytropes. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/1726> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 6

[Einstein Toolkit] #1730: Test failure in GRHydro's balsara4_1d
by Einstein Toolkit 21 Mar '15

21 Mar '15

#1730: Test failure in GRHydro's balsara4_1d -----------------------------------+---------------------------------------- Reporter: eschnett | Owner: Type: defect | Status: new Priority: major | Milestone: Component: EinsteinToolkit thorn | Version: development version Keywords: | -----------------------------------+---------------------------------------- I see test failures in GRHydro's balsara4_1d. The maximum absolute difference is about 1e-10, the maximum relative difference about 1e-11. This seems like a problem with tolerances. Can someone with GRHydro experience check? -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/1730> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 8

[Einstein Toolkit] #1752: GRHydro con2prim is not a projection
by Einstein Toolkit 09 Mar '15

09 Mar '15

#1752: GRHydro con2prim is not a projection -----------------------------------+---------------------------------------- Reporter: rhaas | Owner: Type: defect | Status: new Priority: minor | Milestone: Component: EinsteinToolkit thorn | Version: development version Keywords: GRHydro | -----------------------------------+---------------------------------------- For proper functionality Carpet requires that the MoL_PostStep group is a projection, that is applying it twice in a row may not change values. This is the assumption that goes eg into restriction but also into checkpoint recovery where MoL_PostStep runs on the current timelevel just after recovery. Because of this recovering a checkpoint with GRHydro active is not restoring the simulation to a bitwise identical state to what it was when writing a checkpoint. The best solution would be to make GRHydro no longer use the "old" primitives as an initial guess which would also reduce the number of SYNCs required. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/1752> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 2

[Einstein Toolkit] #1748: enable C++ code in GRHydro by default
by Einstein Toolkit 23 Feb '15

23 Feb '15

#1748: enable C++ code in GRHydro by default -----------------------------------+---------------------------------------- Reporter: rhaas | Owner: Type: defect | Status: new Priority: unset | Milestone: Component: EinsteinToolkit thorn | Version: development version Keywords: GRHydro | -----------------------------------+---------------------------------------- the C++ code is significantly faster and hopefully easier to maintain since it gets rid of the duplicated files and instead has only a single set of source files for both MHD and non MHD code. It actually passes all the test. The change is in https://bitbucket.org/einsteintoolkit/einsteinevolve /pull-request/7/grhydro-enable-c-code-by-default/diff -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/1748> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 4

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

Trac