Users November 2023

users@lists.einsteintoolkit.org

12 participants
21 discussions

Trouble Building Cactus Thorns on Mac and on Expanse
by Joe Hellmers 07 Dec '23

07 Dec '23

Hello, I’d like to use Hyrdro_RNSID in order to generate a initial data for a rotating neutron star, but I’m having some difficulties building the Cactus thorns. Initially I’m just trying to build all of them. When I try to build on my Mac using the latest GNU compilers from Brew, I get a message that my compiler doesn’t support std c11. The version of gcc installed is Apple clang version 15.0.0 (clang-1500.0.40.1), whatever that gcc version that ends up being. If I use the gcc from the MESA SDK, (version 12.2.0) I get the same message. So, I switched to try it on the SDSC Expanse cluster, and at least I don’t get that problem, but I do end of having an issue that it is looking for some Slurm include files from a version that isn’t on expanse any more. Specifically it is looking under /cm/shared/apps/slurm/20.02.3/ but Expanse now has /cm/shared/apps/slurm/21.08.8. So I have a few questions 1) How can I just build what I need for Hydro_RNSID? 2) What can I do about building on my Mac? 3) Where can I change the configuration of my build so that it refers to the correct Slurm version when building on Expanse? Thanks! Joe Hellmers San Diego State University- Physics Dept.

2 1

Meeting minutes for 2023-11-30
by Leo Rosa Werneck 30 Nov '23

30 Nov '23

Present: Leo, Steve, Zach, Peter, Sam, Roland Chair: Steve Minutes: Leo * ET Release: = Blockers: - Locked simfactory repo was fixed - presync-only option in CarpetX was fixed - NSIMD compilation issues still present -> Any cluster which cannot access to the internet will fail -> Dependency on Python package 'requests' -> Dependency on OpenSSL -> Roland will try to fix today = ET gallery examples: - TOV started (Peter) - BBH started (Deborah) - BNS not started (Steve) - Scalar wave not started (TBD) - Poisson equation not started (TBD) = ET Testing: - Deep Bayou (Tests ran a couple of weeks ago with a couple of failures) - SuperMike (Tests ran a couple of weeks ago with a couple of failures) -> test_o11 (from CarpetProlongateTest) -> ML_BSSN_NewRad (from ML_BSSN_Test) -> ML_BSSN_O8_sgw3d (from ML_BSSN_Test) - SuperMUC (Compiled, can't run) - Delta (Compiled + Run) - Expanse (Compiled + Run) - Summit (Not done yet) - Sunrise (Tests ran and got a couple of failures) -> Balsara0 (from GRHayLHDX) -> sphere_pugh_ppm (from Hydro_InitExcision) -> rnsA2 (from Hydro_RNSID) -> ML_BSSN_NewRad (from ML_BSSN_Test) -> ML_BSSN_O8_sgw3d (from ML_BSSN_Test) - Frontera (Not done yet due to NSIMD compilation issues) - Gabriele Bozzola ran tests on Anvil and some failed: -> sphere_pugh_ppm (from Hydro_InitExcision) -> memspeed (from MemSpeed) -> checkpoint-openpmd (from TestOutput) -> output-openpmd (from TestOutput) -> recover-openpmd (from TestOutput) = Sam will push on getting the Zenodo and release announcement ready * ET contribution to springer book on GRMHD codes = Need more writers (currently only Leo, Sam, and Zach) = No progress to report * SPEC contribution = No update * Open questions on the mailing list = Roland will look into compilation issues on Mac OS * Open tickets = None discussed until release is done * Other stuff = Roland asked Steve to update the ET youtube channel = Discussion on creating a repository for numerical relativity gravitational waveforms, and the ET could offer this to the community - Hardware requirements include a few TB for data storage ------ Leonardo R. Werneck, Ph.D. Postdoctoral researcher Office EP 314 | Department of Physics | University of Idaho 875 Perimeter Dr. MS 0903 Moscow, ID 83844-0903, USA leonardo(a)uidaho.edu <mailto:leonardo@uidaho.edu> https://leowerneck.github.io <https://leowerneck.github.io/>

1 0

Einstein Toolkit Meeting Reminder
by rhaas＠illinois.edu 29 Nov '23

29 Nov '23

Hello, Please consider joining the weekly Einstein Toolkit phone call at 9:00 am US central time on Thursdays. For details on how to connect and what agenda items are to be discussed, use the link below. https://docs.einsteintoolkit.org/et-docs/Main_Page#Weekly_Users_Call --The Maintainers

1 0

Workshop "New frontiers in strong gravity III" in Benasque - 1st announcement
by Helvi Witek 29 Nov '23

29 Nov '23

Dear colleagues, The third installment of the two-week workshop “New frontiers in strong gravity” will take place in Benasque, Spain from Jul 07–19, 2024. The registration will open in Spring 2024. Please see the website http://benasque.org/2024relativity/ for further information. Summary: The highly nonlinear, strong-field regime of gravity holds the key to address long-standing puzzles in modern physics. These range from theoretical questions concerning the nature of gravity, the quest for a consistent theory of quantum gravity and resulting modifications to general relativity, to new insights into nuclear matter under extreme conditions in the context of neutron star and multi-messenger astronomy. In this two-week workshop (Jul 07–19, 2024) we will bring together leading experts as well as junior scientists and PhD students in these diverse research areas, to encourage communication and training across the fields and to foster new research collaborations. Invited speakers include: Alessandra Buonanno - Chiara Caprini* - Vitor Cardoso - Ramiro Cayuso - Pippa Cole - Isabel Cordero Carrión - Maxence Corman - Alex Grant - Lavinia Heisenberg - Aaron Held - Leah Jenks - Andrea Mitridate - Jaki Noronha-Hostler*- Ornella Piccinni - Jocelyn Read - Harvey Reall* - Horng Sheng Chia - Banafshe Shiralilou - Justin Vines - Jordan Wilson-Gerow * To be confirmed We would appreciate it if you could forward the announcement to interested researchers in our field. We look forward to welcoming you in Benasque Helvi, On behalf of the organizers (D. Blas, P. Figueras, S. Nissanke, L. Stein, H. Witek) --------------------------------------------- Dr. Helvi Witek Assistant Professor Department of Physics University of Illinois at Urbana-Champaign 247 Loomis Lab 1110 W Green St Urbana, IL 61801 ---------------------------------------------

1 0

Fwd: Scientific software developer in computational astrophysics at the University of the Balearic Islands, SPAIN
by Helvi Witek 29 Nov '23

29 Nov '23

Dear all, please find an announcement below for a position as scientific software developer at UIB to work with Carlos Palenzuela (in cc). Best wishes, Helvi --------------------------------------------- Dr. Helvi Witek Assistant Professor Department of Physics University of Illinois at Urbana-Champaign 247 Loomis Lab 1110 W Green St Urbana, IL 61801 --------------------------------------------- -------- Forwarded Message -------- Subject: Scientific software developer in computational astrophysics at the University of the Balearic Islands, SPAIN Date: Mon, 27 Nov 2023 11:26:56 +0000 From: Carlos Palenzuela Luque <carlos.palenzuela(a)uib.es> Reply-To: Carlos Palenzuela Luque <carlos.palenzuela(a)uib.es> To: consortium(a)lisamission.org <consortium(a)lisamission.org> Dear colleagues, We are looking to fill a scientific software developer position in at UIB (Palma de Mallorca), Spain. The Relativity and Gravitation group at the University of the Balearic Islands (UIB) offers a 2-year position for a scientific software developer. The successful candidate will support our research in computational astrophysics and numerical relativity through the development of the scientific software Simflowny, a cloud-based open environment for scientific dynamical models, with a user-friendly Integrated Development Environment, which automatically generates parallel code for simulation frameworks (for more details see https://bitbucket.org/iac3/simflowny/wiki/Home <https://urldefense.com/v3/__https://bitbucket.org/iac3/simflowny/wiki/Home_…> ). He/she will work under the supervision of Dr. Carlos Palenzuela and Dr. Joan Masso’. The group also includes faculty members Prof. Carles Bona and Dr. Fernando Abalos. The starting date can be negotiated, but it should be somewhere between April and September 2024. The annual gross salary is ~ 30000 EUR. Minimal requirement will be a bachelor’s degree or equivalent in computer science, astronomy, physics or a related discipline, with software developing experience and knowledge in Java, C++, Python and Linux/Unix. Excellent oral and written communication skills either in English or Spanish. Applicants should send a curriculum vitae, including a brief description of previous experience and interests, to be sent to carlos.palenzuela[AT]uib.es. *The deadline for full consideration is January 30, 2024.* Best regards, Carlos Palenzuela

1 0

Agenda for Thursday's Meeting
by rhaas＠illinois.edu 27 Nov '23

27 Nov '23

Please update the Wiki with agenda items for Thursday's meeting. Thanks! https://docs.einsteintoolkit.org/et-docs/meeting_agenda --The Maintainers

1 0

ETK config-stage failure with Macports gcc -- C+11 range-based for statments?
by Bernard Kelly 21 Nov '23

21 Nov '23

Hi. I tried making a new configuration on my Macbook (MacOS Ventura, 13.6.2) after a gap of several months, and it's now failing the "make sim-config" step with a complaint about the C++ compiler not being C++11-compliant -- end of the make config step screen output is below. I'm using the latest available Macports-supplied GNU compilers (gcc-mp-13, g++-mp-13, etc.), with the following C & C++ options: ---------- compiler flags ----------- CPP = /opt/local/bin/cpp-mp-13 CC = /opt/local/bin/gcc-mp-13 CXX = /opt/local/bin/g++-mp-13 CPPFLAGS = CFLAGS = -std=c99 CXXFLAGS = -std=c++14 C_LINE_DIRECTIVES = yes OPTIMISE = yes CPP_OPTIMISE_FLAGS = # -DCARPET_OPTIMISE -DNDEBUG C_OPTIMISE_FLAGS = -O2 -march=native CXX_OPTIMISE_FLAGS = -O2 -march=native OPENMP = yes CPP_OPENMP_FLAGS = -fopenmp C_OPENMP_FLAGS = -fopenmp CXX_OPENMP_FLAGS = -fopenmp WARN = yes CPP_WARN_FLAGS = -Wall C_WARN_FLAGS = -Wall CXX_WARN_FLAGS = -Wall ---------- end of compiler flags ----------- Can anyone suggest what's up? The error says that the C++ compiler is failing to do range-based for statements, but I can compile & run a simple program with a range-based for statement, so this seems unlikely. I'm currently on ET_2023-05, but have this problem with ET_2022_11 as well, and with gcc-mp-12. Thanks, Bernard --------------- last bit of screen output --------- checking if compiler has broken omp collapse... no checking for getopt_long_only... yes checking for working const... yes checking for C inline... inline checking for C static inline... static inline checking for C restrict... restrict checking for C++ restrict... __restrict__ checking for C++ copysign... std::copysign checking for C++ fpclassify... std::fpclassify checking for C++ isfinite... std::isfinite checking for C++ isinf... std::isinf checking for C++ isnan... std::isnan checking for C++ isnormal... std::isnormal checking for C++ signbit... std::signbit checking for C _Pragma... yes checking for C function __attribute__((__const__))... yes checking for C++ function __attribute__((__const__))... yes checking for C++ member function __attribute__((__const__))... yes checking for C function __attribute__((__pure__))... yes checking for C++ function __attribute__((__pure__))... yes checking for C++ member function __attribute__((__pure__))... yes checking for C data __attribute__((__common__))... yes checking for C+ data __attribute__((__common__))... yes checking for C function __attribute__((__noinline__))... yes checking for C++ function __attribute__((__noinline__))... yes checking for C++ member function __attribute__((__noinline__))... yes checking for C function __attribute__((__always_inline__))... yes checking for C++ function __attribute__((__always_inline__))... yes checking for C++ member function __attribute__((__always_inline__))... yes checking for C __attribute__((__unused__))... yes checking for C++ __attribute__((__unused__))... yes checking for C __attribute__((__aligned__(...)))... yes checking for C++ __attribute__((__aligned__(...)))... yes checking for C __attribute__((__cold__))... yes checking for C++ __attribute__((__cold__))... yes checking for C __attribute__((__hot__))... yes checking for C++ __attribute__((__hot__))... yes checking for C __attribute__((__format__(printf, 1, 2)))... yes checking for C++ __attribute__((__format__(printf, 1, 2)))... yes checking for C __attribute__((__noreturn__))... yes checking for C++ __attribute__((__noreturn__))... yes checking for C __attribute__((__nonnull__))... yes checking for C++ __attribute__((__nonnull__))... yes checking for C __attribute__((__returns_nonnull__))... yes checking for C++ __attribute__((__returns_nonnull__))... yes checking for C __builtin_expect... yes checking for C++ __builtin_expect... yes checking for C __builtin_trap... yes checking for C++ __builtin_trap... yes checking for C __builtin_unreachable... no checking for C++ __builtin_unreachable... no checking for C __builtin_assume_aligned... yes checking for C++ __builtin_assume_aligned... yes checking for C++ static_assert... yes checking for C++ auto specifier... yes checking for C++ lambda expressions... yes checking for C++ range-based for statements... no Cactus requires a C++11 compiler -- check your C++ compiler and C++ compiler flags Error reconfiguring sim-config make: *** [sim-config] Error 2 -- ------------------------------------------------------------------ Bernard Kelly -- CRESST Assistant Research Scientist, NASA/GSFC Gravitational Astrophysics Laboratory --- Code 663 Phone: +1 (301) 286-7243 *** Fax: +1 (301) 286-2226 Web: http://science.gsfc.nasa.gov/sed/bio/bernard.j.kelly ORCID: orcid.org/0000-0002-3326-4454 ------------------------------------------------------------------

3 6

Fwd: [Associati] 2-year postdoc at INAF Padova (PRIN 2022 "EMERGE")
by Bruno Giacomazzo 20 Nov '23

20 Nov '23

FYI ---------- Forwarded message --------- Da: Ciolfi, Riccardo <riccardo.ciolfi(a)inaf.it> Date: ven 10 nov 2023 alle ore 15:20 Subject: [Associati] 2-year postdoc at INAF Padova (PRIN 2022 "EMERGE") To: <ricercatori(a)ced.inaf.it>, <associati(a)ced.inaf.it>, < contrattisti(a)ced.inaf.it> Dear Colleagues, I would like to advertise the opening of a 2-year postdoc position (Assegno di Ricerca) at INAF-Osservatorio Astronomico di Padova funded via the PRIN MUR 2022 project "EMERGE - Neutron star mergers and the origin of short gamma-ray bursts" (PI: Riccardo Ciolfi) The selected candidate will study the formation of relativistic jets in binary neutron star mergers and their propagation across the surrounding post-merger environment via a combination of general and special relativistic magnetohydrodynamic simulations. For further details please find attached the official call, both in English and in Italian. I also encourage any interested candidates to contact me. The deadline for the application is *December 4th 2023*. Best, Riccardo Ciolfi

1 0

ML_BBSN shift evolution equation
by Robyn Munoz 17 Nov '23

17 Nov '23

Hello everyone, Could someone please clarify the shift evolution equation implemented in ML_BSSN? Just looking at the parameter file it seems like it is: d/dt beta^i = shiftGammaCoeff Xt^i - betaDriver alpha^shiftAlphaPower beta^i looking at McLachlan_BSSN.m (for GammaDriver and without advection and dissipation), I think it is: d/dt beta^a = shiftGammaCoeff alpha^shiftAlphaPower B^awith d/dt B^a = d/dt Xt^a - betaDriver B^a Whereas looking at Alcubierre's book Eq 4.3.33 and 4.3.34 I would expect it to be d/dt beta^i = B^iwith d/dt B^i = shiftGammaCoeff alpha^shiftAlphaPower d/dt Xt^a - betaDriver B^a on the McLachlan webpage: https://www.cct.lsu.edu/~eschnett/McLachlan/the link to describe the Gamma driver shift condition http://grwiki.physics.ncsu.edu/wiki/Shift_Conditions doesn't work but looking at the 2019 version on the wayback machine the evolution described is d/dt beta^a = (3/4) B^awith d/dt B^a = d/dt Xt^a - betaDriver B^a where here (and in Alcubierre) d/dt = partial_t - beta^c partial_c. Does the McLachlan code have that second term beta^c partial_c ? This is confusing me, so what is actually implemented? Where are the parameters shiftGammaCoeff, betaDriver and shiftAlphaPower in the evolution equation? And these are all constant positive reals right? In Alcubierre's book xi (that I think is shiftGammaCoeff) can be function of space and the lapse. Thank you,Robyn

2 1

"Spikes" in density for FLRWSolver single-mode simulation
by Hayley Macpherson 16 Nov '23

16 Nov '23

Hi all, I’ve noticed an issue with the single-mode setting of FLRWSolver (cosmological initial data thorn) when evolving with GRHydro. This set up is three intersecting sine-waves in 3D, see the attached 1D slice for the relative density perturbation (delta = rho / rho.mean - 1) on the initial slice (first plot attached). To do cosmological simulations which are dark-matter dominated we want something as close to P=0 as possible. GRHydro does not allow this so instead we choose a pressure such that P<<rho. Specifically, we choose a Polytropic EOS with poly_gamma=2 and set poly_k to be very small to achieve this. This has worked in the past, but recently I’ve noticed something strange in the perturbations themselves. I have previously used this setup back in 2017 and didn’t notice this issue, so I’m unsure if it’s something in a recent version of the ET or something different in the parameter file I’m setting. Also just to note - I am aware that Eloisa’s code allows for P=0, however, having a small amount of pressure in the simulations is actually beneficial at late times when the structures are nonlinear (it stops the code from crashing too early and allows us to get further into the nonlinear regime). So for this reason I prefer to continue using GRHydro for now. I’ve attached a parameter file which will reproduce the problem I’m seeing (which initialises the figure shown below). The second plot I’ve attached shows the same simulation 5 iterations later (the 1D slice is 1/4 of the way through the domain, at index 8 in this example), where at the base of the sine wave you can see the “spike” starting to grow. This continues to grow throughout the simulation to be very large (the last plot is the same simulation after 400 iterations, for example). Also to note, this perturbation is small enough such that for the entire simulation it *should* remain very closely approximated by a sine wave. I’ve pinpointed this issue to be sensitive to the value of poly_k that I choose for the simulations. Changing the value of poly_k changes the time in the simulation at which this occurs (it happens later on for larger values of poly_k), but then we reach a point at which the P<<rho condition we require is not satisfied anymore for large values of poly_k. I’ve chosen an extreme value of poly_k in the attached parameter file so that the problem happens early on and it might be easier to diagnose. It seems like this is occurring at the minima and maxima of the sine wave, so I thought it might be something related to the fact the derivatives are very small at these points with a small poly_k such as we’re choosing. I thought that instead of trying to find the “sweet spot” where that these spikes don’t occur *and* we can satisfy P<<rho, there might actually be a fix from someone who knows GRHydro much better than I do. If anyone is able to help me I would very much appreciate it! Best wishes, Hayley ---- Hayley Macpherson | NASA Einstein Fellow Email: hjmacpherson(a)uchicago.edu Pronouns: she/her/hers Office: ERC 479 Kavli Institute for Cosmological Physics Eckhardt Research Center 5640 South Ellis Avenue Chicago, IL, 60637

2 1

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

Users November 2023