Trac

trac@lists.einsteintoolkit.org

8708 discussions

[Einstein Toolkit] #2119: The binary neutron star gallery example gives different results with the release candiate.
by Einstein Toolkit 22 Aug '18

22 Aug '18

#2119: The binary neutron star gallery example gives different results with the release candiate. ---------------------+------------------------------------------------------ Reporter: diener | Owner: Type: defect | Status: new Priority: blocker | Milestone: ET_2018_02 Component: Other | Version: development version Keywords: | ---------------------+------------------------------------------------------ The late part of the waveform plot looks very different in the release candidate than on the gallery page. For l=2, m=2 mode of psi_4 extracted at R=300 (that seems to be the correct data file as otherwise the scale on the y-axis don't match) the merger seem to happen slightly later and the waveform after merger is completely different. The gallery page plot: [[Image(/home/diener/tmp/mp_Psi4_l2_m2_r300.00.png)]] The new plot: [[Image(/home/diener/tmp/mp_Psi4_l2_m2_r300.00_new.png)]] -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/2119> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 13

[Einstein Toolkit] #2131: Boundary thorn
by Einstein Toolkit 22 Aug '18

22 Aug '18

#2131: Boundary thorn -------------------------------------------------------+-------------------- Reporter: miguel.zilhao.nogueira@… | Owner: Type: defect | Status: new Priority: major | Milestone: Component: EinsteinToolkit thorn | Version: development version Keywords: Boundary | -------------------------------------------------------+-------------------- i was trying to do a (unigrid) run with "scalar" boundary conditions on some variables but with uneven boundary width, ie width of 2 grid points on the x and y axis and 0 on the z axis. in the documentation of the Boundary thorn it states that one should create a table passing this information in an array called "BOUNDARY_WIDTH": "The table handle identifies a table which holds extra arguments for the particular boundary condition that is requested. For example, if a negative value is passed for the boundary width, then the boundary condition will look in this table for a 2d-element integer array, which holds the width of each face of the boundary (for a d dimensional grid variable). (The first element of the array holds the width of the ‘-x’ face, the second the ‘+x’ face, the third the ‘-y’ face, etc.)" so i've accordingly created the following table {{{ call Util_TableCreateFromString(param_table_handle, "BOUNDARY_WIDTH = { 2 2 2 2 0 0 }") {{{ and then registered the variables with {{{ ierr = Boundary_SelectGroupForBC(cctkGH, CCTK_ALL_FACES, -one, & param_table_handle, "ScalarBase::phi", "scalar") }}} however, i was getting errors like the following: {{{ Boundary/src/Check.c:130: BndSanityCheckWidths: Assertion `dim < (int)sizeof(dims)' failed. }}} inspecting that file, this is only triggered if {{{(boundary_widths[i] > 100 || boundary_widths[i] < 0)}}} which meant that my BOUNDARY_WIDTH array was likely not being parsed correctly. digging a little bit deeper, i've found the following in ScalarBoundary.c:138 (and analogous for the other files under CactusBase/Boundary/src): {{{ /* Determine boundary width on all faces */ /* allocate memory for buffer */ gdim = CCTK_GroupDimI(gi); if (gdim > max_gdim) { width_alldirs = (CCTK_INT *)realloc(width_alldirs, 2 * gdim * sizeof(CCTK_INT)); max_gdim = gdim; } /* fill it with values, either from table or the boundary_width parameter */ if (widths[i] < 0) { err = Util_TableGetIntArray(tables[i], gdim, width_alldirs, "BOUNDARY_WIDTH"); }}} it seems to me that this last line should be instead {{{ err = Util_TableGetIntArray(tables[i], 2 * gdim, width_alldirs, "BOUNDARY_WIDTH"); }}} for consistency with the rest of the file and with the documentation, right? indeed, with this change the errors disappeared. i've attached a simple patch that applies this on this file, but i guess an equivalent change would be needed also for the rest of the Boundary files... if this patch is correct, could this be ported to the current release? and if it's not correct, is there anything i'm missing, in order to register the boundary conditions? -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/2131> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 11

[Einstein Toolkit] #2187: comet files in simfactory use in MPI rank per node
by Einstein Toolkit 22 Aug '18

22 Aug '18

#2187: comet files in simfactory use in MPI rank per node ---------------------------------+------------------------- Reporter: Roland Haas | Type: enhancement Status: new | Priority: minor Milestone: | Component: SimFactory Version: development version | Keywords: ---------------------------------+------------------------- The current (https://bitbucket.org/simfactory/simfactory2/src/master/mdb/machines/comet.…) uses 1 MPI rank per node: {{{ max-num-threads = 24 num-threads = 24 }}} This is usually not the best way to set things up, I would eg have expected that the default choice would be something like 1 MPI rank per NUMA domain. Given that, unless limited by communication overhead, we seem to obtain fastest per-node performance when using only MPI and no OpenMP (about a factor of 50% speedup on my 12 core workstation with 2 NUMA domains) if anyone is using Comet for production work and wants to contribute their machine description file that would be great. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/2187> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 1

[Einstein Toolkit] #2182: NewRad's extrapolation methods for Gammas expect ghost zones to be valid
by Einstein Toolkit 22 Aug '18

22 Aug '18

#2182: NewRad's extrapolation methods for Gammas expect ghost zones to be valid ---------------------------------+----------------------------------- Reporter: Roland Haas | Type: defect Status: new | Priority: major Milestone: ET_2018_08 | Component: EinsteinToolkit thorn Version: development version | Keywords: ML_BSSN NewRad ---------------------------------+----------------------------------- The current stencil size for NewRad's extrapolation of the Xt (contracted Christoffel tensors) variables is 4 and the code checks for a large enough grid like so (extrap.cc line 61ff) {{{ if (dir[d]<0) { assert(bmax[d] + 4 <= (cctkGH->cctk_bbox[2*d+1] ? imax[d] : cctkGH->cctk_lsh[d])); } else if (dir[d]>0) { assert(bmin[d] - 4 >= (cctkGH->cctk_bbox[2*d] ? imin[d] : 0)); } }}} which checks (eg for {{{dir[d] > 0}}} ie an upper boundary) that, unless the *lower* boundary is a grid boundary, that there are 4 points between bmin and the beginning of the patch (0). This therefore assumes that ghost points (points 0...cctk_nghostzones) are valid since they will be used if the grid is small enough (less than 4+2*cctk_nghostzones). Currently this is not ensured by McLachlan and only points in the interior are valid. This causes the attached parfile to produce poison in the output if run with 2 MPI ranks. A fix would be to add a {{{SYNC: ML_Gamma}}} to ML_BSSN's ML_BSSN_InitialADMBase2Interior routine or to make the check in NewRad stricter, requiring that there are at least 4 points in the interior (which would also make the check simpler). My feeling would be that this also explains NaNs that people have seen when running a TOV simulation with many MPI ranks. I attach a sample parfile as well as sample output. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/2182> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 10

[Einstein Toolkit] #2008: NaNs when running static tov on >40 cores
by Einstein Toolkit 22 Aug '18

22 Aug '18

#2008: NaNs when running static tov on >40 cores -----------------------------------+---------------------------------------- Reporter: allgwy001@… | Owner: Type: defect | Status: new Priority: unset | Milestone: Component: Other | Version: ET_2016_05 Keywords: | -----------------------------------+---------------------------------------- I've been trying to run the static tov example parameter file on an HPC cluster using >40 cores, but this results in NaNs in the data. I can't remember whether the issue first appears at 40 or 41 cores (and won't be able to check this for the next few days), but using 41+ cores definitely gives me NaNs. I remember testing with 39 cores and several other lower values (down to 4), but these runs all seemed fine. So far, I've been able to run larger simulations (e.g. BBHs) on more than 40 cores (same cluster) without any apparent issues. I'll attach the static tov parameter file I used (I think I changed one or two outdated parameters), as well as the PBS script and error/output files from a static tov run on 44 cores. The static tov runs were intended for speed test purposes. The results of the speed tests I've run so far (on fewer than 40 cores) seem quite strange to me, so I'm going to attach a text file with walltimes and CPU times for these runs, too. Any comments would be appreciated! -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/2008> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

2 13

[Einstein Toolkit] #2175: Test "Single, stable neutron star" example
by Einstein Toolkit 17 Aug '18

17 Aug '18

#2175: Test "Single, stable neutron star" example -------------------------------------+--------------------------------- Reporter: Roland Haas | Owner: Roland Haas Type: task | Status: assigned Priority: major | Milestone: ET_2018_08 Component: EinsteinToolkit website | Version: development version Keywords: | -------------------------------------+--------------------------------- Before each release, check that http://einsteintoolkit.org/gallery/ns/index.html still works and produces correct output. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/2175> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 2

[Einstein Toolkit] #2167: clean up CT_MultiLevel to avoid warnings and fix a small memory leak
by Einstein Toolkit 13 Aug '18

13 Aug '18

#2167: clean up CT_MultiLevel to avoid warnings and fix a small memory leak ---------------------------------+--------------------------- Reporter: anonymous | Type: defect Status: new | Priority: minor Milestone: | Component: Other Version: development version | Keywords: CT_MultiLevel ---------------------------------+--------------------------- Pull request is here: https://bitbucket.org/eloisa/ctthorns/pull-requests/1/clean-up- ct_multilevel-to-avoid-warnings/diff -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/2167> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 2

[Einstein Toolkit] #2178: PITTNull can take a very long time to compile with the Intel compiler
by Einstein Toolkit 13 Aug '18

13 Aug '18

#2178: PITTNull can take a very long time to compile with the Intel compiler ---------------------------------+----------------------------------- Reporter: Roland Haas | Type: defect Status: new | Priority: minor Milestone: | Component: EinsteinToolkit thorn Version: development version | Keywords: NullConstr ---------------------------------+----------------------------------- Compiling on stampede2-skx (2018_02 simfactory files, so ifort 18.0.0) the file {{{NullConstr/src/NullConstr_R00.F90}}} takes a very long time (103 minutes an counting) to compile. My guess is that one has to translate its array operations to loops (similar to what was done for other source files in PITTNull), otherwise the compiler just takes too long to try and optimize the code. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/2178> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 15

[Einstein Toolkit] #1263: Multipole does not handle variable names correctly
by Einstein Toolkit 13 Aug '18

13 Aug '18

#1263: Multipole does not handle variable names correctly -----------------------------------+---------------------------------------- Reporter: hinder | Owner: Type: defect | Status: new Priority: major | Milestone: Component: EinsteinToolkit thorn | Version: Keywords: Multipole | -----------------------------------+---------------------------------------- When you specify variables for Multipole to decompose, you have the option of giving it a "name" for the variable to be used in the output filename. This is useful if you are decomposing Psi4r, with imaginary part Psi4i, and want the file to just be named "Psi4". If you don't specify a name, it is supposed to use the original variable name. However, at the moment, this last part seems to be broken. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/1263> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 5

[Einstein Toolkit] #1201: Incorrect dtshift in Exact with shift_add_{x, y, z} parameters
by Einstein Toolkit 09 Aug '18

09 Aug '18

#1201: Incorrect dtshift in Exact with shift_add_{x,y,z} parameters -----------------------------------+---------------------------------------- Reporter: barry.wardell | Owner: Type: defect | Status: new Priority: major | Milestone: Component: EinsteinToolkit thorn | Version: Keywords: | -----------------------------------+---------------------------------------- The Exact thorn has shift_add_{x,y,z} parameters for adding a constant to the shift. Considering these as a coordinate transformation using a vector v^i = [shift_add_x, shift_add_y, shift_add_z], such a transformation should affect both the shift and its time derivative. This is because the time derivative in the new coordinates differs from the time derivative in the old coordinates by a term v^j d(beta^i)/dx^j. This is correctly implemented as a 4D coordinate transformation in the EinsteinExact thorns and I have verified that the difference relative to the Exact thorn is given by this missing term. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/1201> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 5

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

Trac