Users

users@lists.einsteintoolkit.org

3 participants
3984 discussions

parsing bug for temperature_evolution_method
by Hee Il Kim 11 Mar '21

11 Mar '21

Dear all, I have encountered a bug in using HydroBase::temperature_evolution_method. If it is given explicitly by taking its default value "GRHydro", my runs crashed while reading a Lorene data. But if it's not given in the parameter file, it run smoothly but the results are the same with the case of taking "none". I found this bug when I was testing Hybrid EOS. I've tried to realize pure Polytrope (or Ideal_Fluid) by using the piecewise Hybrid EOS interface. But the results are showing around 10% more variations in rhomax compared to the pure Polytrope/Ideal_Fluid cases. I'm using Turing version. Thanks for you help in advance. Hee Il

2 5

Meeting Minutes 2020-03-11
by Miguel Gracia 11 Mar '21

11 Mar '21

Present: Erik S, Atul K., Lorenzo E., Peter D., Bruno G., Kenneth S., Miguel G., Leonardo M., David B., Roland H., Federico L., Steven B., Zach E. Chair: Steven B, Minutes: Miguel G. • Updating LORENE version in ET ticket<https://bitbucket.org/einsteintoolkit/tickets/issues/2206/make-lorene2-the-…> email<http://lists.einsteintoolkit.org/pipermail/users/2021-March/007836.html> [Bruno Giacomazzo] [Bruno G]. LORENE Thorn is not updated with the 2018 version of LORENE. ET compilation fails when trying to compile it with the 2018 LORENE version, this is because the ET patches cannot be applied because LORENE source code is different. [Bruno G]. LORENE 2018 version fixes bugs related with tabulated EOSs. [Bruno G]. Asked if there’s some step by step tutorial about how to create LORENE thorns. [Eric S] Frank L. created LORENE2 tarball. [Steven B.] is going to ask Frank L. to provide some sort of documentation. [Roland H.] Recommended Bruno to use LORENE2 and report back if he is able to make it work with the 2018 LORENE version. if not it needs to be patched like any other external libraries. (see ticket<https://bitbucket.org/einsteintoolkit/tickets/issues/2206/make-lorene2-the-…>) • SPEC benchmark contribution task [RH, SB]. https://bitbucket.org/einsteintoolkit/tickets/issues/2470 [RH] waiting for response. * Unanswered questions / Open tickets / tickets ready to review -Termination trigger feature request. RH thinks it would be useful feature, thinks it is easy to add. Steven B. is going answer the email and ask the author to make a pull request. -no comments about tickets open/ready to review. * ET Release update: [Zach E.] We have one new feature POWER, not yet in Master, waiting for the reviewer…by mid May,code reviews must be finished. * Other comments/discussion: Simfactory3 passed the Test,<https://build-test.barrywardell.net/job/SimulationFactory/> user Albert pw Einstein [Atul K.] Clarified the mailing list question by Hee Il (parsing bug for temperature_evolution_method) answered by Roland (email<http://lists.einsteintoolkit.org/pipermail/users/2021-March/007842.html>). [Roland H.] Try to use only equation of states that doesn’t use temperature like tabulated ones . -Reminder On March 18 (usual ET call time), We have a CarpetX tutorial by Eric S. Will be focused on writing thorns and how to translate existing thorns from Carpet to CarpetX. Everything from a simple user perspective. Future chair and minute takers: March 25 Chair: Roland H. Minute taker: Steven B. end of the meeting. ——

1 0

Einstein Toolkit Meeting Reminder
by users＠einsteintoolkit.org 10 Mar '21

10 Mar '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

Can I simulate this exotic static topological spacetime with the ET?
by Adam Herbst 08 Mar '21

08 Mar '21

Hi all, Before tackling the learning curve, I want to see if there's any chance I can do what I'm hoping to, because it seems unlikely, but with something as highly developed as the ET appears to be, you never know! I want to find a stationary spacetime, in which each time-slice has a topological defect anchored at the origin. Specifically, we take an "extruded sphere" (S^2 x [0,1]), set the metric such that the radii of the end-spheres goes to zero, and attach each end to one "half-space" of the origin (theta in [0, pi/2] and theta in [pi/2, pi]). This can be done "smoothly" by having g_{theta,theta} from outside approach sin^2(2 * theta) instead of sin^2(theta), so that a radial cross-section becomes a pair of spheres, one for each half-space, instead of a single sphere. Thus the defect is actually a "bridge" between these two half-spaces, and geodesics through the origin traverse this loop. But the curvature does become infinite at the origin. Now the thing is, what I really want to do is start with the ansatz described above (I already have a formula for the metric), and make it converge to a solution of the Einstein-Hilbert action, while keeping it stationary. But in this case it is NOT the same as the vacuum field equation, because the "boundary condition" of the topological singularity will not allow the Ricci curvature to disappear, even when we minimize total curvature. Or so I believe. So that's why it has to be a purely action-based approach, if that even makes sense. So I hope this was coherent. And if it is possible, can you let me know which modules I should start getting familiar with in order to give it a shot? Thank you for reading! Cheers, Adam

3 7

Agenda for Thursday's Meeting
by users＠einsteintoolkit.org 08 Mar '21

08 Mar '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

Boundary conditions in diagnostics with compute_every
by Gabriele Bozzola 08 Mar '21

08 Mar '21

Hello, suppose (for clarity) that I want to write a thorn that computes the constraint violations as grid functions. Since this is a diagnostic, I don't need to compute it at every iteration, so I will add a parameter "compute every" and I will schedule the computations in CCTK_ANALYSIS. Then, I will be careful and make sure that compute_every is a multiple of when all the refinement levels are synced up. How are boundary conditions handled in this case? I can call Boundary_SelectGroupForBC every "compute_every" and schedule the corresponding functions in the scheduler. But, do I need to (1) allocate multiple timelevels for my grid functions, (2) do anything about filling previous timelevels? I am looking at WeylScal4 as an example. The thorn has parameters "compute_every", the grid functions have 3 time levels, and Boundary_SelectGroupForBC is called every "compute_every", but nothing is done to fill the previous timelevels. How does this work? Assuming that the boundary conditions are 'flat', is there any way to just work with one timelevel? Thanks, Gabriele

2 8

glitch in et registration server
by Roland Haas 07 Mar '21

07 Mar '21

Hello all, due to a configuration glitch in the server that handles Einstein Toolkit registration requests for the toolkit itselfs and for tutorial accounts, no such requests were processed in the period of Feb 10th 2021 and March 4th 2021. If you tried to register in that time, please try and more and you should be more successful this time. 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://pgp.mit.edu .

1 0

Meeting Minutes 2021-03-04
by Gabella, William E 04 Mar '21

04 Mar '21

Present: Peter D, Bill G, Roland H, Atul K, Miguel G, Steve B, Karim S Chair: Peter, Minutes: Bill * SPEC benchmark contribution [https://bitbucket.org/einsteintoolkit/tickets/issues/2470 task] [RH, SB] Roland, Sent the Makefile to the person at NVidia and a second version that is not sent yet, it is a little nicer. PUGH run with 8th order finite difference and seems to run really slow. Not sure about how long the run the SPEC want. Decided as a test case not to use Minkowski ST too man zeros, so put in a shifted gauge wave. Started with Maclachlan with gamma driver and 1+log lapse (black hole driver) and periodic BCs and seems unstable, the amplitude of the wave grows. Benchmark parameter file chooses the number of cells and the time steps, did satisfy the Courant condition, it is smaller than 0.4 (that is the gallery example), even smaller shows the same growth. "Apples to apples paper(s)" of code comparisons uses harmonic gauge for the shifted gauge wave . There is a harmonic gauge in Maclachlan but not sure it is used, much. Instability seems to be "stable," evolves to the same values. Tarball is attached to the ticket (above). It just uses a Makefile, very minimal. *AOB ** Release discussion---no Zach. We want to put codes in the master branch for folks to try out. Agreed that Python3 simfactory should go in master branch (more discussion below). https://docs.einsteintoolkit.org/et-docs/Release_Details ** Atul, about EOS Omni for different equations of statem there are four or more ways to give the EOS, but one is not documented...called barotropic EOS and is tabulated EOS. Roland, maybe the Commit message for that code would help. Atul, will post to the email list. [https://www.einsteintoolkit.org/tools/unanswered.php unanswered question on mailing list] ** Herbst exotic space time post. Erik responded and Peter will also. [https://bitbucket.org/einsteintoolkit/tickets/issues?status=open&status=new… open tickets sorted by update time] ** Roland, Ticket #2030 about blocks being uninitialized when multi-block boundary and interior symmetry is used. Pull request that should make it work with Z symmetry (reflection) with Lama. Maybe try higher order with fewer interpolation points. In Roland's test case failure is at outer boundary and occurs at 60M, so can turn off the refinement levels and fails quicker, in 30 minutes or so. https://bitbucket.org/einsteintoolkit/tickets/issues/2030/multi-block-bound… ** Roland, Steve implement test cases for Simfactory Python3. Steve, wrote testsim.py and tests various capabilities, it is a start. Both Python 2 and 3 pass. And learned the ListConf() function would never have worked---was supposed to list the configurations, like "ls configs." It is fixed now. Many of the Simfactory options are unclear what they do. Long discussion about how and where to save machine names, especially with-respect-to the clusters where compute nodes have very different names than the login node. Roland would like to move the Python3 test branch into master branch so we can test it. If both 2 and 3 are found, Simfactory uses version 3. The new stuff is in the Py3compat branch. There was agreement to that plan. Long discussion of what had been described as the "Locale" problem, the reading of UTF-8 files versus ASCII/Latin-1 with Python. Newer Python 3.9 seems not to have this problem. But older OSes and older Python's do. Roland recommends that all Simfactory files should be UTF-8 only. One file has a machine name with Chinese character and another computing center with French e with an accent. Simfactory when it opens a file must read it as UTF-8. If Latin-1 it will read it, but interpret it incorrectly. If you read as ASCII (by locale or otherwise), it will fail to read the file, there is a byte marker at the top of the file. One can change the default behavior in your Locale file, and that is where the problem was first noticed. [Some references: ASCII vs ISO 8859 (Latin-1) vs UTF-8 see https://kb.iu.edu/d/ahfr . Short version, US-ASCII is the 128 character set with usual ASCII. The ISO 8859 defines using the other 128 characters in the 2 bytes, so Latin-1 is good for Western European languages, i.e. characters with diacritical marks. UTF-8 is the 8-bit Unicode and UTF is for Unicode Transformation Format, https://en.wikipedia.org/wiki/UTF-8 . See also tables in https://cs.stanford.edu/people/miles/iso8859.html .] [https://bitbucket.org/einsteintoolkit/tickets/issues?status=new&status=open… tickets ready for review] -- ============================== William Gabella Research Assistant Professor Department of Physics and Astronomy Nashville, TN USA (o) 615-343-2713

2 1

Einstein Toolkit Meeting Reminder
by users＠einsteintoolkit.org 03 Mar '21

03 Mar '21

1 0

figures for the Carpet AMR grid structure
by Hamilton, Maria 02 Mar '21

02 Mar '21

Are there any pretty pictures that would show the AMR grid structure implemented by Carpet? 🙂 I know that long time ago I had an undergrad student generate something like that for me for a particular run. I'm looking for something more general and professionally made, like the pictures in this paper https://www.sciencedirect.com/science/article/pii/S0021999113000740?via%3Di… [https://ars.els-cdn.com/content/image/1-s2.0-S0021999113X00063-cov150h.gif]<https://www.sciencedirect.com/science/article/pii/S0021999113000740?via%3Di…> Block-structured adaptive mesh refinement algorithms for Vlasov simulation<https://www.sciencedirect.com/science/article/pii/S0021999113000740?via%3Di…> Direct discretization of continuum kinetic equations, like the Vlasov equation, are under-utilized because the distribution function generally exists … www.sciencedirect.com Maria _______________________ Maria C. Babiuc Hamilton, Ph.D. Professor, Department of Physics College of Science, Marshall University, 1 John Marshall Drive, Huntington, WV, 25755 Room S 257, Phone: (304)696-2754

2 2

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

Users