I edited the description to make it more generic. Many MCT-based apps could use this. We may add more functions over time.

There are less than 10 oasis routines using mct_mod. Feel free to rename it accordingly to CIME requirements, if needed, and OASIS will easily follow.

Another option would be: move your mct_mod.F90 to somewhere else in OASIS3-MCT ( such as /lib/psmile/src) and wait on introducing one in to MCT itself.

If we continue this PR with a slightly renamed module, it should include all the MCT routines in CIME: https://github.com/ESMCI/cime/blob/master/src/share/util/mct_mod.F90

@andreapiacentini let me know what you want to do (move the location of mct_mod in OASIS OR slightly rename it).

If renaming it, how about mctf_mod ? It's a selection of MCT functions. ? Or mctfunc_mod

mct_mod.F90 in oasis is based on the CESM one, although it may be slightly different in implementation.

If MCT is thinking about adding mct_mod.F90 to MCT, that's fine by me. I would propose it should NOT change names though as that would force both oasis and cesm to change all their "use" statements everywhere in their models which seems unnecessary.

On the other hand, a new name for mct_mod.F90 would allow oasis and cesm to migrate to the new file without breaking whatever is currently implemented. The old file could be kept around with the new file as needed. Although that has it's problems too.

One could also argue that since there are separate implementations of mct_mod.F90 in cesm and oasis and where that file lives is different locations in both models, it's best at this point to NOT include it in MCT. Since MCT is not longer being actively developed, I think this is also a very reasonable approach.

@andreapiacentini can you explain how this was going to simplify maintaining MCT within OASIS?

Hi, I must acknowledge that even if "MCT is not longer being actively developed", it is "wonderfully actively maintained" (thanks @rljacob) and this update of the autotools for new compilers represents a typical case of MCT sources update that has to be propagated to the applications using MCT.

I was testing things on my own (Xmas break) and I hoped that MCT could be taken as it comes from a git clone and blindly replace the mct sources in OASIS3-MCT (in case someone not expert - I am an example - should do it). A sort of hardcoded git submodule.

@apcraig is the reference for this task. There are possibly other adaptations on the OASIS side that would make all my speculations useless

@rljacob, just to clarify. The main thing we'd like to have for Oasis is the update to the configure tool for gnu10 (even though we have a workaround in place already). Otherwise, we're quite comfortable with the current MCT implementation. If you want to add an mct_mod.F90 file (with that name or similar) into the MCT source code, we may end up using it, but we obviously have our own version now. If you prefer to reject this PR, I think that's totally fine.

We update MCT in Oasis only every few years and the effort to do so is very low. We checkout MCT and then push it into our repository manually, adding the mct_mod.F90 file and maybe a couple other minor changes for Oasis. We are comfortable with the current process as well as it's cost.

Hi @rljacob and @apcraig
Since I initiated this PR, I can confirm that for me it can be rejected. No problem at all.
While fixing the autotools for gnu 10 we worked out the issue for intel oneAPI (the latest release of their GPU capable compilers). There's no workaround in OASIS for oneAPI, therefore the changes in MCT master have to be merged into OASIS.
@rljacob do you plan to tag the MCT master (in such a case we should wait for the tag) or can @apcraig merge the MCT master as it is in commit 5958972 ?
Thanks for everything
Andrea

Ok we'll close this PR for now. I may reopen it in the future.

Yes I'll be making a 2.11 tag but might take another week or so. You are free to put any hash you want in to OASIS.