[Users] [ET Trac] #2064: Add GiRaFFE to the Einstein Toolkit

[Erik Schnetter]

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/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.einsteintoolkit.org/pipermail/users/attachments/20191104/1fcdafff/attachment.html