Trac January 2019

trac@lists.einsteintoolkit.org

1 participants
17 discussions

[Einstein Toolkit] #2215: Hydro_RNSID cleanup
by Einstein Toolkit 28 Jan '19

28 Jan '19

#2215: Hydro_RNSID cleanup ---------------------------------+----------------------------------- Reporter: Roland Haas | Type: defect Status: new | Priority: optional Milestone: | Component: EinsteinToolkit thorn Version: development version | Keywords: Hydro_RNSID ---------------------------------+----------------------------------- * Hydro_RNSID: respect CPPFLAGS when building utilities * Hydro_RNSID: remove unused variables Adding CPPFLAGS to CFLAGS when compiling is what the Cactus build system does (see lib/make/make.config.rules.in and search for $(CPPFLAGS)). Pull request is here: https://bitbucket.org/einsteintoolkit/einsteininitialdata/pull-requests/5 -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/2215> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 2

[Einstein Toolkit] #2223: reduce compiler warnings from Hydro_RNSID
by Einstein Toolkit 28 Jan '19

28 Jan '19

#2223: reduce compiler warnings from Hydro_RNSID ---------------------------------+-------------------- Reporter: Roland Haas | Type: defect Status: new | Priority: unset Milestone: | Component: Other Version: development version | Keywords: ---------------------------------+-------------------- This is mostly just removing some variable declarations. However I also turned a while loop into a do..while loop (the code already assumed that the while loop would loop at least once). -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/2223> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 4

[Einstein Toolkit] #1974: Add WVUThorns_Diagnostics to the ET
by Einstein Toolkit 25 Jan '19

25 Jan '19

#1974: Add WVUThorns_Diagnostics to the ET --------------------------------+------------------------------------------- Reporter: zachetie@… | Owner: Type: enhancement | Status: new Priority: unset | Milestone: Component: Other | Version: development version Keywords: | --------------------------------+------------------------------------------- I have open-sourced a very useful set of diagnostic routines for GRMHD, GRHD, and even vacuum simulations. The thorns are available here: https://bitbucket.org/zach_etienne/wvuthorns_diagnostics Here's a brief description of each thorn: Brief description of included thorns '''Seed_Magnetic_Fields-modified''' Extended Seed_Magnetic_Fields thorn for binary neutron stars. Supercedes Seed_Magnetic_Fields thorn. '''Meudon_Bin_NS-modified''' Modifications to Meudon BNS initial data thorn to disable the overwriting of initial lapse/shift, which acts to significantly reduce coordinate eccentricity. Supercedes Meudon_Bin_NS thorn. '''VolumeIntegrals_GRMHD''' Nice GRMHD volume integration thorn, currently depends on IllinoisGRMHD and Carpet. Performs volume integrals on arbitrary "Swiss-cheese"-like topologies, and even interoperates with Carpet to track NS centers of mass. '''VolumeIntegrals_vacuum''' Nice GRMHD volume integration thorn, currently depends on ML_BSSN. There is a bit of code duplication and duplicated functionality between VI_GRMHD and VI_vacuum, to ensure that VI_vacuum can be used without enabling a GRMHD code. There is probably a better way of doing this, but I haven't had the time to think deeply about this. '''particle_tracerET''' Solves the ODE \partial_t x^i = v^i for typically thousands of tracer particles, using an RK4 integration atop the current timestepping. E.g., one RK4 substep in the particle integration might occur every 16 RK4 substeps in the GRMHD evolution. These tracer particle positions are quite useful for visualizing magnetic field lines in a consistent way from frame-to-frame in a movie (recall that in the GRMHD approximation, the magnetic field lines stay attached the fluid elements they thread ["Flux Freezing"]). Note that the velocity must be consistent with the velocity appearing in the GRMHD induction equation. This thorn reads in the HydroBase vel[] vector gridfunction, which assumes the Valencia formalism, and converts it into the induction equation velocity. '''smallbPoynET''' Computes b^i^, b^2^, and three spatial components of Poynting flux. It also computes (-1-u,,0,,), which is useful for tracking unbound matter. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/1974> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 8

[Einstein Toolkit] #2161: make ET mailing lists searchable
by Einstein Toolkit 25 Jan '19

25 Jan '19

#2161: make ET mailing lists searchable ---------------------------------+---------------------------- Reporter: Roland Haas | Type: enhancement Status: new | Priority: minor Milestone: | Component: Cactus website Version: development version | Keywords: ---------------------------------+---------------------------- Right now there is no explicit search field for the Einstein Toolkit mailing lists. Google apparently indexes them. At the ET meeting at GeorgiaTech in 2018 it was suggested that a FAQ as well as the ability to search the mailing list would be useful. Such a functionality should be added to the ET wiki and ET website respectively. Something like this: {{{ <form action="https://www.google.com/search" class="searchform" method="get" name="searchform" target="_blank"> <input name="sitesearch" type="hidden" value="example.com"> <input autocomplete="on" class="form-control search" name="q" placeholder="Search in example.com" required="required" type="text"> <button class="button" type="submit">Search</button> </form> }}} seems to work and one can limit to particular lists by setting site to something like {{{site:lists.einsteintoolkit.org/pipermail/users}}} -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/2161> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 5

[Einstein Toolkit] #2101: Add Lean_public and Proca thorns to the ET
by Einstein Toolkit 25 Jan '19

25 Jan '19

#2101: Add Lean_public and Proca thorns to the ET -------------------------------------------------------+-------------------- Reporter: miguel.zilhao.nogueira@… | Owner: Type: enhancement | Status: new Priority: unset | Milestone: ET_2018_08 Component: EinsteinToolkit thorn | Version: development version Keywords: Lean_public | -------------------------------------------------------+-------------------- As discussed during the European ET meeting in Mallorca and during the 2018-01-22 ET telecon, we have a couple of Cactus thorns that we'd like to make available to the general ET community. These include: an updated evolution code that we used to evolve Proca fields (https://arxiv.org/abs/1505.00797), the corresponding analysis and initial data thorns, as well as a general metric evolution thorn (based on Uli Sperhake's Lean). We have been cleaning up the codes, and they are now available in following (public) bitbucket repositories: https://bitbucket.org/canuda/lean_public https://bitbucket.org/canuda/proca Included are some testsuites as well as some basic README files. We are currently working on a paper that would also serve as documentation. We would be very grateful if these could be considered for inclusion in the 2018_08 release. Sincerely, Helvi Witek Miguel Zilhão -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/2101> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 7

[Einstein Toolkit] #2217: EinsteinAnalysis/Hydro_Analysis Thorn new feature
by Einstein Toolkit 25 Jan '19

25 Jan '19

#2217: EinsteinAnalysis/Hydro_Analysis Thorn new feature ---------------------------------+----------------------------------- Reporter: fcipolletta | Type: enhancement Status: new | Priority: unset Milestone: ET_2019_02 | Component: EinsteinToolkit thorn Version: development version | Keywords: Hydro_Analysis ---------------------------------+----------------------------------- Added EinsteinAnalysis/Hydro_Analysis/Hydro_Analysis_Masses.F90 in order to compute the total baryonic mass and baryonic mass within user defined radii. Added parameters to params.ccl in order to control the aforementioned computation. Added a testuite for this new feature. I have already submitted a pull request for this new feature. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/2217> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 7

[Einstein Toolkit] #2222: Testsuite code should remove output directories before tests
by Einstein Toolkit 24 Jan '19

24 Jan '19

#2222: Testsuite code should remove output directories before tests ---------------------------------+-------------------- Reporter: Roland Haas | Type: defect Status: new | Priority: major Milestone: | Component: Cactus Version: development version | Keywords: ---------------------------------+-------------------- The current testsuite driver code does not remove output directories ins TEST/sim/THORN which can hide issues if a new revision of the code simply no longer produces an output file if an older test is still present. There is also one test (Hydro_RNSID/rnsA2.par) that internally writes and reads data to a file while it runs. If the file is already present, then not all code is tested. To test this, place a new file into an output directory, run the tests and the file will still be present. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/2222> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 0

[Einstein Toolkit] #2221: update hwloc to 1.11.12
by Einstein Toolkit 24 Jan '19

24 Jan '19

#2221: update hwloc to 1.11.12 ---------------------------------+----------------------------------- Reporter: Roland Haas | Type: defect Status: new | Priority: major Milestone: | Component: EinsteinToolkit thorn Version: development version | Keywords: hwloc ---------------------------------+----------------------------------- version 1.11 add support of KNL processor (see https://raw.githubusercontent.com/open-mpi/hwloc/v1.11/NEWS): > Version 1.11.0 > * Detection improvements > + Add support for Intel Knights Landing Xeon Phi. > Thanks to Grzegorz Andrejczuk and Lukasz Anaczkowski. since we claim to support KNL CPUs (eg on stampede2) this should be included. The tarball of the source code (not in the patch) is here: https://download.open-mpi.org/release/hwloc/v1.11/hwloc-1.11.12.tar.gz -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/2221> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 2

[Einstein Toolkit] #1718: MemSpeed: Re-use allocated memory
by Einstein Toolkit 23 Jan '19

23 Jan '19

#1718: MemSpeed: Re-use allocated memory -----------------------------------+---------------------------------------- Reporter: eschnett | Owner: Type: enhancement | Status: new Priority: minor | Milestone: Component: EinsteinToolkit thorn | Version: development version Keywords: | -----------------------------------+---------------------------------------- Allocating memory is slow. In thorn MemSpeed, we should re-use memory that has been allocated instead of allocating new memory for each benchmark. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/1718> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 6

[Einstein Toolkit] #2220: add option --nioprocs to CarpetIOHDF5
by Einstein Toolkit 18 Jan '19

18 Jan '19

#2220: add option --nioprocs to CarpetIOHDF5 ---------------------------------+----------------------------------- Reporter: Roland Haas | Type: enhancement Status: new | Priority: minor Milestone: | Component: EinsteinToolkit thorn Version: development version | Keywords: CarpetIOHDF5 ---------------------------------+----------------------------------- This lets one use hdf5_slicer to extract datasets from foo.file_0.h5 and foo.file_1.h5 into bar.file_0.h5 and bar.file_1.h5 and still be able to use them afterwards (useful eg to separate out files written with one_file_per_group, to extract only certain timesteps). Currently, one has to resort to the lower level hdf5_extract and write some shell code like this {{{ for i in grid-coordinates.file*.h5 ; do for d in x y z ; do h5ls $i | gawk -vd=$d '{sub(" (Dataset|Group).*",""); gsub("\\\\",""); if(match($0,"GRID::"d) || /Parameters/) { print }}' >dsets.txt hdf5_extract dsets.txt $i $d.${i#*.} done done }}} to achieve this. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/2220> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 1

[Einstein Toolkit] #2219: fix sqrt() for AVX512, updates to Vectors thorn
by Einstein Toolkit 17 Jan '19

17 Jan '19

#2219: fix sqrt() for AVX512, updates to Vectors thorn -----------------------------------+--------------------------------- Reporter: Roland Haas | Owner: Roland Haas Type: defect | Status: assigned Priority: critical | Milestone: ET_2019_02 Component: EinsteinToolkit thorn | Version: development version Keywords: Vectors | -----------------------------------+--------------------------------- This pull request mostly add better support for the AVX512 instructions found in KNL and modern Intel Xeon / Core iN CPUs. There is one bugfix commit “Correct error in AVX512 sqrt implemention” which is important for those architectures (eg to compute sqrt(detg)). I am marking this as critical until I can verify that without this fix the result of a BBH simulation on eg Stampede2 is not incorrect because of using an incorrect sqrt() function. Pull request is here: https://bitbucket.org/cactuscode/cactusutils/pull- requests/17/rhaas-avx512/diff -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/2219> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 2

[Einstein Toolkit] #2218: Simplify including external files in Formaline
by Einstein Toolkit 17 Jan '19

17 Jan '19

#2218: Simplify including external files in Formaline ---------------------------------+----------------------------------- Reporter: Erik Schnetter | Type: enhancement Status: new | Priority: optional Milestone: | Component: EinsteinToolkit thorn Version: development version | Keywords: ---------------------------------+----------------------------------- Formaline uses a complicated mechanism to include tarballs of the thorns into the executable, requiring running perl scripts and adding additional source files. This can be simplified. See <https://hsyl20.fr/home/posts/2019-01-15-fast-file-embedding-with- ghc.html> for how to implement this. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/2218> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 1

[Einstein Toolkit] #2216: Vectors: allow seamless interaction with scalar types
by Einstein Toolkit 16 Jan '19

16 Jan '19

#2216: Vectors: allow seamless interaction with scalar types ---------------------------------+----------------------------------- Reporter: Roland Haas | Type: enhancement Status: new | Priority: minor Milestone: | Component: EinsteinToolkit thorn Version: development version | Keywords: Vectors ---------------------------------+----------------------------------- * Vectors: allow implicit cast from scalar_t * Vectors: provide binary operations with scalars one needs both {{{ operatorX(T, vectype<T>) }}} and {{{ operatorX(vectype<T>, T) }}} for both commuting and non-commuting operators Pull request is here: https://bitbucket.org/cactuscode/cactusutils/pull- requests/16/rhaas-inclict-conv/diff -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/2216> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 5

[Einstein Toolkit] #2211: gh::regrid contains code whose runtime is quadratic in number of components
by Einstein Toolkit 10 Jan '19

10 Jan '19

#2211: gh::regrid contains code whose runtime is quadratic in number of components ---------------------------------+-------------------- Reporter: Roland Haas | Type: defect Status: new | Priority: minor Milestone: | Component: Carpet Version: development version | Keywords: ---------------------------------+-------------------- The member function gh::regrid contains this code {{{ // Check component consistency for (int ml = 0; ml < mglevels(); ++ml) { for (int rl = 0; rl < reflevels(); ++rl) { assert(components(rl) >= 0); for (int c = 0; c < components(rl); ++c) { ibbox const &b = extent(ml, rl, c); ibbox const &b0 = extent(ml, rl, 0); assert(all(b.stride() == b0.stride())); assert(b.is_aligned_with(b0)); for (int cc = c + 1; cc < components(rl); ++cc) { assert((b & extent(ml, rl, cc)).empty()); } } } } }}} which b/c of the {{{c}}} and {{cc}} loops is quadratic in the number of components (MPI ranks). For many (tens of thousands) components this becomes a dominant cost of the regrid operation. The Carpet branch {{{rhaas/quadratic_regrid_time}}} contains a test thorn ArrayTest and a hacked version of Carpet that can simulate a number of MPI ranks using just one rank. One can run: {{{ mpirun -n 1 exe/cactus_sim arrangements/Carpet/ArrayTest/par/array.par }}} and control the number of pretend ranks by setting {{{ArrayTest::size}}} in array.par. On my workstation regrid takes ~3.5s for 16k ranks with the consistency check and ~0.5s without. This is per grid array and per grid scalar. So for a typical setup with ~400 grid arrays and grid scalars (no matter whether they have storage or not) this amounts to 400 * 3s = 1200s of time spent in the consistency check. This happens only once per simulation (since grid arrays and grid scalars are only regrid once) but for a test simulation can be quite significant (at scale). The branch actually arranges for the consistency check to be skipped if one defines {{{CARPET_OPTIMISE}}}. I attach a gnuplot script that takes carpet-timing-statistics.0000.txt and shows how much time is spent in dh and gh regrid. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/2211> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 10

[Einstein Toolkit] #2194: Memory increase during regridding
by Einstein Toolkit 10 Jan '19

10 Jan '19

#2194: Memory increase during regridding ---------------------------------+-------------------- Reporter: wolfgang.kastaun@… | Type: defect Status: new | Priority: unset Milestone: | Component: Other Version: development version | Keywords: ---------------------------------+-------------------- I still have the problem that my BNS runs consume increasing memory during inspiral, where regridding happens. It limits the runtime of typical BNS runs to around 1 day, then they are killed by memory exhaustion. After merger, with fixed grid structure, the problem goes away. It happens with two different codes, WhiskyThermal+McLachlan and WhiskyMHD+McLachlan, on all clusters I use (hydra, marconi, supermuc, fermi, ..), and all releases I used: Payne, Brahe, Tesla, Wheeler. Regridding controled using CarpetRegrid2. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/2194> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 13

[Einstein Toolkit] #2184: PAPI does not detect ifort correctly
by Einstein Toolkit 10 Jan '19

10 Jan '19

#2184: PAPI does not detect ifort correctly ---------------------------------+----------------------------------- Reporter: Roland Haas | Type: defect Status: new | Priority: minor Milestone: | Component: EinsteinToolkit thorn Version: development version | Keywords: PAPI ---------------------------------+----------------------------------- PAPI's makefile attempts to set options for the fortran compiler and checks for the intel compiler suite by comparing F77 to the string ifort. This breaks since for Cactus F77 is not ifort but something along the lines of /long/path/to/ifort . The attached patch replicates the methods that the Makefile already uses to identify the C compiler to identify the F77 compiler. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/2184> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 4

[Einstein Toolkit] #2214: Cactus: handle error in gethostname
by Einstein Toolkit 10 Jan '19

10 Jan '19

#2214: Cactus: handle error in gethostname ---------------------------------+-------------------- Reporter: Roland Haas | Type: defect Status: new | Priority: minor Milestone: | Component: Cactus Version: development version | Keywords: ---------------------------------+-------------------- This works around deficiencies of the gethostname call, namely that it does not return an error of the supplied buffer is too small and that it may not include a NUL byte at the end of the buffer if the buffer was too small and the returned name was truncated. This should not happen (often) in practise since glibc already has a similar workaround in place, but may happen eg on a Mac if they indeed use a non glibc C library. Pull request is here: https://bitbucket.org/cactuscode/cactus/pull- requests/55/cactus-handle-error-in-gethostname/diff -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/2214> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 1

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

Trac January 2019