Adding Tidymess to AMUSE documentation#1270
Conversation
LourensVeen
left a comment
LourensVeen
left a comment
There was a problem hiding this comment.
This is definitely going in the right direction! I've added some comments with more improvements, but go ahead and focus on adding more content if you want, they can be fixed later as well.
|
|
||
| In this tutorial, we will create an interface from scratch for the | ||
| TIdal DYnamics of Multi-body ExtraSolar Systems code, or ``TIDYMESS``, | ||
| written by Dr. Tjarda Boekholt and Dr. Alexandre Correia. This code |
There was a problem hiding this comment.
Is there a paper we can cite here?
| =============== | ||
|
|
||
| This tutorial assumes you have a working amuse or amuse development build, | ||
| preferrably in seperated environment (virtualenv, venv or conda etc). |
|
|
||
| This tutorial assumes you have a working amuse or amuse development build, | ||
| preferrably in seperated environment (virtualenv, venv or conda etc). | ||
| Please ensure that amuse is setup correctly, this can be verified by running the |
|
|
||
| > amusifier --type=c --mode=dir Tidymess | ||
|
|
||
| Having run the ``amusifier``, we now have our new directory in ``amuse/src/amuse_tidymess``. |
There was a problem hiding this comment.
Well, that depends. Did we move into amuse/src first?
There was a problem hiding this comment.
Also, there are two options: inside AMUSE here, and stand-alone in any directory or a separate repository or whatever. But I think it would be best to explain the stand-alone option in a separate section at the end.
|
|
||
| Building the code | ||
| ================= | ||
| Before we start working on the interface, we should try and install and compile ``TIDYMESS`` |
|
|
||
| Setting up Autoconf | ||
| ~~~~~~~~~~~~~~~~~~~ | ||
| The ``amuse_deps`` file we just created informs the ``AMUSE`` build system about whether or not our |
There was a problem hiding this comment.
I would remove this first sentence, as it's repetitive and not very related to the rest of this paragraph. Instead, maybe add an instruction to the previous paragraph for the user to go to the top-level directory and run ./setup, so that they can see their code in the list?
|
|
||
| .. WARNING:: | ||
|
|
||
| Make sure the the ``amuse_tidymess/support/shared/`` folder is a simlink to ``amuse/support/shared/`` |
There was a problem hiding this comment.
"symlink", it's a symbolic link not a simulated one. Although that would be appropriate in this context 😄
|
|
||
| Naming our project | ||
| ~~~~~~~~~~~~~~~~~~ | ||
| Amuse naming conventions typically follows PascalCase, so we will name our project Tidymess. |
There was a problem hiding this comment.
It's a class name, and PEP-8 says they should be formatted like that. So nothing AMUSE-specific.
| +----------------------------------+-------------------------------------------+ | ||
| | Interface: | Example codes: | | ||
| +----------------------------------+-------------------------------------------+ | ||
| | ``GravitationDynamicsInterface`` | N-body: Tidymess, Ph4, Huyano | |
There was a problem hiding this comment.
"Huayno", it's an Andean dance.
|
|
||
| Defining the Python interface | ||
| ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ | ||
| The ``interface.py`` actually defines two classes: the high-level and low-level Python interfaces. The high-level |
There was a problem hiding this comment.
This paragraph could use some work. Maybe instead of "high-level" and "low-level" we could call it the Python interface and the native interface? That's a bit more descriptive (although that term native may also not be well-known, hmm). It's not explained what the low-level interface does anyway.
As for the structure, this mixes explanation of concepts, a practical description of what the amusifier does, and the next step to do. I think it's better to 1) briefly introduce the structure (two interfaces, user calls Python interface, which is handled by AMUSE and results in a call to the native interface, which calls the code or accesses data), then 2) in the next paragraph explain that the first step is making the Python interface, introduce the concept of standard interfaces, and then 3) we get to the practical side and we can mention that there's a stub for interface.py already there.
elkogerville
added
the
area: documentation
2 participants
This PR adds a section to the AMUSE documentation on how to add a C++ code to AMUSE, using Tidymess as an example.
The documentation is still a work in progress, with many sections still needed. This PR is intended for feedback rather than merging into the codebase.