MetOffice / opsinputs

JEDI library generating VarObs and Cx files
BSD 3-Clause "New" or "Revised" License
4 stars 1 forks source link

Create UKV versions of varobs and CX namelists for sondes #148

Closed ctgh closed 1 year ago

ctgh commented 1 year ago

Create UKV versions of varobs and CX namelists for sondes.

Compared to the global case, the sonde UKV varobs file requires the extra fields 81, 82 and 83 (which are drift time, lat and lon).

The CX configuration is the same for the global and ukv cases. However, the ukv directory is referred to in the sith setup script, so it is useful to produce a separate file.

Also update the Varobs Writer to ensure output varobs profiles are the correct length.

Fixes #147

ctgh commented 1 year ago

@smnewman Thanks for your review! The addition of IC_PLevels to the signatures of two new functions mirrors what I already did for the function opsinputs_fill_fillelementtype2dfromsimulatedvariable_records.

The reason for passing IC_PLevels into these routines is because of the vertical grid staggering. There are 71 'rho' levels so I have to allocate 71 locations per profile when performing the averaging of each variable onto model levels. However, most variables only have 70 entries, and crucially the varobs output is expected to have 70 entries. By default, the opsinputs_fill_..._records functions use length of each record to allocate the varobs arrays, which meant that they had one more entry than desired. That led to problems when sending the output to VAR. Using IC_PLevels, which is fixed at 70, ensures that the varobs columns are the correct length.

The reason for extending the other two functions is that three new fields are added to the varobs file in the UKV case: level time, level latitude, and level longitude. These variables are processed with the newly-extended functions. Apart from that there is no difference between the global and UKV cases; both of them are treated in the same way by the opsinputs code.

This change can only affect data types that have been divided into records (i.e. sondes, ocean profiles, GNSSRO and maybe surfacecloud/geocloud). All other data types will be processed with the ..._norecords functions which are unchanged. In order to be on the safe side, I have added a yaml option called varobs_length_is_IC_PLevels. If that parameter is false (the default) then the existing record length will be used to allocate the varobs arrays. In other words the user will have to choose to use IC_PLevels instead. I'll have to update sith to use this parameter for the sonde yamls but that's not a problem.

I also added the internal variable VarobsLength in order to emphasise that it may not be equal to IC_PLevels. If VarobsLength is zero then the length of each varobs profile will be taken from the record length.

ctgh commented 1 year ago

Thanks for your reviews! I am going to merge now and will then update the sith sonde yaml to use the new configuration parameter.