Users January 2021

users@lists.einsteintoolkit.org

21 participants
31 discussions

Announcing a new Python package for post-processing simulation data: kuibit
by Gabriele Bozzola 13 Jan '21

13 Jan '21

Hello, I developed a new package to analyze Einstein Toolkit simulations, kuibit [0,1]. kuibit is a Python3.6+ code that I built from scratch following the same design (and in various instances, implementation details too) of Wolfgang Kastaun's PostCactus. kuibit provides high-level data types to easily work with grid functions, time and frequency series, gravitational waves, and so on. It also has readers to effortlessly access simulation data with full support for HDF5 and ASCII output (1D, 2D, 3D grid data, scalar data, reductions, horizon data, ...). You can find a reasonably comprehensive list of features in the documentation [2] or a high-level summary in the frontpage of the docs [3]. One of the main reasons I wrote this code is for other people to use it. Our group (University of Arizona) is a young one and we don't have any sophisticated codes to analyze simulation data. Without suitable tools, post-processing simulations can be a daunting task for those that are new to the Einstein Toolkit. Given that I want other people to use kuibit, I made the effort to make the code user and developer-friendly. For users, there is documentation [4] with examples and small tutorials. Also, the package is on PyPI so it can be easily installed and updated. For developers, the entire codebase has unit tests and continuous integration [5], there are extensive comments, and the style of the code is rather verbose to help developers understand what is going on. The continuous integration also lints the code, performs static analysis, and generates the documentation, reducing the maintenance costs. kuibit takes care of all the low-level details needed to deal with simulation data, so it greatly lowers the entry barrier in using the Einstein Toolkit. I believe that this, along with the care I put in making the code accessible to other developers, makes kuibit a good candidate for inclusion in the Einstein Toolkit. The main problem with kuibit is that it is a new code: regardless of all the tests I wrote, there will be bugs, unergonomic interfaces, and performance issues. kuibit needs to be tested with several real-world projects and cross-checked with other codes. I am happy to give a short introduction to kuibit during a weekly call if there's interest. In the meantime, the code is available here: https://github.com/Sbozzolo/kuibit Best regards, Gabriele Bozzola [0] https://github.com/Sbozzolo/kuibit [1] https://github.com/Sbozzolo/kuibit#what-is-a-kuibit [2] https://sbozzolo.github.io/kuibit/features.html [3] https://sbozzolo.github.io/kuibit/#summary-of-features [4] https://sbozzolo.github.io/kuibit/ [5] https://github.com/Sbozzolo/kuibit/actions

1 0

Einstein Toolkit Meeting Reminder
by users＠einsteintoolkit.org 13 Jan '21

13 Jan '21

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

Announcing a new Python package for post-processing simulation data: kuibit
by Gabriele Bozzola 13 Jan '21

13 Jan '21

Hello, I developed a new package to analyze Einstein Toolkit simulations, kuibit. kuibit is a Python3.6+ code that I built from scratch following the same design (and in various instances, implementation details too) of Wolfgang Kastaun's PostCactus. kuibit provides high-level data types to easily work with grid functions, time and frequency series, gravitational waves, and so on. It also has readers to effortlessly access simulation data with full support for HDF5 and ASCII output (1D, 2D, 3D grid data, scalar data, reductions, horizon data, ...). You can find a reasonably comprehensive list of features in the documentation or a high-level summary in the frontpage of the docs. One of the main reasons I wrote this code is for other people to use it. Our group (University of Arizona) is a young one and we don't have any sophisticated toolchain to analyze simulation data. Without suitable tools, post-processing simulations can be a daunting task for those that are new to the Einstein Toolkit. Given that I want other people to use kuibit, I made the effort to make the code user and developer-friendly. For users, there is documentation, examples and small tutorials. Also, the package is on PyPI so it can be easily installed and updated. For developers, the entire codebase has unit tests and continuous integration, there are extensive comments, and the style of the code is rather verbose to help developers understand what is going on. The continuous integration also lints the code, performs static analysis, and generates the documentation, reducing the maintenance costs. kuibit takes care of all the low-level details needed to deal with simulation data, so it greatly lowers the entry barrier in using the Einstein Toolkit. I believe that this, along with the care I put in making the code accessible to other developers, makes kuibit a good candidate for inclusion in the Einstein Toolkit. The main problem with kuibit is that it is a new code: regardless of all the tests I wrote, there will be bugs, unergonomic interfaces, and performance issues. kuibit needs to be tested with several real-world projects and cross-checked with other codes. I am happy to give a short introduction to kuibit during a weekly call if there's interest. In the meantime, the code is available on GitHub (Sbozzolo/kuibit), documentation is available at sbozzolo(dot)github(dot)io/kuibit. Best regards, Gabriele Bozzola

1 0

Out-Dated Code Version Error
by Karima Shahzad 13 Jan '21

13 Jan '21

Hello, There is a spinning single BH evolution example inside (*Cactus Cactus/par/arXiv-1111.3344/kerr/by-a0.7.par) *which is using the code version 2010. I am trying to simulate it using the newest version of the ETK with the only changes of refinement levels (reduced to 3) in the parameter file. It is giving some warnings and suggestions to change the out-dated parameters ( *LapseAdvectionCoeff, ShiftAdvectionCoeff*) along with the boundary condition to set as usual (what it means?). I also tried using the suggested parameters, but the data output is not as expected (incomplete output data), probably because of these out-dated parameters (?), the output and the error files are attached. I am asking if there are any alternatives (solutions) to these parameters, or should I prefer using the old ETK version, 2010? In the latter case, I am again encountering the download error, pasted below. Likewise, I want to get around this issue as well. I assume this email contains multi issues, but they are co-related, sorry to put them in one post. ./GetComponents --parallel https://bitbucket.org/einsteintoolkit/manifest/raw/*ET_2010_06*/ einsteintoolkit.th *Note:* I have tried without using the* "--parallel option" *as well, but the same error persists. Error: No definition for ET_RELEASE found in input file or ENV. ---------------------------------------------------------------------------CalledProcessError Traceback (most recent call last)<ipython-input-26-9fa64924ebf0> in <module>----> 1 get_ipython().run_cell_magic('bash', '', './GetComponents https://bitbucket.org/einsteintoolkit/manifest/raw/ET_2010_06/einsteintoolk…' <https://bitbucket.org/einsteintoolkit/manifest/raw/ET_2010_06/einsteintoolk…'>) ~/.local/lib/python3.8/site-packages/IPython/core/interactiveshell.py in run_cell_magic(self, magic_name, line, cell) 2369 with self.builtin_trap: 2370 args = (magic_arg_s, cell)-> 2371 result = fn(*args, **kwargs) 2372 return result 2373 ~/.local/lib/python3.8/site-packages/IPython/core/magics/script.py in named_script_magic(line, cell) 140 else: 141 line = script--> 142 return self.shebang(line, cell) 143 144 # write a basic docstring: <decorator-gen-110> in shebang(self, line, cell) ~/.local/lib/python3.8/site-packages/IPython/core/magic.py in <lambda>(f, *a, **k) 185 # but it's overkill for just that one bit of state. 186 def magic_deco(arg):--> 187 call = lambda f, *a, **k: f(*a, **k) 188 189 if callable(arg): ~/.local/lib/python3.8/site-packages/IPython/core/magics/script.py in shebang(self, line, cell) 243 sys.stderr.flush() 244 if args.raise_error and p.returncode!=0:--> 245 raise CalledProcessError(p.returncode, cell, output=out, stderr=err) 246 247 def _run_script(self, p, cell, to_close): CalledProcessError: Command 'b'./GetComponents https://bitbucket.org/einsteintoolkit/manifest/raw/ET_2010_06/einsteintoolk…'' <https://bitbucket.org/einsteintoolkit/manifest/raw/ET_2010_06/einsteintoolk…''> returned non-zero exit status 25. Any kind of assistance would highly be appreciated and worthwhile. Thank you Best, Karima S

1 0

ETK_2010 Download Error
by Karima Shahzad 11 Jan '21

11 Jan '21

Hi, I am installing the ETK, 'Bohr' version (2010) but it gives error for the download command > "./GetComponents > https://bitbucket.org/einsteintoolkit/manifest/raw/ET_2010_06/einsteintoolk…". Error: Error: No definition for ET_RELEASE found in input file or ENV. --------------------------------------------------------------------------- CalledProcessError Traceback (most recent call last) <ipython-input-26-9fa64924ebf0> in<module> ----> 1get_ipython().run_cell_magic('bash', '', './GetComponents https://bitbucket.org/einsteintoolkit/manifest/raw/ET_2010_06/einsteintoolk…' <https://bitbucket.org/einsteintoolkit/manifest/raw/ET_2010_06/einsteintoolk…'>) ~/.local/lib/python3.8/site-packages/IPython/core/interactiveshell.py inrun_cell_magic(self, magic_name, line, cell) 2369 with self.builtin_trap: 2370 args= (magic_arg_s, cell) -> 2371result= fn(*args, **kwargs) 2372 return result 2373 ~/.local/lib/python3.8/site-packages/IPython/core/magics/script.py innamed_script_magic(line, cell) 140 else: 141 line= script --> 142return self.shebang(line, cell) 143 144 # write a basic docstring: <decorator-gen-110> inshebang(self, line, cell) ~/.local/lib/python3.8/site-packages/IPython/core/magic.py in<lambda>(f, *a, **k) 185 # but it's overkill for just that one bit of state. 186 def magic_deco(arg): --> 187call= lambda f, *a, **k: f(*a, **k) 188 189 if callable(arg): ~/.local/lib/python3.8/site-packages/IPython/core/magics/script.py inshebang(self, line, cell) 243 sys.stderr.flush() 244 if args.raise_errorand p.returncode!=0: --> 245raise CalledProcessError(p.returncode, cell, output=out, stderr=err) 246 247 def _run_script(self, p, cell, to_close): *CalledProcessError**: Command 'b'./GetComponents **https://bitbucket.org/einsteintoolkit/manifest/raw/ET_2010_06/einsteintoolkit.th\n'' <https://bitbucket.org/einsteintoolkit/manifest/raw/ET_2010_06/einsteintoolk…''>**returned non-zero exit status 25. NOTE: *I have tried without "--parallel" option, but the same error persists. Any help would be worthwhile. Thank you Regards, Karima S **

1 0

Agenda for Thursday's Meeting
by users＠einsteintoolkit.org 11 Jan '21

11 Jan '21

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

1 0

Meeting Minutes 2021-01-07
by Gabella, William E 07 Jan '21

07 Jan '21

Present: Maria BH, Bill G, Roland H, Ken S, Yosef Z, David B, Atul K, Peter D, Zach E, Steve B, Frank L Chair Maria, Minutes Bill * SPEC benchmark contribution [https://bitbucket.org/einsteintoolkit/tickets/issues/2470 task] [RH, SB] RH, SPEC group replied and happy to have our contribution. Same person assigned to us that worked with Erik last time. They want a different code than last time. RH, could use the newest version of Maclachlan does derivs in steps, does not do them in one go, or different formulation of BSSN (CZZ4, Z4C), or not use it at all, but use Baikal code. Which is fine they want un-optimized code to test the compilers optimization. SPEC runs the inner kernel, not a full run. PD, Maclachlan is mostly Erik. Whatever is easiest? ZE, Baikal, we could do something. Maybe more future directed sense; Baikal is based on NRPy and designed to output Einstein Eqns on any coord system. When Black Holes at Home is off the ground, had in mind submitting to SPEC, solving Einstein eqns in curvilinear coordinates. SPEC is only performed on desktops and laptop computers. RH, deadline for fully done is February (25 Feb 2021 PST time) and needs to be a production code. Would like it to the ET "sticker" on it. Alternate forms of BSSN Z4 with constrained damping in various ways and two flavors to do that, one maybe Daniella Alic at AEI (https://arxiv.org/abs/1106.2254 ) and other David Hildich (https://doi.org/10.1103/PhysRevD.81.084003 and https://arxiv.org/abs/1107.5539 ). CZZ4 is in Maclachlan and is the more formal; Z4C is there but is a branch on the ET. They are very similar to each other. Could use that and version of Kranc that generates the derivatives in two steps. Non-vectorized Machlachlan code, which may or may not be there. PD, is using the non-vectorized version of Machlachlan and it is working. Must strip away ancillary code and look at the "kernel," the one or two routines to do the updates. There is a mini-driver that exists. Roland will make a list and some notes and will discuss/decide next week. * search for ET release team [RH] RH, next release is end of May. Need one or two persons that will be release chair. Last few times it was Steve or Roland. Do have a list of the tasks involved...not a lot of work but not negligible. Zach E volunteers as the release chair and Bill G will be a "junior lieutenant." Keep looking at and refining the "check-list," See Release Details: https://docs.einsteintoolkit.org/et-docs/Release_Details and Release Process: https://docs.einsteintoolkit.org/et-docs/Release_Process * simfactory usage survey, [https://docs.google.com/forms/d/e/1FAIpQLSf3RzB_o8Y8fIdwZOPoWJyKp9jvV2tIvom… draft] [RH] RH, promoting Simfactory as the major tool to use. But we get a lot of questions on the mailing list. Also it is complicated. And the original maintainers are gone. To simplify doing something with it, we want to know how are people using it and which parts are used? Maybe gives an idea of which parts can be cut. RH and SB in the process of porting to Python 3. This group should comment on the survey form. Is a bit long and does not cover all topics. * BBH gallery inclusion of LIGO data [RH], see [http://lists.einsteintoolkit.org/pipermail/users/2020-September/007590.html Minutes for 2020-09-03], the proposed [https://docs.einsteintoolkit.org/et-docs/images/d/d8/ET_2020_05_strain-NR-H… figure] Peter Schaffarcyzk has a new figure for the GW150914 gallery example. When Peter did the 2019 testing he overplotted the LIGO data on the ET calculated strain. We agreed to do this but questions about details of plot. Ask Peter S: is the Hanford the best data? Is it whitened, if so it should say so? Power B 2020 needs to be run longer, green tail around t=0.44. X-axis just label "time" (though it is in units of seconds and not mass?)? MBH, Roland will contact Peter and ask about getting the scripts. * Summer Student projects (ad hoc discussion) Maria and Zach, good to have projects for students to take on. ZE, Undergraduates ask about summer projects and Google Summer of Code. Frank L, You need a sponsor, and continued acceptance can be fickle. Have to take students and make sure the work is done on time. SB, needs to be a list of undergraduate projects; should post a list. RH, There is a list on the Wiki, but not all are suitable for a summer student. More computer science-y than physics-y, easier or more concrete tasks. ET Wiki list at https://docs.einsteintoolkit.org/et-docs/Summer_student_projects . * call for projects to be included in the next release [RH] ** Simfactory Python3 support [SB, RH] SB, have a port that is mostly working. Does the things he wants to do. There are features in the survey that Steve has never used...some features were never working. One snarly issue with Python3, has a tendency to require your language environment setup correctly or will die in funny ways. Less robust/user friendly than Python2, it seems. ** POWER [https://bitbucket.org/einsteintoolkit/tickets/issues/2413/include-power-cod… #2413] [RH, MH] RH, no update but can be cleaned up and have in a state ready for review by end of the month. SB, is it alternative to Mathematica script? RH, that is part of it. Does a couple of methods for evolving Psi4 to Scri-I+. Toward having more things as pure Python and not Mathematica. Helps on clusters. Has been converted to Python3 and works. SB, might want something for the trajectory and then the gallery example plots can be done without Mathematica. YZ, what requires Mathematica? RH, The gallery example has example Mathematica notebooks, but likely all could be moved to non-Mathematica. ** con2prim updates for GRHydro [https://arxiv.org/abs/1712.07538 paper] [https://bitbucket.org/einsteintoolkit/tickets/issues/2414/include-con2prim-… #2414] [RH] RH, topic seems a misnomer. Update method in GRHydro, Dan Siegel and students at Columbia have done this. It turns out that Arizona is working on this, but working with Illinois GRMHD and not sure how close that is to the one in ET. If they are willing to contribute their code would like to have it. Need to hear from the authors if they want and will contribute it to ET. Roland will invite one of them to the meeting to give us a status report. ** updates to Selfforce1D [PD] PD, no update. ** Canuda updates and new features [https://bitbucket.org/einsteintoolkit/tickets/issues/2485/include-complex-a… #2485] [MZ, HW] RH, Miguel Zilhao and Helvi Witek, they have extra functionality for complex and scalar fields, seems ready and used for publication. Helvi is busy with a proposal until the end of January. There is a code there and we need / would like that someone wants to use it for their research. Seems the closest to ready for the next ET release. [https://www.einsteintoolkit.org/tools/unanswered.php unanswered question on mailing list] None. Script tagged the Dec 17th minutes, not an unanswered post. [https://bitbucket.org/einsteintoolkit/tickets/issues?status=open&status=new… open tickets sorted by update time] #2486, the gallery example uses Z-symmetry but allows the 3 components of the spin when only the z-component can be specified. Would like someone other than Roland to look at it and fix it. Need a volunteer! Ticket #2486, https://bitbucket.org/einsteintoolkit/tickets/issues/2486/ [https://bitbucket.org/einsteintoolkit/tickets/issues?status=new&status=open… tickets ready for review] * AOB * New chair and minute taker: Jan 14-chair Peter D, minutes Maria BH Jan 21- * Maria BH, was trying to run at WVU and was given a warning..."no open file bricks connection scheme reported" (?) and the simulation ran fine. ZE, low level network file structure that MPI is interfacing with. Not a problem, an error. * Zach E, update on LaTeX Parser, almost finished BSSN and starting to transition from Parser to working on GPU kernel generation with NRPy. Ken is writing example CUDA codes and then will code NRPy to do that. Everything parsed (BSSN) within a week or two. -- ============================== William Gabella Research Assistant Professor Department of Physics and Astronomy Nashville, TN USA (o) 615-343-2713

1 0

Einstein Toolkit Meeting Reminder
by users＠einsteintoolkit.org 06 Jan '21

06 Jan '21

1 0

failure of CCTK_WARN on Frontera cluster
by Bruno Giacomazzo 06 Jan '21

06 Jan '21

We are having some issues running the Einstein Toolkit with ourSpritz code on the Frontera cluster at TACC and I'm wondering if any of you ever saw the error you can find in the stderr attached to this email. The error is *corrupted size vs. prev_size: 0x00002b3728001060 **** and it looks like the code crashes within a call to CCTK_WARN. We used both the May and November 2020 versions of the Einstein Toolkit and they both produce the same error. We are currently a bit lost, also because the same code and par file run fine on another cluster (MarconiA3 at CINECA in Italy). We actually also tried a different parfile (that calls anyway the same routine) and the same problem happens on Frontera (but not on MarconiA3). It may well be a bug within Spritz when calling the CCTK_WARN function (that for some reason does not show up on other machines) or a compilation problem on Frontera. Have you seen a similar error? Do you have some suggestions on how to debug it? Thanks, Bruno -- Prof. Bruno Giacomazzo Department of Physics University of Milano-Bicocca Piazza della Scienza 3 20126 Milano Italy email: bruno.giacomazzo(a)unimib.it phone: (+39) 02 6448 2321 web: http://www.brunogiacomazzo.org ---------------------------------------------------------------------- There are only 10 types of people in the world: Those who understand binary, and those who don't ----------------------------------------------------------------------

2 1

Agenda for Thursday's Meeting
by users＠einsteintoolkit.org 04 Jan '21

04 Jan '21

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 January 2021