Proposals for MATM replacement

[aidanheerdegen]

There is a proposal that COSIMA fund development of a replacement for MATM, which was never designed to support the range of input datasets that it is currently.

Please add what you functionality/features you would like to have in this code. If possible you could rate them in terms of priority.

[aidanheerdegen]

1. Universal binary for any size grid, i.e. allocatable arrays

[ScottWales]

What is the smallest interface you could get away with? Perhaps users only need to specify catalogue and start date:

atm Era-Interim 19600101

and this would set up the correct grids and just send the fields at every available time starting at the start date.

[aidanheerdegen]

I believe there is some staggering of forcing in some instances, but that is what I was hoping to get feedback about.

[aidanheerdegen]

Asynchronous data reads. MATM spends a lot of time waiting on other models but only reads the data when OASIS asks for it. It could read ahead and be waiting to broadcast the data as soon as requested.

[aidanheerdegen]

Use multiple ranks to read multiple fields simultaneously.

[marshallward]

Follow on last point, allow multiple ranks to send data to targets.

[marshallward]

Look into the possibility of replacing OASIS with explicit MCT calls. Also look at other options? (e.g. YAC)

[nichannah]

Provide a python interface to the coupling code. This would make adding support for new datasets a lot easier.

[nichannah]

I like the idea about async reads. We could remove the matm receive so that it blocks on a send, so is always ready. In this case it may make sense to out the interpolation on the matm side.

[nichannah]

Another +1 for using python is that we can avoid doing string, file, config and date handling in Fortran.

[aidanheerdegen]

I'm not sure about adding a dependency on python. Would this be optional, with the code written in FORTRAN with python bindings?

[ScottWales]

Since I like a challenge and have never worked with Python's Fortran bindings - https://github.com/ScottWales/pyoasis. It does successfully start oasis, though I've not added any coupling send functions. If you want to give it a go edit the oasis library path in setup.py and mpirun -n 1 python test_oasis.py from the test directory.

[nichannah]

Scott, this could be really useful!

Another thing. I probably goes without saying but we want good handling of failure cases. Presently MATM more or less fails silently and you're left wondering why the job is not progressing.

[ScottWales]

I've added partitions and variables to pyoasis. It's working fine for saving to a file with OUTPUT, and probably would work fine sending fields to another model. It can't create its own grids yet though so you would need external files for interpolation.

The basic setup is to define a variable and then register it with the Oasis class. The variable doesn't hold any data itself, a numpy array is passed to its put() method to be sent off to other components

with Oasis('test') as o:
    shape = (5,5)

    part = partition.Serial('default', shape[0]*shape[1])
    o.register(part)

    var = Variable('foo', part, shape, types.real, direction.out)
    o.register(var)
    o.enddef()

    data = np.zeros(shape, order='F')
    o.variable['foo'].put(0, data)

Does this api make sense? I'm starting off pretty simple, once the basics are in place you could imagine adding a richer api like adding put() and get() methods onto a numpy array.

[nichannah]

As part of work to better support for varying forcings I've been incorporating some of the suggestions made here. I am not doing a complete rewrite, more a refactor, in preparation for further changes down the track.

A key thing that I've fixed is the timestepping logic. It is now a lot simpler and, importantly, does forcing indexing/selection and timestamping using dates. I have to admit that I was emotionally driven to make this fix ... I was getting very frustrated with the number of date-based bugs that we have had recently. @aekiss has had at least two runs that went bad like this, e.g. we spent a few days struggling with ice buildup only to find that it was always winter.

[nichannah]

Another feature that is needed is good testing. It's too easy to make a change that inadvertently changes the forcing, which we almost never want to do.

[nichannah]

I think we're all in agreement that cmake is the preferred build tool going forward.