(Towards #868) Metadata support for fields with nlayers and ndata

[arporter]

No description provided.

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 99.90%. Comparing base (6a32322) to head (e878688).

Additional details and impacted files

@@           Coverage Diff           @@
##           master    #3209   +/-   ##
=======================================
  Coverage   99.90%   99.90%           
=======================================
  Files         376      376           
  Lines       53149    53149           
=======================================
  Hits        53097    53097           
  Misses         52       52           

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[arporter]

Please could @TeranIvy and/or @tommbendall (or someone else?) take a look at the updated documentation that this PR introduces. Once we're happy with that, I'll proceed to implementation.

[arporter]

Tagging @stevemullerworth so he can join the fun too :-)

[stevemullerworth]

One of my changes (for multi-data fields) suggests a change to the implementation. The others are document changes only, I think.

[stevemullerworth]

I would suggest avoiding the idea that there is a particular model mesh. For example, we will have apps that regrid data from one number of levels to another.

Suggested change

	Typically, a field will have the same number of vertical layers as the
	model mesh. However, this is not a requirement and the number of layers
	can be as few as one (a 2D field).
	While an application may model a set of fields that all have the same number of
	vertical levels, this is not a requirement. An application may have fields on a range
	of different levels including fields on a single level (a 2D field).

[stevemullerworth]

I may be misunderstanding this. I am assuming it relates to a kernel which, for example, takes an argument which may be, say, an 70-level field but could be a 50-level or 40-level field. But the kernel should only set 40 levels (or fewer) of the field. Most typically, perhaps, it would be useful when setting the bottom level of a field of any number of levels.

Suggested change

	that is not the same as the extruded mesh then this must be specified using
	that may be different from the mesh of the input field then this must be specified using

[arporter]

I don't know what the use case is I'm afraid. However, when we discussed with Chris and Iva we were definitely talking about fields that did not have e.g. 70 levels because that then changed the values in the dof map. On the other hand, if all fields actually have the same number of levels but only populate a subset of them then all of their dofmaps will be identical (for a given FS). I think this needs clarification from @TeranIvy or @tommbendall?

[stevemullerworth]

For LFRic atmosphere, It would be useful to have the same flexibility for giving named values as is done for NLAYERS: in fact, it is more useful to have the flexibility here than for NLAYERS as there is less mixing and matching of layer numbers.

We have a lot of physics kernels with ~100 fields with a handful of multidata choices distinguished by ANY_DISCONTINUOUS_SPACE_1, ANY_DISCONTINUOUS_SPACE_2 etc. If they are converted to GH_RUNTIME we would need separate dofmaps etc. for each of the many fields rather than for each of the ANY_DISCONTINUOUS_SPACE choices. Example kernel here [MOSRS password protected]:

https://code.metoffice.gov.uk/trac/lfric_apps/browser/main/trunk/interfaces/physics_schemes_interface/source/kernel/bl_exp_kernel_mod.F90

[tommbendall]

Just commenting that I agree with this point! In fact I think the most common situation is that NDATA will be a runtime variable, but there might be many multidata fields being passed as arguments the same kernel, but all using the same NDATA value.

I'm not sure what the best solution to this is... because the NDATA values are science-related, I don't think we want any specific values hard-coded in arguments_mod.

Could we define a local variable for NDATA to take? e.g.

type(ndata_type) :: LAND_TILES
type(ndata_types) :: NUM_AEROSOLS

arg_type(GH_FIELD, GH_REAL, GH_READ, W2, NDATA=4)
type(arg_type) :: meta_args(4) = (/  &
     arg_type(GH_FIELD, GH_REAL, GH_READWRITE, W3),  &
     arg_type(GH_FIELD, GH_REAL, GH_READ,  W3, NDATA=LAND_TILES), &
     arg_type(GH_FIELD, GH_REAL, GH_READ,  WTHETA, NDATA=NUM_AEROSOLS), &
     arg_type(GH_FIELD, GH_REAL, GH_READ,  W3, NDATA=NUM_AEROSOLS)  &
/)

[stevemullerworth]

This is the sort of thing I had envisaged (though originally I was thinking of a direct but more meaningful replacement for ANY_*SPACE entries).

One of the challenges of moving away from ANY_DISCONTINUOUS_SPACE settings was deciding how and where to name scientifically-meaningful versions given that arguments_mod is in core. One could have a physics module to store them which would enable a common set to be used by several kernels.

I think they would need to be initialised so as not to cause any compiler warnings? If so, that's another reason for hiding them in a module.

[arporter]

Great, that's the same as I was imagining for NLAYERS so it's straightforward to do from a PSyclone point of view. I can see your issue with names in core and physics but I'll let you wrangle that :-)

[tommbendall]

Something else to consider that Tom M has just mentioned is that we have two types of multidata field. Those with ndata_first and those without. We may also need to capture that

[stevemullerworth]

Suggested change

	of layers which is not ``GH_RUNTIME`` then only one dofmap is passed to
	the kernel for those arguments.
	of layers which is not ``GH_RUNTIME`` then only one dofmap, the dofmap of the
	first field listed in the metadata, is passed to the kernel for those arguments.