Users

users@lists.einsteintoolkit.org

3 participants
3984 discussions

Agenda for Thursday's Meeting
by rhaas＠illinois.edu 11 Sep '23

11 Sep '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

Today: NR community call at 9am Pacific / noon NYC / 5pm London / 6pm Berlin
by Nils Vu 11 Sep '23

11 Sep '23

Dear Numerical Relativists, We’ll have our NR community call today, Monday Sep 11, 9am LA / noon NYC / 5pm London / 6pm Berlin in this Zoom room: https://caltech.zoom.us/j/87114806411 Our speakers today will be Deborah Ferguson (UT Austin / UIUC) and Jaime Redondo Yuste (NBI). - Feel free to circulate this information within the NR community. - Please subscribe to our mailing list <https://groups.google.com/u/1/a/black-holes.org/g/nr-community-call/> to receive info on the community calls in the future (or send a short message to nr-community-call+subscribe(a)black-holes.org <mailto:nr-community-call+subscribe@black-holes.org> to subscribe) and join our Slack <https://join.slack.com/t/generalrelativity/shared_invite/zt-dl4gqb6v-aAuw~p…> for discussions (channel: #nr-community-call <https://generalrelativity.slack.com/archives/C021LLTLK37>). - Please sign up for a slot <https://docs.google.com/forms/d/e/1FAIpQLSfoCnnCJve7J7Jzrpdlqw7nAbwWS_iuX_e…> in the schedule to speak at one of the community calls: https://github.com/sxs-collaboration/nr-community-call/wiki Looking forward to seeing you all later, Nils — Nils Vu, Ph.D. (he/him) Sherman Fairchild Postdoctoral Fellow in Theoretical Astrophysics California Institute of Technology

1 0

Einstein toolkit access
by Shohreh Abdolrahimi 10 Sep '23

10 Sep '23

Dear Einstein Toolkit, I am an associate professor at Cal State Pomona. I am trying to get access to the tutorials of the Einstein Toolkit. I do have an ORCID account. However, I received an error when submitting the form that I should enter a correct email address. However, there is no place to enter the email address. I've attached the file for you to look over.

1 0

meeting minutes for 2023-09-07
by Roland Haas 07 Sep '23

07 Sep '23

Present: Roland, Steve, Peter, Yosef, Sam, Johnny, Leo, Zach ET release: * deadline to include thorns in thornlist was yesterday, none have been added ** Sam asks for a reviewer to look at GRHayl thornlist, Steve will look at pull request ** CarpetX still has issues, Roland will fix LoopControl problem ** no updates from SGRID Tickets: * merging SeedMagneticField in https://bitbucket.org/einsteintoolkit/tickets/issues/2746/make-seed_magneti… Sam has made some changes to push things forward * https://bitbucket.org/einsteintoolkit/tickets/issues/2745 Zach and Sam on fence on whether to push for GRHayL in this release or the next to replace IllinoisGRMHD * https://bitbucket.org/einsteintoolkit/tickets/issues/2756 Roland described issue being caused by E and P cores on Intel cpus and unexpected number of logical CPUs reported by the OS. Steve asked if there is an easy way to to identify them. Roland is not aware. Yosef asks if it is possible to limit to only one sort of cores. The ET currently tries to avoid HT but the issue here is really the uneven number of logical cpus compared to cores. Currenlty lscpu --extended can be used to identify the cores based on their maximum frequency, but it is not nice. * https://bitbucket.org/einsteintoolkit/tickets/issues/2752/parameter-file-pa… causes issues since we copy the string context verbatim to C, then LaTeX then HTML code. Had a discussion about allowing everything and escaping, or listing forbidden characters, or listing allowed characters. Discussion favored escaping for C, LaTeX and HTML output. * https://bitbucket.org/einsteintoolkit/tickets/issues/2749/wvuthorns-sprintf… Zach will fix this * https://bitbucket.org/einsteintoolkit/tickets/issues/2751/ehfinder-array-re… Peter will fix * https://bitbucket.org/einsteintoolkit/tickets/issues/2750/httpd-array-acces… Roland will fix * https://bitbucket.org/einsteintoolkit/tickets/issues/2739/change-admmacros-… Steve will review * https://bitbucket.org/einsteintoolkit/tickets/issues/2754/inconsistent-defi… Sam will add a parameter Email: * https://lists.einsteintoolkit.org/pipermail/users/2023-September/009059.html "Loss of precision after postintial?". Yosef suggested that init_3_tl could also cause changes in POSTPOSTINITIAL. Peter is not sure if anything more can be said without having seen the parameter file. Peter will try and contact Hayley. Chair next week: Steve Minutes next week: Sam Yours, Roland -- My email is as private as my paper mail. I therefore support encrypting and signing email messages. Get my PGP key from http://keys.gnupg.net.

1 0

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

06 Sep '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

Next NR community call: Monday, Sep 11
by Nils Vu 05 Sep '23

05 Sep '23

Dear Numerical Relativists, A new season of NR community calls begins next week! Our first community call of the season will be on Monday, September 11 (9am Pacific, noon NYC, 6pm Berlin). Our speakers will be Deborah Ferguson (UT Austin / UIUC) and Jaime Redondo Yuste (NBI). You can find the schedule in the wiki: https://github.com/sxs-collaboration/nr-community-call/wiki As always: - Feel free to circulate this information within the NR community. - Please subscribe to our mailing list <https://groups.google.com/u/1/a/black-holes.org/g/nr-community-call/> to receive info on the community calls in the future (or send a short message to nr-community-call+subscribe(a)black-holes.org <mailto:nr-community-call+subscribe@black-holes.org> to subscribe) and join our Slack <https://join.slack.com/t/generalrelativity/shared_invite/zt-dl4gqb6v-aAuw~p…> for discussions (channel: #nr-community-call <https://generalrelativity.slack.com/archives/C021LLTLK37>). - Please sign up for a slot <https://docs.google.com/forms/d/e/1FAIpQLSfoCnnCJve7J7Jzrpdlqw7nAbwWS_iuX_e…> in the schedule to speak at one of the community calls: https://github.com/sxs-collaboration/nr-community-call/wiki Best, Nils — Nils Vu, Ph.D. (he/him) Sherman Fairchild Postdoctoral Fellow in Theoretical Astrophysics California Institute of Technology

1 0

Agenda for Thursday's Meeting
by rhaas＠illinois.edu 04 Sep '23

04 Sep '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

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

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

Users