[Users] Meeting Minutes 2020-05-07

Thu May 7 10:38:05 CDT 2020

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/enhancement-to-newton-raphson-and/diff 
    and tracked in the ticket
    athttps://bitbucket.org/einsteintoolkit/tickets/issues/2383/enhancement-to-newton-raphson-and 
    .  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-altivec-support   

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=Feature+freeze&font=sanserif 
    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[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=major&priority=blocker&priority=critical&status=new&status=open  
    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=minor&priority=trivial&milestone=ET_2020_05&status=new&status=open  
    tagged for the next release
    other
    https://bitbucket.org/einsteintoolkit/tickets/issues?kind=proposal&kind=enhancement&milestone=ET_2020_05&status=open&status=new  
    flagged for the next release
  * gallery testing:
    https://bitbucket.org/einsteintoolkit/tickets/issues?kind=task&milestone=ET_2020_05 

    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&sort=-updated_on

tickets ready for review: 
https://bitbucket.org/einsteintoolkit/tickets/issues?status=new&status=open&sort=-updated_on&q=Please%20review

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-to-be-hosted-by-github

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 at vanderbilt.edu
(o) 615-343-2713

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.einsteintoolkit.org/pipermail/users/attachments/20200507/52488a9d/attachment-0001.html 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: pEpkey.asc
Type: application/pgp-keys
Size: 1769 bytes
Desc: not available
Url : http://lists.einsteintoolkit.org/pipermail/users/attachments/20200507/52488a9d/attachment-0001.bin 