Understanding unstructured grids (LFric) with Pointstat

[robdarvell]

We have been playing with the LFric unstructured grid files and Pointstat using Beta5 release. I have managed to set up a METplus wrapper and this runs successfully and produces a nice .mpr file with sensible numbers within it.
That is the good bit. Whatever forecast range (LEAD_SEQ) I specify within the wrapper, the correct LFric file is picked up eg: running for a valid time of 09th October @ 12Z for a T+12 forecast then it knows that it needs to be using the 00Z forecast file, but it always outputs just the T+0 forecast information from the particular file. (so if I ran for a T+0 forecast then all is good!)
I have been taking a look through the codebase, in particular ugrid_file.cc which does the reading of the netcdf file.
Having placed some extra lines of output in the code and recompiling I can see that the code is reading (for my example) in the 18 forecast ranges in the forecast file successfully and setting the correct time information up for them.
It was then in the section (line 766) where it was setting up which valid time to use where I became stuck as to what was going on and how it would work. The bit of code in question starts:
if(info->t_slot >= 0) valid_ut = ValidTime[a[info->t_slot]];
else valid_ut = ValidTime[0];
When running for different forecast ranges the info->t_slot is always set to 0 (in my case) and thus it is always using the first entry in the array. When looking at where t_slot is being defined, then it is in a section where the options could only be 0, 1, or 2 (as it is doing something with number of dimensions) so with say 18 forecast ranges being included you would never reach that far. (assuming my thinking of what that variable would represent is what it should be).
Then the InitTime isn’t ever set in this routine (section found in the other netcdf reading files isn’t in this code) so it is then just set to the valid time value. Then the subsequent lines just set the forecast period to be 0 as the InitTime is the same as the ValidTime.
If I do a bit of hardwiring in the code (to set the VT to the correct element in the time array eg: a LEAD_SEQ as 6 then the ValidTime array to 2 (stores 3hrly forecasts in file)) then it does read the correct forecast file elements by the looks of it and produces different numbers in the output files.
Is there a setting or something which I am not including or am I missing something obvious? I am not seeing at this point how the requested forecast range is getting into this part of the code to be able to match things up.

What I was not sure about is whether or not this falls into the ‘multiple times within the same file’ issue which has been fixed within Beta6, but couldn’t recall if that was MET or METplus.

Thanks very much
Rob

[DanielAdriaansen]

Hi @robdarvell! Thanks for following up after the meeting yesterday with more info. We're coordinating on testing the UGRID functionality with the LFric files we have and we'll get back to you around Tuesday of next week- a few folks are out until then that we need to coordinate with. Just wanted to give you a heads up on our plan.

[j-opatz]

Hi @robdarvell,

Dan and I were able to take a look at this yesterday afternoon and I think we have a simple solution to the issue you're currently experiencing.

If I could summarize the issue you're running into, it would be that when you run PointStat with your current configuration file, METplus only returns the 0th time index of the forecast input file, regardless of what the actual valid time is.

If that's a correct summary, the solution is to use the {valid} keyword in your levels forecast setting. This creates a dynamic entry to the level that will change each time the valid evaluation time changes, rather than a static one.

For example, your current configuration file might look something like

FCST_VAR1_NAME=u10m
FCST_VAR1_LEVELS=(*,*)

or

FCST_VAR1_NAME=u10m
FCST_VAR1_LEVELS=(0,*)

In either of these examples, METplus will only pull the first (0th) index of the input file each time, regardless of what the valid time is evaluating at. Using the * symbol for a time index isn't technically supported, and only through UGrid logic is it able to pull out the first index each time. In reality this should error out and inform you that * isn't supported in a time index.

Using the {valid} keyword means METplus will evaluate what the valid time is before looking through the input file; either directly (if you're using VALID_BEG, VALID_END) or indirectly (if you're using INIT_BEG, INIT_END, and LEAD_SEQ). For demonstration's sake, let's assume you're using INIT; you would set your forecast field information as follows:

FCST_VAR1_NAME=u10m
FCST_VAR1_LEVELS=({valid?fmt=%Y%m%d_%H},*)

With this setting, if you are currently at an INIT_TIME evaluation of 20210912_00 and your LEAD_SEQ is 6, METplus would have a level call that looks like

FCST_VAR1_LEVELS=(20210912_06,*)

and will find the corresponding index in the file for that time, assuming that the file's time variable is understood in MET.

I'll add that in a similar way, you can use the keyword {init} to dynamically set the time index based off of the initialization time. You can read more about this in the METplus wrappers documentation here. This feature was available since METplus coordinated release 5.0, so you should be OK to use it in METplus v6.0 beta5.

If you have any clarifications or additional questions on this, please let us know. A sample of the configuration file you're using and a test file may be helpful to demonstrate additional issues.

[robdarvell]

Many thanks for the reply and suggested way of attacking it. This seems to have got us further.
Does remind me to try and remember something moving forward. -> If I am using a different forecast netcdf file than one I am used to, try and remember to do an ncdump -h on it first to examine what is found within.

[robdarvell]

I will close this discussion now. Any further issues/discussion points can be raised later.

Rob