Options passed to mpirun are hardcoded

[ofuhrer]

We use different MPI libraries which use different default options passed to the mpirun command. While OpenMP (default) requires --allow-run-as-root --use-hwthread-cpus --mca btl_vader_single_copy_mechanism none" MPICH actually does not require any arguments and does not understand the aforementioned arguments. These are currently hardcoded infv3config._native.pyand it would be nice to be able to override them from thefv3config.run_XXX()` command.

[nbren12]

For this reason and others, @mcgibbon and I pretty much think fv3config.run_... should be deprecated

• nothing is using the kubernetes usage anymore
• For local development with docker, it's easier to pull the docker run to the highest level rather then embedding it in the code. For example, if I write a script to work like docker run python script.py, then script.py only needs to know about the containerized environment. OTOH, a script like python script_with_docker_run_inside.py will need to know about the host and guest, and will be quite brittle.
• run_native bakes in assumptions about log capturing, output locations, flags etc that are more cleanly handled by a linux shell with pipes etc.

Overall the problem with the run_ stack is that we are trying to wrap underlying APIs (docker, k8s, shell) that are already parsimonious. If we break the assumptions of the wrapping API and add too many options, ultimately you end up with a system that can execute arbitrary linux commands---at which point the code is basically a crappy front-end to the linux shell/k8s API/docker run.

[ofuhrer]

Sounds good. I was basically just following the example in fv3gfs-wrapper/examples and tried to get it running with our current base images. I think the example in fv3gfs-fortran/examples is already using the strategy you are outlining, so I guess it's mostly a question of updating the example and documentation.

[nbren12]

Yah, I think it's an easy change, but run_native is used pretty widely across the test suite. So it will take some effort. Maybe when we shut down free access to the fv3config data cache we can address this on the fv3net side.

[ofuhrer]

Closing this issue.