Users August 2023

users@lists.einsteintoolkit.org

19 participants
27 discussions

Problems running BBH example
by Praveer Krishna 03 Sep '23

03 Sep '23

Hello, I've downloaded and configured the Einstein Toolkit on my desktop, but I'm having an issue when I try to run the BBH example provided here <https://einsteintoolkit.org/gallery/bbh/index.html> and the BNS simulation from here <https://einsteintoolkit.org/gallery/bns/index.html>. The job finishes in an instant, producing the attached error file. (I'm using the command "simfactory/bin/sim create-submit GW150914_28 --define N 28 --parfile par/GW150914/GW150914.rpar --procs 24 --walltime 24:00:00") There seems to be an issue with the 'num_pus' to 'num_cores' ratio in the "system_topology.cc" file, but the error oddly persists even when I manually equate them, or cut out line 471 altogether. This error does not appear when I run the tov_ET example or the HelloWorld one. I'm also able to run this mini BNS tutorial <https://www.youtube.com/watch?v=3euS5yMBFmI> without any issues, so I'm a bit baffled. I've attached my .ini file and the .cc file along with the error file in case it helps. Please take a look and let me know if I'm missing something obvious. PS: My PC has 128GB of memory, a 13900K(24C/32T) processor and 1TB of storage. Regards, Praveer

2 3

Loss of precision after postintial?
by Hayley Macpherson 01 Sep '23

01 Sep '23

Hi all, I’m the author of a cosmological initial data thorn in the ET; FLRWSolver. I’m currently working on improving the initial data to solve the constraint equations exactly (instead of previously using an approximation), for a given metric and Kij. The way this works is to calculate the metric terms on the LHS of both the constraints and solve for the relevant rest mass density and peculiar 3-velocities from the matter terms. I have my own routines from a post-processing analysis code to calculate the metric terms, and I’ve incorporated these into the ET for both generating the initial data but also then double checking the constraint violation after the initial data is set up. I noticed something strange: my checks immediately after FLRWSolver is called in the ET show the constraints are satisfied essentially to roundoff error (i.e. the momentum constraint violation has magnitude ~ 1.e-15), but when I take the 3D dump of the initial time slice and run this through my analysis code (which uses the same routines as I use to set up initial data), I see the momentum constraint is violated at the ~ 1e-7 level. I thought this might be my post processing code, so I added a second call to check the constraints using my routines after the full initial process is finished. The first call which immediately follows my FLRWSolver routine is placed in group HydroBase_Initial, and I added another call in CCTK_POSTINITIAL which gives the same result, however, if I instead schedule this call in POSTPOSTINITIAL I see the momentum constraint violation is identical to what I see when post processing the initial dump, at ~ 1.e-7. I can see the specific terms which are causing this difference are the terms which use finite-difference derivatives (the curvature terms in the momentum constraint), while all others are identical. So my question is the following: is there any way that the metric and curvature variables could suffer a loss of precision between the POSTINITIAL and POSTPOSTINITIAL phases of the run? Especially, a loss in precision which is then translated to the 3D dumps. The momentum constraint violation I have is satisfactory, but I am trying to pinpoint why this jump happens to make sure it’s not a bug in my separate code somewhere (also to explain why the constraints aren’t satisfied to roundoff level when they should be, by construction of my initial data :) ). Any help is much appreciated! 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

3 7

Meeting minutes for 2023-08-31
by Leo Rosa Werneck 31 Aug '23

31 Aug '23

Hi all, Einstein Toolkit Meeting - August 31, 2023 Chair : Peter Minute taker : Leo Present : Sam Cupp, Yosef Zlochower, Peter Diener, Leo Werneck, Zach Etienne, Roland Haas * Next ET Release - Should CarpetX be enabled or disabled by default? Sam believes it would be weird to include all of the new thorns that depend on CarpetX and then have people do extra work to have access to them. This will force everyone to have a compiler that supports C++17, but this is not a particularly high bar. Erik also supports enabling it by default. - Roland said some modification might be needed for simulation factory to account for this. There is also some consideration about the default compiler, which would mostly affect the "generic" configuration. The new configuration would need to check the system until it finds a C++17-compatible compiler, something that is currently not done. Further, some older versions of GCC require you to pass additional options to link against the correct, "experimental" standard library. - Zach shared a useful list of supported C++ features by compiler: https://en.cppreference.com/w/cpp/compiler_support/17 - Roland suggested enabling CarpetX now so that problems can be fixed as they appear. - Loop control, as it exists, prevents Carpet and CarpetX from existing in the same executable. The provided macros are drastically different for the two drivers because of the way looping is done in AMReX. One option is to have thorns require "Loop control" OR "Loop control X" so that the header file can pick the appropriate macros at compile time. This is not yet implemented, but Roland will work on it. - Peter should review GRHayLHDX, but skip GRHayLMHDX. * Unanswered Questions on the Mailing List - There are bugs in POWER. Roland will look into it. * Open Tickets: - #2754: there are different definitions of magnetic fields in the toolkit, differing by a factor of sqrt(4pi). Note that the evolution of GRMHD quantities is still consistent, as these factors are accounted for when computing the magnetic pressure that is used to compute the energy-momentum tensor. As Zach points out, this only affects very specific scenarios where direct comparisons between e.g., GRHydro and IllinoisGRMHD are performed. - In the future, it would be nice do modify the Seed_Magnetic_Fields thorns from WVUThorns* to provide a more user friendly way of setting up the magnetic fields (for example, the user can specify the ratio of magnetic to fluid pressure). Next week's chair : Zach Next week's minute taker : Roland Cheers, Leo ------ 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

POWER code issues
by Anuj Kankani 31 Aug '23

31 Aug '23

Hi, I was recently suggested the POWER ( https://git.ncsa.illinois.edu/elihu/Gravitational_Waveform_Extractor/) code for some GW extrapolation work I was doing by Gabriele Bozzola but I believe I found some bugs and he suggested I send an email here. Running the script as is on the GW150914 gallery example gives me results significantly different from what the plots on the ET website show. I found replacing where the code currently fits the strain amplitude and phase to a polynomial expression with numpy polyfit seems to fix the main problem. I also noticed in the getCutoffFrequencyFromTwoPuncturesBBH function, lines 341 - 347 have an incorrect equation for angular momentum, it looks like a typo between position and momentum. Right now its position * momentum - momentum^2. I'm not sure if this code is being actively used, but I saw there were git branches for the latest ET release. Thanks, Anuj Kankani

2 1

Einstein Toolkit Meeting Reminder
by rhaas＠illinois.edu 30 Aug '23

30 Aug '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

Agenda for Thursday's Meeting
by rhaas＠illinois.edu 28 Aug '23

28 Aug '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

Error Estimation for RK45CK
by Garrison, David 24 Aug '23

24 Aug '23

Hello, Where in the MoL is the error estimates for RK45 calculated? I can’t seem to find that in the source code. Somehow they are written to the MOL::ERRORESTIMATE grid function but I can’t see where that is done. -DG -- David Garrison, Ph.D. Associate Dean for the College of Science and Engineering, Professor and Founding Chair of Physics University of Houston-Clear Lake Bayou 3611 Houston, TX 77058 Phone: 281-283-3796 https://www.uhcl.edu/science-engineering/faculty/garrison-david http://www.uhcl.edu/physics "If we knew what it was we were doing, it would not be called research, would it?" — Albert Einstein.

3 3

Meeting Minutes, August 24, 2023
by Cupp, Samuel D. 24 Aug '23

24 Aug '23

Chair - Leo Minutes - Sam Attendees - Roland Peter Yosef ET_2023_11 release SpaceTimeX likely will not be included Yosef - this means there's no spacetime evolution thorn, greatly reducing what can be done with CarpetX While true, these thorns are also on Erik's plate, for the most part, and he is busy with CarpetX release. They also haven't been used for a publication or an equivalent quality control. Even if CarpetX is included without a spacetime evolution thorn, having CarpetX in the toolkit will simplify future releases with CarpetX-based codes. Also, if people want to use the Z4c thorn in SpacetimeX, they can still check it out at their own peril. AsterX also doesn't have a publication, so the reviewer will need to check whether AsterX is actually ready for inclusion. Is the paper just limited by writing, or is something still not working correctly? Roland - I think there was an issue with TOV star evolution, but I don't know if that was resolved. Bruno hasn't responded in regard to being a reviewer for the AsterX arrangement. Sam - Samuel Tootle volunteered to review it, though I don't know if one person is enough for the whole arrangement. I'll make sure the reviewer(s) clarify whether AsterX is completely working and the paper is just a matter of writing, or if there's still something being debugged. Unanswered emails: "Loss of precision after postintial?" Con2Prim runs after initial data is set, even with checkpoint/restart. This means that the data can potentially change depending on which evolution thorn is being used. Since finite differences were mentioned, one could also try increasing resolution and see how this affects the precision. Tickets: Ticket 2749<https://bitbucket.org/einsteintoolkit/tickets/issues/2749/wvuthorns-sprintf…> - Leo will address this issue. Next week's meeting: Chair - Peter Minute taker - Leo Samuel Cupp Postdoctoral Researcher Department of Physics University of Idaho

1 0

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

23 Aug '23

1 0

Agenda for Thursday's Meeting
by rhaas＠illinois.edu 21 Aug '23

21 Aug '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

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

Users August 2023