[Users] [ET Trac] #2064: Add GiRaFFE to the Einstein Toolkit
Zach Etienne
zachetie at gmail.com
Mon Nov 4 13:05:57 CST 2019
Hi again, Erik.
To better illustrate (and hopefully make working with BaikalETK easier for
you), I just performed the second step of the NRPy+ development process on
BaikalETK: creating a separate Python module for generating BaikalETK.
Simply do a git pull then from within, e.g., iPython, type:
import BaikalETK.BaikalETK_Pymodule as BE
BE.BaikalETK_codegen(outrootdir="BaikalETK-validate")
The full function call allows for many parameters to be adjusted as desired:
def BaikalETK_codegen(outrootdir = "BaikalETK/",
FD_order=4, # Finite difference order: even numbers
only, starting with 2. 12 is generally unstable
LapseCondition = "OnePlusLog", # Set the standard 1+log
lapse condition
ShiftCondition = "GammaDriving2ndOrder_NoCovariant", #
Set the standard, second-order advecting-shift,
#
Gamma-driving shift condition
add_stress_energy_source_terms = False, # Enable
stress-energy terms?
default_KO_strength = 0.1 # default Kreiss-Oliger
dissipation strength; adjustable within thorn's param.ccl.
):
Admittedly, the BaikalETK_Pymodule isn't very... modular at this point.
Instead it calls on a number of largely infrastructure-agnostic NRPy+
modules. Once there are modules within NRPy+ for, e.g., setting param.ccl
etc, modules like this one will shrink and simplify considerably. This is
one of the goals of the proposed ETK/NRPy+ development.
If you wish, you are free to modify either the Python module (git friendly)
or the Jupyter notebook (not as git-friendly, but where the documentation
is housed), but are required to update both in the end. I think you'd agree
that any code updates should require corresponding documentation updates.
I haven't yet updated the BaikalETK Jupyter notebook to validate that its
output agrees perfectly with the separate BaikalETK_Pymodule Python module
(we call this "self-validation"), but I did confirm independently that only
a couple of harmless whitespace differences appear in the generated C code
between the BaikalETK notebook & BaikalETK_Pymodule.
Thanks again for your feedback.
-Zach
* * *
Prof. Zachariah Etienne
Physics & Astronomy Dept.
West Virginia University
http://astro.phys.wvu.edu/zetienne/
http://blackholesathome.net
<https://blackholesathome.net>
On Mon, Nov 4, 2019 at 12:15 PM Zach Etienne <zachetie at gmail.com> wrote:
> Hi Erik,
>
> Thanks for the feedback, and sorry to hear about the frustration. Indeed
> BaikalETK is only a proof-of-principle code at the moment, in which the
> second stage of development (copying the code blocks in the Jupyter
> notebook to a proper, callable, git-friendly Python module) hasn't been
> completed yet. I'm hoping that with more resources to combine ETK & NRPy+
> development, the full modularization of all the ETK Jupyter notebooks can
> be completed.
>
> > The only way I see is to undo my changes ("git checkout"), and then
> pull your changes. In this case that's fine because there are no major
> changes, but if I had made changes I'd be in trouble.
>
> I generally do a `git diff` if `git pull` complains about conflicts, and
> it's usually easy to see if anything significant has changed (and then do
> `git checkout` if not). Maybe if I chose a standard way of prefixing lines
> that are ignorable comments (e.g., "COMMENT: Finished BSSN symbolic
> expressions in") a simple script could be written that checks for trivial
> differences like these. Removing all output isn't a good idea as it would
> wipe away the "standard" output displayed on nbviewer (
> https://nbviewer.jupyter.org/github/zachetienne/nrpytutorial/blob/master/NRPyPlus_Tutorial.ipynb)
> in case the user wants only to learn from the Jupyter documentation.
>
> Also if in doubt, one can simply compare the thorn output from the master
> Jupyter notebook with your own version. We're making it easier to redirect
> all NRPy+ output to whatever directory you like, so that such diffs can be
> made quickly and easily.
>
> -Zach
>
> * * *
> Prof. Zachariah Etienne
> Physics & Astronomy Dept.
> West Virginia University
> http://astro.phys.wvu.edu/zetienne/
> http://blackholesathome.net
> <https://blackholesathome.net>
>
>
> On Mon, Nov 4, 2019 at 11:56 AM Erik Schnetter <schnetter at cct.lsu.edu>
> wrote:
>
>> On Mon, Nov 4, 2019 at 8:38 AM Zach Etienne <
>> trac-noreply at einsteintoolkit.org> wrote:
>>
>>> #2064: Add GiRaFFE to the Einstein Toolkit
>>> Reporter: Zach Etienne
>>> Status: open
>>> Milestone: ET_2019_10
>>> Version: development version
>>> Type: enhancement
>>> Priority: minor
>>> Component: EinsteinToolkit thorn
>>>
>>> Comment (by Zach Etienne):
>>>
>>> @Ian Hinder : Version control with Jupyter is only slightly more
>>> difficult than with plain source code, as its JSON is plaintext.
>>>
>>> Is it a good idea to pull the whole code into notebooks? I don’t know
>>> how sustainable it is when you have multiple contributors; merging changes
>>> from different people can become very difficult.
>>>
>>> Writing the Jupyter notebook is only the first step in NRPy+
>>> development, but arguably the most important as it contains the
>>> documentation and some validation checks. I’d liken the Jupyter notebook
>>> phase more to collaboratively writing a journal article with a shared git
>>> repo than code development within such a repo.
>>>
>>
>> I'd like to add a point to this, out of frustration:
>>
>> A few weeks ago I downloaded and ran Tutorial-BaikalETK.ipynb. Today I
>> try to "git pull", and it doesn't work, because there are differences in
>> the output everywhere (e.g. "Finished BSSN symbolic expressions in
>> 1.2987918853759766 seconds"). The only way I see is to undo my changes
>> ("git checkout"), and then pull your changes. In this case that's fine
>> because there are no major changes, but if I had made changes I'd be in
>> trouble.
>>
>> I think the problem is that the output is stored in the git repo. In the
>> future, you might want to switch to a system where (a) notebooks
>> automatically have all output removed before they are committed, and (b)
>> upon commit, Travis or a similar system creates for-viewing-only notebooks
>> with a standardized output.
>>
>> -erik
>>
>>
>>
>>> After the notebook has been written, a separate Python module containing
>>> the code developed in the Jupyter notebook is then written. At the bottom
>>> of every NRPy+ Jupyter notebook it is required to include a self-validation
>>> check against the separate Python module (many NRPy+ Jupyter notebooks have
>>> additional validation checks). Further, all NRPy+ Python modules must
>>> include proper unit testing on all symbolic expressions generated, so that
>>> Travis CI can confirm agreement with the trusted version. This has the nice
>>> consequence of often requiring developers to update the documentation any
>>> time the module is updated in order for the Jupyter notebook to pass
>>> self-validation tests, though generally NRPy+ developers prefer updating
>>> the Jupyter notebooks as a first step, then propagating changes to the
>>> module & unit tests. Proper documentation makes our lives much easier and
>>> is the foundation of a sustainable codebase.
>>>
>>> The above approach has worked fine with multiple contributors so far, as
>>> NRPy+ is extremely modular, with 70+ Python modules & about 100 Jupyter
>>> notebooks. Also I generally don’t put multiple students on exactly the same
>>> project (though they certainly do interact and benefit from each others'
>>> documentation). Thus
>>>
>>> --
>>> Ticket URL:
>>> https://bitbucket.org/einsteintoolkit/tickets/issues/2064/add-giraffe-to-the-einstein-toolkit
>>> _______________________________________________
>>> Trac mailing list
>>> Trac at einsteintoolkit.org
>>> http://lists.einsteintoolkit.org/mailman/listinfo/trac
>>>
>>>
>>
>> --
>> Erik Schnetter <schnetter at cct.lsu.edu>
>> http://www.perimeterinstitute.ca/personal/eschnetter/
>>
>> _______________________________________________
>> Users mailing list
>> Users at einsteintoolkit.org
>> http://lists.einsteintoolkit.org/mailman/listinfo/users
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.einsteintoolkit.org/pipermail/users/attachments/20191104/c261ad59/attachment-0001.html
More information about the Users
mailing list