Remove ESMFIO.F90 once all of its multi-tile functionality can be reproduced through the documented I/O interface

[billsacks]

I sent this email:

Inspired by the conversation in ufs-community/ufs-weather-model#1765 and the poking around I did to try to answer that, I looked a bit through src/Superstructure/IOAPI/interface/ESMFIO.F90. It looks like this is an entirely different, undocumented I/O interface that Raffaele Montuoro wrote in 2018 to enable I/O of multi-tile Fields. Unlike most ESMF I/O, this does not go through PIO, but instead calls into netcdf directly. I haven't read through it carefully, but my guess is that the functionality of this module may now be superseded by the multi-tile I/O work I did for FieldWrite, FieldBundleWrite, etc.

Does anyone know more about this module – and specifically, whether it is indeed something that we can deprecate with the recent multi-tile I/O work?

In that same directory, I also see ESMF_IO.F90, which mostly consists of commented-out code, though has a few implemented things. So, while we're talking about this, any insights into that one?

No need for anyone to spend significant time looking into this or writing a reply... just curious if anyone knows anything that they can quickly share about this. We can also add it to the agenda for a future core team call if it would require a longer discussion.

Gerhard replied:

Without going back through the entire history of this, my recollection is indeed that this was work done to make multi-tile output work for UFS/FV3. It was never intended for broader usage, therefore not publicly documented - so we could remove easily in the future.

I agree that the way forward is to work on the FV3 side to see if the now multi-tile capable standard FieldWrite() and FieldBundleWrite() can be used instead of what's implemented in ESMFIO.F90. Once that has been shown to work, the ESMFIO.F90 implementation and API should be removed. The only area where I would expect potential issues is maybe with the attribute handling. Not sure how that is done with what is in ESMFIO.F90, and how FV3 might be using it, but I think it might be something to keep an eye on during this exercise.

As for ESMF_IO.F90, I would have to take a look to recall specifics, but in general, there were many attempts to add I/O capabilities in the past, and if something looks like it's completely disabled, it might well be outdated and probably should be cleaned up.

A few minutes to take a look at the core call might be good just to make sure.