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 _______________________________________________ Users mailing list [email protected] http://lists.einsteintoolkit.org/mailman/listinfo/users
