[Users] Meeting Minutes 2022-04-07

Thu Apr 7 10:02:36 CDT 2022

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
> 
> * next [https://urldefense.com/v3/__https://docs.einsteintoolkit.org/et-docs/Release_Process__;!!DZ3fjg!tY0RS6oUnjQ4dsLprTv_UO5S5XtSP-A1VRMtn_UViOrahhqTAb7JNucLsZ4alEqc$  ET 
> release],
> [https://urldefense.com/v3/__https://docs.einsteintoolkit.org/et-docs/Release_Details__;!!DZ3fjg!tY0RS6oUnjQ4dsLprTv_UO5S5XtSP-A1VRMtn_UViOrahhqTAb7JNucLsY4-nhfB$  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__;!!DZ3fjg!tY0RS6oUnjQ4dsLprTv_UO5S5XtSP-A1VRMtn_UViOrahhqTAb7JNucLsdetOPYV$ 
> 
> ** 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.php__;!!DZ3fjg!tY0RS6oUnjQ4dsLprTv_UO5S5XtSP-A1VRMtn_UViOrahhqTAb7JNucLsZG3NC-b$  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/issues?status=open&status=new&sort=-updated_on__;!!DZ3fjg!tY0RS6oUnjQ4dsLprTv_UO5S5XtSP-A1VRMtn_UViOrahhqTAb7JNucLscfqQwDw$  
> 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/issues/2601/add-four-more-parameters-for-carpet__;!!DZ3fjg!tY0RS6oUnjQ4dsLprTv_UO5S5XtSP-A1VRMtn_UViOrahhqTAb7JNucLse5SM9TJ$ 
> 
> #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/issues/2392/default-values-of-keyword-parameters-are__;!!DZ3fjg!tY0RS6oUnjQ4dsLprTv_UO5S5XtSP-A1VRMtn_UViOrahhqTAb7JNucLsb10SRai$ 
> 
> #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/issues/2589/modernize-information-about-visualization__;!!DZ3fjg!tY0RS6oUnjQ4dsLprTv_UO5S5XtSP-A1VRMtn_UViOrahhqTAb7JNucLsdvfZKk_$ 
> 
> [https://urldefense.com/v3/__https://bitbucket.org/einsteintoolkit/tickets/issues?status=new&status=open&sort=-updated_on&q=Please*20review__;JQ!!DZ3fjg!tY0RS6oUnjQ4dsLprTv_UO5S5XtSP-A1VRMtn_UViOrahhqTAb7JNucLsQxwyCNa$  
> 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
> 

-- 
My email is as private as my paper mail. I therefore support encrypting
and signing email messages. Get my PGP key from http://keys.gnupg.net.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
Url : http://lists.einsteintoolkit.org/pipermail/users/attachments/20220407/4f524bc7/attachment-0001.bin 