Get ExtDataDriver.x running on tiles

[bena-nasa]

This allows ExtDataDriver.x to work on "tile" grids and create the locstream on an attached grid and then create 'tileonly' variables which is precursor to getting ExtData able to ingest tile data and retire MAPL_ReadForcing. This will allow me to develop without having to run the full model.

Unfortunately do to a bug or limitation (which has been reported to ESMF) when doing ESMF_FIeldCreate on grids with ESMF_USER_INDEX, I had to redo the "clone" function in the field operation utilities to have MAPL, if the grid has was created with ESMF_USER_INDEX, rather than ESMF allocate the memory, we do, which of course brings the ugly rank/type logic we want to avoid. I'm very sorry about this but until ESMF either fixes the bug or removes the limitation this is what we must do and the way it must be, it just is.

I also updated and moved the field destroy that takes advantage of the fact ESMF now can report who allocated the memory so that I can destroy these fields no matter who allocated the memory.

Description

Related Issue

Motivation and Context

How Has This Been Tested?

Types of changes

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to change)
• Trivial change (affects only documentation or cleanup)

Checklist:

• I have tested this change with a run of GEOSgcm (if non-trivial)
• I have added one of the required labels (0 diff, 0 diff trivial, 0 diff structural, non 0-diff)
• I have updated the CHANGELOG.md accordingly following the style of Keep a Changelog

[tclune]

Minor change requested. And some questions.

[bena-nasa]

Minor change requested. And some questions.

@tclune, turns out some external repos call "MAPL_FieldDestroy" so I should not have change the name to just "FieldDestroy", as I broke the public API which was causing the GEOSgcm build to fail.

[tclune]

Minor change requested. And some questions.

@tclune, turns out some external repos call "MAPL_FieldDestroy" so I should not have change the name to just "FieldDestroy", as I broke the public API which was causing the GEOSgcm build to fail.

OK - let's defer those kinds of changes until MAPL3. There we may use things like FieldDestroy internally, and then have a compatibility layer than uses rename to the explicit name.

I would hope destroying fields is very rare outside of MAPL though ...