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