Users

users@lists.einsteintoolkit.org

3 participants
3984 discussions

Meeting Minutes 2020-05-07
by Bill Gabella 07 May '20

07 May '20

Present: Roland H, Bill G, Beyhan K, Zhao Z, Federico C, Liu H, Atul K, Steve B, Peter D, Alois Peter S, Chris E, Zach E, Maria BH Chair: Roland Minutes: Bill * Questions before we start? * improve interpolation in tabulated EOS in EOS_Omni [FC] Proposed modification to the EOS_Omni thorn: I would like to discuss the possibility of including the patch to the EOS_Omni thorn proposed in the pull request that you can find at https://bitbucket.org/einsteintoolkit/einsteineos/pull-requests/6/enhanceme… and tracked in the ticket athttps://bitbucket.org/einsteintoolkit/tickets/issues/2383/enhancement-to-… . Although the modification may appear as minor, in my opinion, it could be relevant in some cases when adopting tabulated EOS (in particular in case of weak energy dependence on temperature). Best Regards, Federico Cipolletta. ** Federico: Developing code and done Spritz and GRHydro and the EOS_Omni thorn may not preform well in some cases. Using EOS, 3 Dim tables, rho, temp, and electron fluctuations. Define TOV initial data based on ICs, constant entropy or temp, for example. When starting with initial data from constant temperature obtain problems during evolution. GRHydro sim stops after about 140 iterations, temp grows too large. Parameter for t_max is in GRHydro and stops the sim. While in Spritz they get the incorrect results, temp goes too high. Added check in EOS_Omni to check temperatures, rho, y, eps, and want temp. See the tickets and pull request. Interpolate values of temperature, with Newton-Raphson, if iterations are more than a value you pass to other method Bisection. Paper in 2013 noted that if dependency of energy density on temperature is weak the Newton-Raphson can overshoot and can get out of the table ranges. Lines 547 and check line 615, on the derivative, if too high goes to Bisection method, slower but more accurate. Would like this change in a new release. Zach: Could this change cause any trouble with existing GRHydro? Positive impression. Federico: Proposed names for reviewers. Roland: Would it know if temperature is about to land outside of the valid domain of the table? FC: Line 399 (see ticket). RH: Seem to be depriving the user of an error message. Should run it by a high temperature EOS user for discussion. Peter: Do you make sure the root is properly bracketed that is needed by Bisection? Then guaranteed to find the solution. Do not see in the included code. FC: Think it is done in the earlier code. In Line 595 of Newton-Raphson, not included in the Diff shown in the ticket. * update on potential codes to be included in next release, from minutes [RH] o BaikalETK (Zach, Helvi) Zach: Have not heard from Helvi. She might be in finals, so maybe early next week. A couple of exchanges with Roland, GCC 9.3 has weird behavior, from man page or use the command line output so see optimizations for O1. Looking for the optimization for slow compiles, for the 8th order kernel, e.g. Pasted in the O1 optimizations expclicitly and it compiled fast. There is a command line flag for spitting out all the O1 optimizations. Something different from -O1 and from the documentation for O1. Paths forward, split up 8th order kernel, which is good for performance reasonse (3 parts seems optimal performance). That should be a work around for this issue. Re-organizing the equations. So weird. Looks like same problem in gcc 10.0. Peter: Why not tell cactus to compile with these flags? Zach: Could, but simfactory uses -O1, O2, etc. Roland: Cannot taek the explicit list because compiler dependent. Could take the optimization, run it through Perl script for correct options for compiler. Seems too awkward. Zach: Very slow on MacOS but still maybe 3x slower on Linux. Gcc 7.5 and 8.4 compiles times are quite fine. Roland: Would like to see a positive review even if the -O1 is so slow for some platforms, Homebrew or MacPorts, then good on the clusters, at least. Zach: Did add some code tests, and tests enabled, and both (Baikal and Baikal vacuum) passed on all the clusters. o PreSync (Steve, Roland) Roland: Seen a lot of "churn" in the last weeks. Steve: Fxiing things. Seeing if he can adjust Kranc to create correct Presync code. No good count as to how many issues/tickets for fixing it to get it in the release. Roland: Not ready today, but could still be read by release. Some as official, other parts as experimental. * tickets with bugfixes to review before freeze [RH] o no. 2381 https://bitbucket.org/einsteintoolkit/tickets/issues/2381/update-vectors-al… Roland: Support the Power9 cpus on Summit. * no. 2370 https://bitbucket.org/einsteintoolkit/tickets/issues/2370 Roland: Simple fix and will commit after this call. * * https://www.timeanddate.com/countdown/to?iso=20200514T09&p0=3704&msg=Featur… in *7* days, timeline <https://docs.einsteintoolkit.org/et-docs/Release_Details#Schedule_for_ET_20…> [RH] *!!!* * slow compile of Baikal code with gcc 9.3.0 on OSX [RH] See discussion by Zach above. o takes about 30 minutes to compile 8th order FD RHS using gcc 9.3.0 using -O1 and -march=core2 o Zach and Roland have been looking into this o slowness goes away if one uses |gcc -O1 --help=optimizers| which claims to report the options that are used by -O1 o not observed on Linux * deprecation announcement for ET_2020_05 [RH] Roland: Policy of announcing deprecation in the release BEFORE the actual deprecation. Recommends: o non-piraha parser in CST will be removed (will fail to parse READS / WRITES already) o READS / WRITES for non-existing variables will be a CST error, instead of a runtime error when the READS is encountered * http://einsteintoolkit.org/testsuite_results/index.php[RH] Roland: Ran last 4 days ago. Same as before, most are passing, as do the two Baikal tests. https://bitbucket.org/einsteintoolkit/tickets/issues?kind=bug&priority=majo… Peter: Summation by parts, will enable a new default to be minimal bandwidth, and not use the so-called optimized one. Will get information from Miguel and propose it. https://bitbucket.org/einsteintoolkit/tickets/issues?kind=bug&priority=mino… tagged for the next release other https://bitbucket.org/einsteintoolkit/tickets/issues?kind=proposal&kind=enh… flagged for the next release * gallery testing: https://bitbucket.org/einsteintoolkit/tickets/issues?kind=task&milestone=ET… Roland: Advises compiling now but again after the Feature Freeze in about 7 days! o TOV: Brock Brendal (UIUC) o BNS: Shawn Rosofsky (UIUC) o BBH: Peter Schaffarczyk (Kiel) o Poisson: Bil Gabella (Vanderbilt) o Multipatch scalar wave: Beyhan Karakaş (Ege University) unanswered question on mailing list: https://www.einsteintoolkit.org/tools/unanswered.php open tickets sorted by update time: https://bitbucket.org/einsteintoolkit/tickets/issues?status=open&status=new… tickets ready for review: https://bitbucket.org/einsteintoolkit/tickets/issues?status=new&status=open… Steve: New cactus site is https://test.cactuscode.org/ please make comments. Current site http://cactuscode.org/ . And this move is clearly decoupled from the new release. We can do it whenever. New Cactus ticket https://bitbucket.org/einsteintoolkit/tickets/issues/2387/move-cactuscodeor… Atul: *BBH test*, finished the figure for position of the centers and the strain. Some scaling issue compared to LIGO version. Ian Hinder's code on Mathematica, SimulationTools helps to sort that out: https://simulationtools.org/ . Peter S. will work on that. Working on Kerr Ricci scalars using Mathematica and Atul is missing a few C compilers that he needs...on his version of Mathematica on Windows. Third set of images on apparent horizons, made with VisIT. Issue page on GitHub, Roland recalls that there is a statement that you are using the intercompiler (?) to compile things. Should send a message to Users list on Einstein toolkit and on the Simulation Tools GitHub issues page, BitBucket https://bitbucket.org/simulationtools/simulationtools/issues . Atul is working on Windows with Mathematica and Steve recommends using the Linux on Windows. * Anything else: ** Beyhan: Getting errors with core collapse control thorn in the source code, he thinks. Roland: Sounds like something is missing. Version from SVN, could be old. Post a ticket if you still have problems. ** Bill: Is anyone running VisIT in a container? Seems not---will find a way to run it. Roland: *Vote next week for Feature Freeze.* Take a look at the new codes being included. -- ===================================== William Gabella Research Assistant Professor Department of Physics and Astronomy Vanderbilt University Nashville, TN USA b.gabella(a)vanderbilt.edu (o) 615-343-2713

1 0

normal vector when looping over boundary using CCTK_LOOP3_BND
by Roland Haas 07 May '20

07 May '20

Hello all, I am trying to loop over the boundary of my domain using CCTK_LOOP3_BND(cckGH, i,j,k, ni,nj,nk). The documentation http://einsteintoolkit.org/usersguide/UsersGuidech9.html#x13-102000C1.7.1 says that "ni, nj, and nk are names of variables describing the (outwards pointing) normal direction to the boundary as well as the distance to the boundary." However on a 5x5x5 grid and 1 boundary point in a uniprocess setup ni, nj, nk are either 0 or 1 but never eg -1 which I would expect for the lower boundary. Looking at the code in flesh/src/include/cctk_Loop.h shows that ni is computed as const int ni CCTK_ATTRIBUTE_UNUSED = cctki0_idir<0 ? i+1 : cctki0_idir==0 ? 0 : cctki0_imax-i; ie by construction is always non-negative. LoopControl does the same. Now my question is how am I supposed to find out which boundary I am at (lower or upper)? 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 .

2 1

Einstein Toolkit Meeting Reminder
by users＠einsteintoolkit.org 06 May '20

06 May '20

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

Proposed modification to the EOS_Omni thorn
by Federico Cipolletta 06 May '20

06 May '20

We propose the attached patch for the file EOS_Omni/src/nuc_eos_cxx/helpers.hh of EOS_Omni in order to fix a bug that causes GRHydro to fail in some situations involving tabulated EOSs. We are currently working on the development of our GRMHD code, "Spritz", which will be capable of dealing with tabulated EOS, considering the evolution of Temperature, T, and Electron Fraction, Y_e. In order to test the implementation, we are currently performing some TOV tests with both Spritz and GRHydro, adopting the LS220 tabulated EOS that we downloaded from the stellarcollapse website. We realized that the EOS_Omni thorn may present some issues when dealing with tabulated nuclear EOS. In particular, when T must be found in relation to other thermodynamic quantities, this is normally done by the EOS_Omni thorn by computing T through a Newton-Raphson routine with a "fall-back" on Bisection method in the case of too many iterations (the procedure is related to the routines "nuc_eos_findtemp" and "bisection" contained in the file "EOS_Omni/src/nuc_eos_cxx/helpers.hh" - if the number of iterations performed by Newton-Raphson is greater that one hard-coded 200 value, then the Bisection method is called). With our tests for the LS220 EOS, we do see that the calculation of T, in some cases, may not perform well. Specifically, with the GRHydro code, roughly after 144 iterations the T goes above the prescribed parameter "GRHydro_max_temp" (which we imagine being chosen in accordance with the maximum value of T given in the Table), so the simulation is stopped. With Spritz, as well, we clearly get one wrong T value (well above T_max given in the table). This issue is probably related to a weak dependence of T on \epsilon and can be solved by using the bisection method, see Section IV of Galeazzi, Kastaun, Rezzolla, and Font, PRD (2013). Lorenzo Sala, one of our collaborators, already implemented this modification in the aforementioned routines of the EOS_Omni thorn. In the modified version, if the energy dependence on the temperature is weak, i.e., if the derivative of the function is too large and therefore the Newton-Raphson routine may overshoot (in the routine "nuc_eos_findtemp"), the code switches to a safer bisection method (in the routine "bisection"). In addition, the "bisection" routine presents a slight modification in order to be sure of not going below the minimum of tabulated temperature value. With these modifications, both tests with GRHydro and Spritz result to be successful and well in accordance. We would like to propose the inclusion of the modified EOS_Omni thorn in the future releases of the EinsteinToolkit, in order to provide the community with this more robust version. For your reference, I attach: 1- the file "helpers.hh" containing our proposed modifications; 2- a patch file "diff_STDvsMOD.txt" where I compared the standard (STD) vs the modified (MOD) helpers.hh file 3 - a file "LS220_RHOmax.pdf" with a plot showing the evolution of maximum density for the TOV test with the LS220 EOS and comparing the results obtained with Spritz and GRHydro plus the standard and modified EOS_Omni thorn; 4- a file "LS220_Tmax.pdf", which is the same as 3 but for maximum temperature. Best Regards, Federico Cipolletta.

1 0

Agenda for Thursday's Meeting
by users＠einsteintoolkit.org 04 May '20

04 May '20

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

1 0

A question about radius in CarpetRegrid2
by ZhiChao Zhao 30 Apr '20

30 Apr '20

Hi All, I am using ET to simulate a BNS merge. I set the radius as(max 7 level): CarpetRegrid2::radius_1[1] = 270.0 CarpetRegrid2::radius_1[2] = 162.0 CarpetRegrid2::radius_1[3] = 94.5 CarpetRegrid2::radius_1[4] = 40.5 CarpetRegrid2::radius_1[5] = 27.0 CarpetRegrid2::radius_1[6] = 13.5 However, when I check the radius of mesh in VisIt(the output h5 file), I found the radius of each level becomes: [ 512, 352, 200, 112, 50, 32, 16] , which is different from what I have written in CarpetRegrid2:: radius_1[index]. Could anyone tell me how the radius transfer from 270.0 to 352? Or give me any document of Carpet? My another parameters are: CoordBase::dx = 6.4 CoordBase::xmax = 512.00 Carpet::ghost_size = 3 Carpet::prolongation_order_space = 5 Thanks a lot! Yours, Zhichao Zhao.

2 1

Meeting Minutes for 2020-04-30
by Steven R. Brandt 30 Apr '20

30 Apr '20

Present: Ian Hinder, Steve, Bill, Roland, Peter, Alois Peter, Helvi, Zhichao Zhao, Yosef, Christopher Evens, Zach, Atul Chair: Helvi Note Taker: Steve Update to cactuscode - Regenerated for the last time (?) - List of issues: https://github.com/EinsteinToolkit/cactuscode.org/issues * Bugs (problems with the conversion) * Enhancements (this probably out of date) * No longer have dynamic comments Zach: Gcc9.3.0 takes a ridiculously long time in MacOS it takes half an hour to compile the 8th order code. Under Linux it takes 30 seconds or so. Ian suggests that the "inline" might be the problem. Also, it could be the architecture. Note the compile is fast with less than 9.3. Zach is able to get it to compile faster by splitting up the routine. Report to GCC maintainers? Release will be pushed back by another week to make it possible for everyone to catch up. PreSync addressing Roland comments. Vector support in Fortran Do Macro changes for Kranc? No. New release test suite results Roland sees nothing unexpected Cory, SuperMUC, Golub show more failures than we'd like (Intel compiler) But no new failures Roland tracks how long it takes to build and how long it takes to run the tests Steve notes that we need parallel tests Bugs: fix adaptive time stepping others are presync related Gallery: Change the representation of the data on the website? Since it's targeting the first LIGO detection, could it be somehow compared to what LIGO saw? Add a link to the LIGO data? Some problems comparing with LIGO data. Poisson example--had some problems running and comparing numbers. How was the plot made? Visit session file in the ticket. there are scripts in https://bitbucket.org/einsteintoolkit/www/src/master/gallery/bbh/ for generating some of the plots (you need mathematica and simulationtools) Summation by parts question, Peter was supposed to update

1 0

Einstein Toolkit Meeting Reminder
by users＠einsteintoolkit.org 29 Apr '20

29 Apr '20

1 0

kesnar spacetime graphs.
by Nisa Amir 29 Apr '20

29 Apr '20

Hello, Hope all of you are doing well. I am trying to replicate some examples given in par directory of the Cactus for practice. I have run the parameter file kasner.par, have obtained the results but my graph is not correct according to the paper arXiv-1111.3344. I am attaching the parameter file which I have run, the resulting .asc file and the graph I have obtained. Kindly, anyone guide me what mistake I am making. Thanks

2 7

Agenda for Thursday's Meeting
by users＠einsteintoolkit.org 27 Apr '20

27 Apr '20

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

1 0

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

Users