[Users] Meeting Minutes 2021-03-04

[Gabella, William E]

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

** 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&sort=-updated_on&q=Please%20review 
tickets ready for review]


-- 
==============================
William Gabella
Research Assistant Professor
Department of Physics and Astronomy
Nashville, TN USA
(o) 615-343-2713