Binary examples typo

[teuben]

it seems the README file in Binary refers to the wrong yml file

There is also an example where the stars no longer feel mutual self-gravity, but instead are evolved in an external logarithmic potential. This may be run using `mpirun -np 1 exp binary.yml`. This example demonstrates `noforce`.

this should be logpot.yml

I'm very partial to hardcoding paths in a yml file. This is perhaps a discussion for another time. But what we did in athena, is allow the executable to override config file parameters, for example something like

     exp -f logpot.yml    nsteps=10000 outdir=run1 ldlibdir=$NEMO/opt/lib/user

another nitpicking comment would be that the subdirectory user is often found in a system directory, so it ought to give more provenance in the name itself, e.g. EXP_user. With a prefix of /usr/local there would be a /usr/local/lib/user directory, which I think is asking for trouble.

[michael-petersen]

Transferred the second comment to EXP-code/EXP#115, thanks!

[michael-petersen]

See #9 for a simple typo fix.

Overriding particular flags might work for global, but the configurations get complicated very quickly from there. Is it helpful for certain global parameters to the point where we think it is worth implementing, @The9Cat ? I vote no offhand, but am open to being persuaded.

[The9Cat]

Ironically, earlier versions of exp (prior to our YAML replacing INI) did exactly this. But we need and depend on the YAML hierarchy at this point given the exp architecture.

That said, we could implement parsing of additional command-line key-values pairs for [Global] without much difficulty. I.e. we could compare any dangling command line arguments with the internal YAML db and replace default keys by any matching command like key values. The YAML provenance file would still be written correctly.

My concern is user confusion. The advantage of YAML is discipline. So my feeling is similar to @michael-petersen: no offhand, but I could be persuaded.

[teuben]

In athena there's always a run directory, and it would write the correct new yaml file in that directory. But I could imagine with some abuse that might run into provenance issues, and as you said, discipline with less liberty could prevent that. Sadly, NEMO is full of these user "conveniences" and users will just never remember them. But have a very strict discipline will cause some to re-invent the wheel. You can't seem to win in this game.

[The9Cat]

Yes exp currently writes the correct new YAML file in the run directory as well. So overrides would not break provenance here either. It's really confusion that worries me. We have so much flexibility in this code that it's easy to get confused. When we went all in on YAML, I decided that having more ways to set parameters was a bad thing.

But I'm happy to be having this discussion. We pulled it back from dual config + command line key=value some years ago.

[michael-petersen]

#9 has been merged; we've moved the discussion of command line key=value to EXP-code/EXP#116.