Identify list of SOCA model variable names

[travissluka]

Description

Settle on a list of SOCA model variable names so that

1. we have different names for the input/output of our variable changes (linear and non-linear)
   ( i.e. balanced/unbalanced, rotated/unrotated, staggered/unstaggered.... and the various ice variable changes), to make it easier for the subsequent cleanup of existing variable changes, and the addition of the planned other variable changes this year.
2. It conforms to the model naming conventions being developed for JEDI

at the very least, if uocn didn't mean 5 different things, that would be nice!

No code / PR is expected to be created with this issue. This is just a discussion for us to settle on the list of names. Updating the variable names in the code will happen with subsequent issues.

[travissluka]

tagging @Dooruk @danholdaway @guillaumevernieres

As the starting point for what we currently use:
https://github.com/JCSDA-internal/soca/blob/develop/test/Data/fields_metadata.yml

• so within soca we use the name, (e.g. uocn, tocn)
• the variable passed to UFO are the getval name and getval name surface names (e.g. sea_surface_temperature)

Within the variable transforms of soca we'll need to stop using those uocn, tocn,... names and use the names that we come up with here

[Dooruk]

I would like to start working on this but we need to have some discussions first. I'm not sure where to start 😄

While pondering about the geostrophy code, I thought one thing we might need is to have interpolated vs. native variable distinction, something like uocn vs. uocn_c? With different names of course.

Would we need vertically integrated variables for now or in the future, something like u2d vs. u3d?

[shlyaeva]

It would be great if the names (returned to geovals, and passed to saber/vader) aligned with CCPP convention (adopted as JEDI model variable naming convention). We are in the process of identifying the correct names for the names already used across JEDI for other components as well. Tagging @svahl991 who is driving this process.

[travissluka]

@Dooruk I think the first step is to focus on the variables needed for the potential/insitu temperature conversion we want to do in VADER (I'm going to open a bunch of issues this week for what will be needed this quarter to get that to work. This week is the JCSDA planning week for this next quarter). The u/v staggered/unstaggered rotated/unrotated names seems like more of a headache to sort out at the moment.

For insitu/potential conversion we'll need the following variables, the first thing we should do is find an appropriate CCPP name for them (@svahl991 how would you prefer we proceed with this?):

• sea_water_potential_temperature
• sea_water_salinity
• sea_water_depth

(and while we're at it, we might as well find names for these as well)

• sea_surface_temperature
• sea_surface_salinity

We can then, later, find names for the rest of the variables we need. For reference, all of our variables are here
https://github.com/JCSDA-internal/soca/blob/develop/test/Data/fields_metadata.yml

[svahl991]

Recapping an in-person conversation here: Eventually the needed names will need to be added to CCPP via a pull-request if there is no adequate name already there. But if it will prevent rapid progress you can proceed with development using non-CCPP names, with the understanding that the names may need to change later if the names are not accepted as-is for the CCPP standard.