Trac August 2018

trac@lists.einsteintoolkit.org

1 participants
59 discussions

[Einstein Toolkit] #1889: correct finding normalization value for relerr compuation
by Einstein Toolkit 31 Aug '18

31 Aug '18

#1889: correct finding normalization value for relerr compuation --------------------+------------------------------------------------------- Reporter: rhaas | Owner: Type: defect | Status: new Priority: major | Milestone: Component: Cactus | Version: development version Keywords: | --------------------+------------------------------------------------------- Before it would have taken the larger of the abs value of the new and old data of the last data set rather than the largest abs value of the new and old data of all the datasets. This will make relative errros smaller and will be particularly noticeable in cases where the last dataset was small or zero. This should get rid of the "Error, how did I get here" warnings (that really indicated an logic error). -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/1889> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 4

[Einstein Toolkit] #1885: support bibtex in thorn documenation files
by Einstein Toolkit 28 Aug '18

28 Aug '18

#1885: support bibtex in thorn documenation files -------------------------+-------------------------------------------------- Reporter: rhaas | Owner: Type: enhancement | Status: new Priority: optional | Milestone: Component: Cactus | Version: development version Keywords: | -------------------------+-------------------------------------------------- The pull request https://bitbucket.org/cactuscode/cactus/pull-requests/new?source=rhaas /docs-bibtex&t=1 adds support for bibtex to Cactus' documentation system. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/1885> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 16

[Einstein Toolkit] #2055: Move gallery examples to EinsteinExamples repository
by Einstein Toolkit 28 Aug '18

28 Aug '18

#2055: Move gallery examples to EinsteinExamples repository -------------------------------------+-------------------------------------- Reporter: hinder | Owner: Type: enhancement | Status: new Priority: minor | Milestone: Component: EinsteinToolkit website | Version: development version Keywords: | -------------------------------------+-------------------------------------- The [http://einsteintoolkit.org/gallery.html Einstein Toolkit Gallery examples] parameter files could be moved from the [https://bitbucket.org/einsteintoolkit/www/src/master/gallery/?at=master www] repository to the [https://bitbucket.org/einsteintoolkit/einsteinexamples/src/master/par/?at=m… EinsteinExamples] repository and arrangement. This would mean: * They are checked out when someone downloads the ET, avoiding a separate web browser or curl download * They will have branches like the rest of the ET, so they can be associated with a given release if necessary Note that this will separate them from the other related material on the website, such as thornlists, images, etc, but I think it is worth it to make it easier for new users. Eventually, we hope that all the gallery examples will use the standard ET thornlist anyway. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/2055> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 6

[Einstein Toolkit] #2042: new thorns for hydro analysis
by Einstein Toolkit 28 Aug '18

28 Aug '18

#2042: new thorns for hydro analysis -------------------------+-------------------------------------------------- Reporter: knarf | Owner: Type: enhancement | Status: new Priority: optional | Milestone: Component: Other | Version: development version Keywords: | -------------------------+-------------------------------------------------- The LSU and Parma groups developed, and used for publications, a set of two thorns for analysis of hydro quantities, in particular for mode analysis. We would like to have those included in the Einstein Toolkit. We are aware that a few things are still missing for that (documentation, test suites), but before we go that extra step and create all of that, we want to be sure the following is seen as 'ok': The main thorn (GRHydro_Analysis, _not_ to be specific to GRHydro, it only inherits hydrobase - could and should probably be renames) does reductions of quire a few quantities. In practice, the memory required for this turned out to be a problem on some machines. These reductions are done at ANALYSIS, which means even telling Cactus to allocate/deallocate not once, globally, but instead doing that every time step does not help. Thus, there is a second thorn, a utility thorn called 'TempPool'. It's task is nothing else than to provide an array of grid functions that are always allocated, but which can be used by other thorns for, reductions - and, and this is the interesting part - can be re-used by other thorns, for other reductions after that; within the same time step in ANALYSIS. This is how TempPool is used by GRHydro_Analysis. TempPool is not tied to GRHydro_Analysis. Any other thorn can also request storage there, but there currently isn't another thorn. It just seemed to good idea to split this functionality. The book keeping already now makes sure that the number of allocated grid functions is only as large the maximum of any thorn using it. The relevant code can be found here: https://bitbucket.org/GravityPR/prthorns/src I'd like another developer to have a look and give input. Once/If this is deemed ok to be included, we will add the necessary documentation and test suites and make a proper proposal for inclusion. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/2042> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 6

[Einstein Toolkit] #2189: Carpet/CarpetLib: Add Lagrange_third_order_prolong prolongation option.
by Einstein Toolkit 24 Aug '18

24 Aug '18

#2189: Carpet/CarpetLib: Add Lagrange_third_order_prolong prolongation option. -------------------------+--------------------------------- Reporter: zachetie@… | Owner: rhaas@… Type: enhancement | Status: assigned Priority: unset | Milestone: Component: Other | Version: development version Keywords: | -------------------------+--------------------------------- When the default prolongation type is chosen in a dynamical spacetime evolution, hydrodynamic and GRMHD fields can suffer from spurious oscillations generated at AMR refinement boundaries due to the high-order Lagrange polynomial prolongation. As there is no way to directly specify the prolongation order in the interface.ccl, I have created a Carpet pull request that adds the desired order (3rd) Lagrange polynomial prolongation: https://bitbucket.org/eschnett/carpet/pull-requests/21/ I would like this to be the default prolongation option for IllinoisGRMHD and GiRaFFE, so it would be immediately useful. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/2189> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 0

[Einstein Toolkit] #2173: Test "Poisson equation" example
by Einstein Toolkit 24 Aug '18

24 Aug '18

#2173: Test "Poisson equation" example -------------------------------------+--------------------------------- Reporter: Roland Haas | Owner: shawngr2@… 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/poisson/index.html still works and produces correct output. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/2173> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 9

[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

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

Trac August 2018