Trac December 2018

trac@lists.einsteintoolkit.org

1 participants
17 discussions

[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] #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] #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] #2106: Make ParseFile.c more robust
by Einstein Toolkit 17 Dec '18

17 Dec '18

#2106: Make ParseFile.c more robust ----------------------+----------------------------------------------------- Reporter: eschnett | Owner: Type: defect | Status: new Priority: unset | Milestone: Component: Cactus | Version: development version Keywords: | ----------------------+----------------------------------------------------- We don't check for all the errors yet. https://bitbucket.org/cactuscode/cactus/pull-requests/45/flesh-make- parsefilec-a-bit-more-robust/diff -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/2106> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 22

[Einstein Toolkit] #2213: simfactory should abort earlier if runscript, submitscript or thornlist are wrong
by Einstein Toolkit 14 Dec '18

14 Dec '18

#2213: simfactory should abort earlier if runscript, submitscript or thornlist are wrong ---------------------------------+------------------------- Reporter: Steven R. Brandt | Type: enhancement Status: new | Priority: optional Milestone: | Component: SimFactory Version: development version | Keywords: ---------------------------------+------------------------- Right now simfactory will go through the Cactus sim-config stage before it checks if eg the thornlist is incorrect (does not exist). {{{ [sbrandt@wothw Cactus]$ ./simfactory/bin/sim build --thornlist doesnotexist Using configuration: sim Reconfiguring sim Writing configuration to: /home/sbrandt/cactus/Cactus/configs/sim/OptionList CUSTOMIZED MAKE Cactus - version: 4.2.3 Reconfiguring sim. Adding configuration options from '/home/sbrandt/cactus/Cactus/configs/sim/OptionList'... Setting VERSION to '2018-01-25' Setting CPP to 'cpp' Setting CC to 'gcc' Setting CXX to 'g++' Setting FPP to 'cpp' Setting F90 to 'gfortran' Setting CPPFLAGS to '' Setting FPPFLAGS to '-traditional' Setting CFLAGS to '-g -std=gnu99' Setting CXXFLAGS to '-g -std=gnu++0x' [...] Use make foo to build the configuration. Complete rebuild required Cleaning sim Cleaning configuration sim Deleting all built files in /home/sbrandt/cactus/Cactus/configs/sim Warning: default submit script contents have changed Updated script file for configuration sim Warning: default run script contents have changed Updated runscript file for configuration sim Error: specified thornlist "doesnotexist" does not exist or is not readable tried paths "/home/sbrandt/cactus/Cactus/doesnotexist" and "/home/sbrandt/cactus/Cactus//repos/simfactory2/etc/thornlists/doesnotexist", working directory is "/home/sbrandt/cactus/Cactus" Aborting Simfactory. }}} It may be nice to detect this earlier. See https://bitbucket.org/simfactory/simfactory2/pull-requests/28/simlib- make-non-existing-cactusfile-fatal/diff#comment-85638965 for a discussion. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/2213> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 0

[Einstein Toolkit] #331: SimFactory does not abort if it has been given a nonexistent optionlist
by Einstein Toolkit 13 Dec '18

13 Dec '18

#331: SimFactory does not abort if it has been given a nonexistent optionlist ------------------------+--------------------------------------------------- Reporter: hinder | Owner: mthomas Type: defect | Status: new Priority: major | Milestone: Component: SimFactory | Version: Keywords: | ------------------------+--------------------------------------------------- If I specify a nonexistent optionlist in a machine's .ini file, I get the warning Info: optionlist is: None Warning: no option list specified, using blank option list This is incorrect. I have specified an optionlist, but it has not been found, which indicates an error. In this case I would expect a fatal error. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/331> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 5

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

Trac December 2018