Users

users@lists.einsteintoolkit.org

3 participants
3984 discussions

New release of kuibit (now with support for OpenPMD files)
by Gabriele Bozzola 19 Jun '24

19 Jun '24

Dear Einstein Toolkit community, kuibit 1.5.0 was just released. kuibit 1.5.0 comes with one big feature and one important fix. The fix is for the (unmaintained) tikzplotlib package, which stopped working with recent versions of matplotlib. This led to problems with using the `visualize` module in kuibit. Second, more excitingly, kuibit now comes with experimental support for reading OpenPMD grid files, such as the ones produced by CarpetX. This is the result of the impressive year-long effort by high-school student Krishiv Bhatia, supervised by Erik Schnetter and Lucas Carneiro. kuibit abstractions work in the same way regardless of the file format (ASCII, HDF5, or OpenPMD). For example, the following piece of code plots a equatorial slice of a 3D field: ``` import kubit sd = SimDir("PATH_TO_SIM_OUTPUT") iteration_num = 0 kuibit.visualize_matplotlib.plot_color(sd.gf.xyz["my_var"][iteration_num].sliced(cut=[None, None, 0]), shape = [100, 100]) ``` Support for reading OpenPMD files should be considered experimental at this point. Please, report any issue you might find. https://github.com/Sbozzolo/kuibit Best, Gabriele

1 0

New Testing Framework for Individual Einstein Toolkit Thorns
by Zach Etienne 18 Jun '24

18 Jun '24

Einstein Toolkit community: I have completed a new, automated, and fast framework for testing individual or small groups of thorns within the Einstein Toolkit. Although it is developed with GitHub Actions in mind, it can be run locally. As I believe this may be useful for the community, I am sharing all the details in this email. While the framework is developed for thorns generated with NRPy2, it can be simplified fairly straightforwardly for thorns developed by hand. Here's how it works: With each push to the NRPy2 `main` branch, the following happens (as documented here: https://github.com/nrpy/nrpy/blob/main/.github/workflows/main.yml#L136): GitHub Actions first downloads an Apptainer (formerly Singularity) SIF image I have prepared here: https://github.com/nrpy/einsteintoolkit_ci_images/releases. The above image contains a recent (24.04) Ubuntu distribution with two pieces of software installed in /opt: 1. A *compiled* version of a recent (pre-2024-06 release) version of the Einstein Toolkit, with Baikal*, IllinoisGRMHD, WaveToyNRPy, and all other required thorns. 2. A recent NRPy2. After downloading the above image, Actions runs a script that pulls the latest NRPy2 main branch, generates Baikal* and WaveToyNRPy thorns, overwrites these thorns in the Einstein Toolkit, and then compiles them within the Toolkit. Since other thorns are not compiled, this is a very quick check to ensure that updates to NRPy2-generated thorns do not break the compilation. Finally, the Einstein Toolkit testsuite is run on each of these thorns. If any of the above steps ({download, thorn generation, compilation, testsuite}) fail, then GitHub Actions fails and it automatically sends me an unpleasant email. We plan to extend the framework to CarpetX (Baikal*X and WaveToyNRPyX thorns) in the coming months, probably with a separate Apptainer image. Please feel free to use the Apptainer image available at https://github.com/nrpy/einsteintoolkit_ci_images/releases, or the script available at https://github.com/nrpy/nrpy/blob/main/.github/workflows/main.yml#L136 if you may find it useful. Everything here is open source. This complements the very nice existing Einstein Toolkit testing framework ( https://einsteintoolkit.github.io/tests/), which builds the entire Toolkit automatically after any ET thorn or the flesh is updated. The full build requires about 90 minutes, whereas my testing framework is more limited in scope and completes in under 10 minutes (as it focuses only on a small collection of thorns). -Zach * * * Zachariah Etienne Assoc. Prof. of Physics, U. of Idaho Adjunct Assoc. Prof. of Physics & Astronomy, West Virginia U. https://etienneresearch.com https://blackholesathome.net

1 0

Re: [Users] Using FUKA ID's in ETK
by Jason Alarcon 18 Jun '24

18 Jun '24

Hello, I fixed the issue. I for some reason placed the ID as the parfile. However, starting the simulation segment ends short when the thorn Kadath_Importer cannot be found. The parfile I am using includes it as an active thorn and the thornlists seemed to have included in both KadathImporter and KadathThorn. KadathThorn also fails to be found when included in the parfile. I have included both the output and parfile below for a BBH setup: Best regards, Jason Alarcon

3 4

Agenda for Thursday's Meeting
by rhaas＠illinois.edu 17 Jun '24

17 Jun '24

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

1 0

Using FUKA ID's in ETK
by Jason Alarcon 17 Jun '24

17 Jun '24

Hello, I am new to using the Kadath FUKA solver as a thorn for the Einstein Toolkit and I decided to use the BBH.info <http://bbh.info/> ID located in the KadathImporter/par path and its respected .par file, however when I run my usual create and submit command with simfactory, there is some parsing error: - /home/eilyn/simulations/BBH/SIMFACTORY/exe/cactus_sim -L 3 /home/eilyn/simulations/BBH/output-0000/BBH.info <http://bbh.info/> WARNING level 0 from host Girls-DESKTOP33. process 0 in thorn cactus, file BBH.info:2 <http://bbh.info:2/>: -> ERROR IN PARAMETER FILE:Parse Error Expected one of the following characters: ':'initial { ^ I have tried fixing the formatting but nothing has worked thus far. Here is the ID file: How can this file be put into Cactus format? Best regards, Jason Alarcon

2 1

Meeting minutes for 2024-06-13
by Cupp, Samuel D. 13 Jun '24

13 Jun '24

Present: Sam, Keith, Steve, Lucas, Zach, Leo, Roland # ET Workshop recap * Other than Steve getting very sick, meeting went well * in process of gathering slides, videos to provide links * should add a page on the wiki for "things to keep in mind while planning a workshop" * Try to collect pictures from meeting to share # ET Release * working to get testing, gallery examples completed * goal: have release out by the end of June * BNS gallery example needs some additional instructions to better clarify the required steps to run * Z4c is delayed to next release, so it was removed from manifest thornlist # Tickets * Ticket 2803: this PR is already merged; the commit will be closed * Ticket 2802: needs similar fix as in ticket 2801 * Ticket 2801: PR resolves compilation failures; should be reviewed and merged Next week Chair: Lucas Minute taker: Roland Samuel Cupp Postdoctoral Researcher Department of Physics University of Idaho

1 0

Einstein Toolkit Meeting Reminder
by rhaas＠illinois.edu 12 Jun '24

12 Jun '24

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

Error on the linking phase on compilation in a virtual environment
by José Ferreira 12 Jun '24

12 Jun '24

Dear toolkit users and developers, With the latest update of GCC to version 14, there is a known error that prevents the compilation from taking place, preventing me from compiling the toolkit. I’ve been trying to do something which I probably should have some time ago to avoid this kind of issues, while also granting some portability between machines, which is to setup a virtual environment using Conda to compile the toolkit. I am sending you this e-mail because I’ve failed to compile the toolkit in a virtual environment, where I am currently stuck with an error during the linking phase. Before the update to GCC 14, and without the virtual environment, I was able of compiling the toolkit without any issue. Here are the steps that I have performed: 1. Activate an empty virtual environment managed by a conda (or a drop-in replacement) with the conda-forge repository configured 2. |conda install gcc gxx gfortran openmpi openmpi-mpicc openmpi-mpicxx openmpi-mpifort binutils| 3. Compile the toolkit with an empty thornlist, attached in |empty.th|, and an option file that points towards the virtual environment that is activated, attached in |venv.cfg| 4. Get the following error from |ld| (the full log for making the config and the binary are attached in |cactus_empty.log|) |Creating cactus_empty in /home/undercover/projects/cactus/exe from /home/undercover/.micromamba/envs/phd/bin/x86_64-conda-linux-gnu-ld: unrecognised emulation mode: arch=native Supported emulations: elf_x86_64 elf32_x86_64 elf_i386 elf_iamcu make[1]: *** [/home/undercover/projects/cactus/lib/make/make.configuration:150: /home/undercover/projects/cactus/exe/cactus_empty] Error 1 make: *** [Makefile:265: empty] Error 2 | To me, the previous error indicates that something is passing the wrong flags to |ld|, because even if the emulation mode was not recognized it should give the error |ld: unrecognised emulation mode: <something>| instead of |ld: unrecognised emulation mode: arch=<something>|. Removing the flag |-march=native| from the compilers confirms my guess by revealing a different error at the same stage |Creating cactus_empty in /home/undercover/projects/cactus/exe from /home/undercover/.micromamba/envs/phd/bin/x86_64-conda-linux-gnu-ld: unrecognized option '-DMPICH_IGNORE_CXX_SEEK' /home/undercover/.micromamba/envs/phd/bin/x86_64-conda-linux-gnu-ld: use the --help option for usage information make[1]: *** [/home/undercover/projects/cactus/lib/make/make.configuration:150: /home/undercover/projects/cactus/exe/cactus_empty] Error 1 make: *** [Makefile:265: empty] Error 2 | and if I were to remove the corresponding flag in the config file, |ld| will complain about something else. It really seems like something is passing the flags onto |ld| where it shouldn’t, but I cannot tell who and where. I should note that compiling very basic programs in C in the virtual environment doesn’t raise any issues, although I haven’t tested it very thoroughly. Please do let me know if you have any issues in rendering this e-mail! Best regards, José Ferreira

2 4

Agenda for Thursday's Meeting
by rhaas＠illinois.edu 10 Jun '24

10 Jun '24

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

1 0

Compiling Einstein Toolkit
by Edmond, Lawrence 04 Jun '24

04 Jun '24

Hello, I am Lawrence Edmond, IV, a rising third-year PhD student at Brown University in the physics department. I am interested in using EinsteinToolkit to simulate black holes with accretion disks for cosmo/dark matter research. I am following along with the Wiki <https://einsteintoolkit.org/download.html> and the JupyterNotebook <https://github.com/einsteintoolkit/jupyter-et/blob/master/tutorial-server/n…> on git to compile and run the first "HelloWorld" Thorn before attempting to write my own. Following along with the notebook. I am able to compile EinsteinToolkit via the following bash command: ./simfactory/bin/sim build -j4 --thornlist ../einsteintoolkit.th which differs from the notebook by the location of the "einsteintoolkit.th" thorn. This is able to compile without errors however, when I try to run the following command to create and execute the "HelloWorld" thorn, ./simfactory/bin/sim create-run helloworld \ --parfile arrangements/CactusExamples/HelloWorld/par/HelloWorld.par I get an error message saying that the executable cannot be found or was not created (see below for a copy of the output). [ledmond@login010 Cactus]$ ./simfactory/bin/sim create-run helloworld \ --parfile arrangements/CactusExamples/HelloWorld/par/HelloWorld.par Warning: Current Working directory does not match Cactus sourcetree, changing to /users/ledmond/EinsteinToolkit/Cactus Parameter file: /oscar/home/ledmond/EinsteinToolkit/Cactus/arrangements/CactusExamples/HelloWorld/par/HelloWorld.par Error: Executable /users/ledmond/EinsteinToolkit/Cactus/exe/cactus_sim for configuration sim does not exist or is not readable Aborting Simfactory. I believe the issue is that the procedure is looking for the executable file, and the associated folder to hold all created executables is being created using a path that cannot be accessed on my cluster. That being said, is there a way to manually change the path for the exe/ directory that is created by Simfactory? Thank you in advance for any help you may offer. Please do not hesitate to contact me if you need any more information or further clarification to address this compilation issue. -- *Best Regards, * *Lawrence Edmond, IV* *Class of 2026*

2 1

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

Users