ESMCI / ESMCI/cime

Porting: MPILIBS: documentation and handling

Open
#3,537 7 comments 0 reactions 0 assignees View on GitHub
Low Priority tp: config tp: documentation ty: enhancement
Dominant language
Python
Stars
174
Forks
225
Avg merge
1d 16h
Merged PRs (30d)
14

Description

In writing a wrapper script to facilitate making a cime machine port, I ran into a question about the allowed values for MPILIBS. This is partly a documentation issue, but partly reporting what looks like a minor issue with the way cime currently handles MPILIB.

My sense, from grepping through cime, is that – for the most part – a given machine port can use whatever name it wants for its MPILIBS. A major exception is mpi-serial, but other than that (and the other exception noted below), it seems like cime doesn't care what you call your mpi library, as long as you are self-consistent within your given machine port block in config_machines.xml and config_compilers.xml. For example, if you're using openmpi, you can call it openmpi or you can call it my_mpi_library, and it looks like you'll get the same result as long as you use that name consistently. **My first question is: Does this seem right to others? (@jedwards4b ? @jgfouca ?) If so, I'm wondering if that should be mentioned in the documentation, to save others the work I just did trying to figure that out.**

However, there are a couple of exceptions to this. In CESM's `config_compilers.xml` I see this in the generic intel block:

https://github.com/ESMCI/cime/blob/50a0edc493659c086c7635f719ccb25294a7c135/config/cesm/machines/config_compilers.xml#L329-L338

and there are a couple of similar occurrences for E3SM (I haven't checked UFS).

It seems like what this is really trying to say is: If you're using `mpi-serial`, use X; for any other mpi library, use Y. If so, this logic is a bit wrong currently, and could get more wrong in the future, since it doesn't handle some values of MPILIB (e.g., I see the use of `intelmpi` on at least one machine).

It feels to me like we should introduce a derived xml variable like `MPI_IS_SERIAL`. This will be True if using `mpi-serial` and False for any other value of MPILIB. Then logic like the above could key off of `MPI_IS_SERIAL`, rather than trying to list out all allowed values of MPILIB. Then I think we could more accurately say that you can use any value you want for MPILIBS in a machine port, as long as you are self-consistent. **What do people think of this suggestion?**

Contributor guide

Open the contributing guide

Assessment

This issue has not been assessed yet.

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.