Hello all,
I re-ran the code generation for McLachlan, WeylScal4, CTThorns, and EinsteinExact checked that there is no difference (CTThorns has an inconsequential change in source code where (-a)*(b) changes to (a)*(-b)).
Baikal when regenerated following the README file does show changes compared to the version in the ET (wvuthorns), namely the manual commits
* 6b982d7 - WVUThorns Baikal/BaikalVacuum: Correct error message (1 year, 5 months ago) <zetienne> * 314ad00 - WVUThorns Baikal/BaikalVacuum: GetBoundarySpecification() does not seem to work on certain processor counts. Instead use workaround adopted by GRHydro & Lean to set bndsize when Boundary_SelectVarForBC() for the BSSN constraints (1 year, 5 months ago) <zetienne>
are not present in the nrpytutorial commit used to regenerate Baikal.
Yours, Roland
Present: Peter D, Bill G, Zach E, Yosef Z, Roland H, Atul K, Steve B,
Chair: Peter D, Minutes: Bill G
release], [https://urldefense.com/v3/__https://docs.einsteintoolkit.org/et-docs/Release... Details].
** The Kranc and NRPy+ codes, regeneration. Roland, will check and run make (now). Seems to be working, but with the Readme hash for NRPy+, so the older code.
Zach, looking at WUThorns recently and Baikal has not been updated in a long time. Core C code is the same, but different in the Python and Codegen side. Also the automation of the CCL files has been improved. Because it take a long time for 8th order finite diff, it does a code gen in parallel, and Python's GIL does not allow parallelization easily, so NRPy clones itself, so when it is finished has to combine the results, uses Pickling. Zach found race conditions in the old version of Baikal that caused problems in the Codegen of Baikal and these have been remedied. Zach, advocates for reviewing the new NRPy+ stuff.
Roland, we check regeneration just to see it works. You should be able to regen it, if one wants. So that if someone types to regen the code they get the latest versions. Zach suggests to move on to the newer version. A diff will show a lot of differences, Zach moved code between .h files to .c files, to speed up the compilation. Does pass the unittests that were set up. Zach is using the new version for BBHs, for his work. The "new way" is the code to use; the "old way" is still there.
Zach can write instructions for testing. Zach, new code is in NRPy+ master and in Jupyter notebooks. Roland, but that is not what the Readme files say to do. Zach, could convert the notebooks to Python files. Roland, prefers if could cd in Baikal_ETK and it would build with a Makefile. There is a one liner that runs the Jupyter by converting to Python and running.
Feature freeze is the 12th of April.
Decide on a name? Those present voted for Bernhard Riemann as the name of the next release. https://urldefense.com/v3/__https://en.wikipedia.org/wiki/Bernhard_Riemann__...
** Gallery, BBH? Roland, no response from students, APS is in the way. Steve could do it, but better if students do it. Steve, the BBH gallery is fairly will automated with Python scripts.
A little early to run the gallery examples. Usual advice, if you have never run an example, do it soon. And the run it again closer to and then after the Feature Freeze.
** FLRW Solver
Roland, has not tried to compile it, will do that. Needs the Python C development files, which may or may not be present on certain clusters. Embeds Python interpreter in the compiled C code and runs preprocessed code. It might also need some non-standard modules. Python external library, maybe. If so difficult, we do not want to include it this round.
[https://urldefense.com/v3/__https://www.einsteintoolkit.org/tools/unanswered... unanswered question on mailing list]
Garrison's post about Seg Fault in CarpetReduce, when ghost zones set to 1 for reduction. Roland will respond and ask again for a par file.
[https://urldefense.com/v3/__https://bitbucket.org/einsteintoolkit/tickets/is... open tickets sorted by update time]
#2601 Add four parameters for carpet, Liwei has added six parameters with all x,y,z being treated ecumenically. https://urldefense.com/v3/__https://bitbucket.org/einsteintoolkit/tickets/is...
#2392 Roland, default values of keyword parameters not checked. Defaults for keywords were not set correctly, just taking the first one in a list. Been around for 10+ years. Steve does have fix for this at compiles time, is a pull request. That does NOT close the ticket because of other issues. Roland, should we keep the runtime checks? If we have fixed the compiletime checks for these keyword parameters. Steve agrees do not need a runtime check for these...so maybe can close this ticket. Steve, wants this PR in. AHfinder is used without seeing the AHFinder bug. Roland, it is a level 3 or 4 warning. AHFinder has the incorrect defaults; AHFinderDirect is fine, from Jonathan. https://urldefense.com/v3/__https://bitbucket.org/einsteintoolkit/tickets/is...
#2518 BlueGeneQ support? Nothing done.
# 963 Improve McLachlan accuracy
#2589 Adding Kuibit to the tutorial server. Also a Pull Request to update the server used for the tutorial server. Steve and Roland have a discussion about the details. Steve will try to review and get it in. https://urldefense.com/v3/__https://bitbucket.org/einsteintoolkit/tickets/is...
[https://urldefense.com/v3/__https://bitbucket.org/einsteintoolkit/tickets/is... tickets ready for review] # 2364 is an enhancement only, so not a big deal.
Any other business
Chairs / Minutes
April 14: Chair Roland, MInutes Atul