Closed teuben closed 8 months ago
I'm not sure it's the same as for ATHENA. REBOUND is a shared library. It is only compiled once. Almost all options (collision routines, integrators, etc) are set at runtime. There are only a few options that are set at compile time (whether MPI or OpenMP are used). What the user does with the library is out of REBOUND's control. The examples provide a simple Makefile and a problem.c file with a main routine. That would be the place to implement the self-describing feature you're suggesting. But that's really up to the user.
Two more thoughts:
reb_githash_str
. To print it in a program use printf("%s\n", reb_githash_str);
. To print it from the command line one can use for example strings librebound.so | grep -x '.\{40\}'
.If one wants to find out what settings have been used for a given simulation, then one can use the reb_simulation_diff
function. This will print all changes that a user has made to a vanilla simulation:
#include "rebound.h"
#include <stdio.h>
#include <stdlib.h>
int main(int argc, char* argv[]) {
struct reb_simulation* r = reb_simulation_create();
r->G = 2.;
reb_simulation_add_fmt(r, "m", 1.);
reb_simulation_add_fmt(r, "m a e", 1e-3, 1., 0.1);
struct reb_simulation* r_empty = reb_simulation_create();
reb_simulation_diff(r, r_empty, 1);
}
Understood. I took the plummer example in rebound, and nemo-fied this as an example how a 3rd party could use it. In case I wind up giving this hypothetical talk, it would be my NEMO example. Looks promising so far.
Currently the system seems to promote a single binary "rebound" (athena does something similar). In athena we have a self-describing feature, in that case -h will describe for which kind of physics it was compiled. With a little extra requiremenrt in the problem.c one could make the executable a little more self-describing.
Alternatively, I could rename the binary to rebound_ or something like it.
as i'm writing this, I have a deja-vu on this issue.