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/enhancemen... and tracked in the ticket athttps://bitbucket.org/einsteintoolkit/tickets/issues/2383/enhancement-to-new... .  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-alt...

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... in *7* days, timeline https://docs.einsteintoolkit.org/et-docs/Release_Details#Schedule_for_ET_2020_05 [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%5BRH%5D%C2%A0%C2%A0%C... 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=m... 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=m... tagged for the next release other https://bitbucket.org/einsteintoolkit/tickets/issues?kind=proposal&kind=... flagged for the next release * gallery testing: https://bitbucket.org/einsteintoolkit/tickets/issues?kind=task&milestone...

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=...

tickets ready for review:  https://bitbucket.org/einsteintoolkit/tickets/issues?status=new&status=o...

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-cactuscodeorg...

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.