search

cmip6dr / CMIP6_DataRequest_VariableDefinitions

Definitions of variables in the CMIP6 Data Request
7 stars 0 forks source link

Correct inconsistencies with ocean overturning streamfunction variables #164

Closed durack1 closed 7 years ago

durack1 commented 7 years ago

@martinjuckes @taylor13 @SebastienDenvil @sherimickelson @jonathangregory, this issue relates to the definition of some variables within the Omon physics sheet

On 4/18/17, 5:40 AM, "martin.juckes" wrote:

    Hello Paul,

    we need to distingish between (1) msftmyz (ocean_meridional_overturning_mass_streamfunction), which is a function of latitude, model vertical coordinate and basin and (2) msftyyz (ocean_y_overturning_mass_streamfunction) which is a function of Y (not latitude), model vertical coordinate and basin (see section I6 of the OMIP GMD paper: http://www.geosci-model-dev.net/9/3231/2016/gmd-9-3231-2016.pdf).  Can we replace "Function of Y, Z, basin" and "Function of Y, rho, basin" with "Function of latitude, Z, basin" and "Function of latitude, rho, basin" for msftmyz, msftmzmpa, msftmrhompa,msftmzsmpa.

    There is an anomaly in the naming convention of msftmyz, msftyyz: the "mpa" and "smpa" versions of these variables (contributions to parameterised mesoscale advection and parameterised sub-mesoscale advection respectively) do have one "y" less, i.e. we have msftmzmpa and msftyzmpa. In msftmzmpa it is clear the "mz" stands for the meridional and vertical coordinates, but in msftmyz, which has the same coordinates, an extra "y" has been inserted. Can we reduce "msftmyz" and "msftyyz" to "msftmz" and "msftrhoz" for consistency?

    regards,
    Martin

    ________________________________________
    From: Durack, Paul J.
    Sent: 18 April 2017 02:30
    To: mickelso; Juckes, Martin (STFC,RAL,RALSP)
    Cc: CMIP6 Data Request
    Subject: Re: Version 1.00.06

    Hi Sheri and Martin,

    This information is obtained from the physics google sheet (https://goo.gl/Rhrcwp). I have amended the appropriate cells so that information for the variables:

    msftmyz, msftmrho, msftyyz, msftyrho, msftmzmpa, msftmrhompa, msftyzmpa, msftyrhompa, msftmzsmpa, msftyzsmpa (Omon, E44-E53)

    Now include all information relevant to the quantity, rather than referencing other cells (in the sheet). This should allow Martin to propagate the information from the source google sheet into the data request with little intervention.

    Thanks for raising this query, and please point out any other inconsistencies that should be fixed upstream.

    Cheers,

    P

    On 4/12/17, 3:45 AM, "CMIP6 Data Request on behalf of Martin Juckes" <CMIP6-DATAREQUEST> wrote:

    Hello Sheri,

    thanks for raising this.
    There are 7 variables with dimensions "latitude olevel basin time" and 4 with dimensions "latitude rho basin time" affected by this. I will put some more explicit information in the cell_methods string, and edit the processing attributes.

    regards,
    Martin

    ________________________________
    From: CMIP6 Data Request [CMIP6-DATAREQUEST] on behalf of Sheri Mickelson [mickelso]
    Sent: 10 April 2017 21:15
    To: CMIP6-DATAREQUEST
    Subject: Re: Version 1.00.06

    Hi Martin,

    Thank you for the new version of the Data Request.

    I was hoping that either you or someone else on the list could help out with a question I have. I noticed that there are about 9 variables on the Omon table that have 'Also see note above' in the 'processing' attribute. We are automating the digestion of the datarequest and in the process we lose the context of this comment. Do you know what the 'Also see note above' comment is referencing? And would it be possible to replace this for all of those variables with the note it is referring to?

    The variables I noticed where this occurs are:
    msftmrho, msftmrhompa, msftmzmpa, msftmzsmpa, msftmrho, msftyrhompa, msftyyz, msftyzmpa, and msftyzsmpa

    Thanks,
    Sheri

    On Mon, Apr 10, 2017 at 2:29 AM, Martin Juckes <martin.juckes> wrote:
    Dear All,

    a new version of the Data Request is now available,

    See the Data Request home page: https://earthsystemcog.org/projects/wip/CMIP6DataRequest,

    I'm sorry that the process is dragging on, but significant progess has been made in the last few weeks with the help of detailed feedback from several modeling centres.

    regards,
    Martin
durack1 commented 7 years ago

@martinjuckes I have corrected the erroneous information for the *meridional_overturning-* variables which include: msftmyz, msftmrho, msftyzmpa, msftyrhompa, msftmzsmpa, msftyzsmpa (Omon, E44-45, E48-49, E52-53: https://goo.gl/Rhrcwp). The identifier for each is now "function of latitude, Z, basin. For a model.." which replaced the erroneous "function of Y, Z, basin.."

durack1 commented 7 years ago

@martinjuckes regarding the naming consistency, there is some confusion in the requested new name:

There is an anomaly in the naming convention of msftmyz, msftyyz: the "mpa" and "smpa"
versions of these variables (contributions to parameterised mesoscale advection and
parameterised sub-mesoscale advection respectively) do have one "y" less, i.e. we
have msftmzmpa and msftyzmpa. In msftmzmpa it is clear the "mz" stands for the
meridional and vertical coordinates, but in msftmyz, which has the same coordinates,
an extra "y" has been inserted. Can we reduce "msftmyz" and "msftyyz" to "msftmz"
and "msftrhoz" for consistency?

All these discussions refer to variables contained in the physics google sheet: https://goo.gl/Rhrcwp

The "msftmyz" (Physics, Omon, F44) -> "msftmz" seems ok, however "msftyyz" (Physics, Omon, F46)->"msftrhoz" is incorrect.

The "msft" in the name refers to "mass streamfunction", with the "myz" in the first example (msftmyz) referring to "meridional, I agree a spurious y, and z (depth) coordinate". Following this logic, we could rename "msftyyz" -> "msftmrho" with the difference between "msftmz" and "msftmrho" the vertical coordinate

Are there any other inconsistencies that should also be considered?

martinjuckes commented 7 years ago

@durack1 Hello Paul, thanks for the updates ... but the instruction about "zig-zag" averaging only applies to the meriodional versions (msftm(y)z, msftmrho, msftmzmpa, msftmrhompa, msftmzsmpa), not the native coordinate versions (msftyz, msftyrho, msftyzmpa, msftyrhompa, msftyzsmpa). For the latter, we need something along the lines of "Function of Y, Z, basin. The average is taken along the model X-coordinate. When the model X-coordinate is longitude this variable should be omitted because it is identical to the meridional version of the variable". It would be nice to add the name of the corresponding meridional version for each version.

The text you have added says 'For a model with a cartesian latxlon grid, this is the same as the "Ocean Y Overturning Mass Streamfunction"': this is only true for "Ocean Meridional Mass Stream Function". For the "mpa" and "smpa" versions you need to adjust the text slightly.

martinjuckes commented 7 years ago

@durack1 Hello Paul, are you going to make the change "msftyyz" -> "msftmrho" which you refer to above?

durack1 commented 7 years ago

@StephenGriffies just trying to clean things up here, is it appropriate to undertake these renames: Ref sheet is Omon in https://goo.gl/Rhrcwp

msftmyz -> msftmz (Omon, F44) which is consistent with msftmzmpa and msftmzsmpa (Omon, F48, F52) msftyyz -> msftyz (Omon, F46) which is consistent with msftyzmpa and msftyzsmpa (Omon, F50, F53)

And with the *smpa variables did we need the *rho* equivalents of these to be added?

Are there any other outstanding issues?

StephenGriffies commented 7 years ago

Thanks @durack1 for the ping.

Yes to name changes: yes: msftmyz -> msftmz yes: msftyyz -> msftyz

No to adding new smpa variables. They need no rho* equivalents since the "smpa" diagnostics are in the mixed layer only. They are not of interest in rho-space.

durack1 commented 7 years ago

@martinjuckes @StephenGriffies those changes are now made, so this issue can now be closed.

The latest version of the google sheet can be obtained from https://goo.gl/Rhrcwp

durack1 commented 7 years ago

@martinjuckes a number of standing issues are now resolved in the revised sheet (https://goo.gl/Rhrcwp), I note that #156 still may need msftmrho and msftyrho to be added, I have queried @StephenGriffies on this.

Complete changes made include (these are documented in the "general" sheet at the link above)

I am awaiting the standard names to be finalised, and once these are done I can implement the changes and close #171. These are the only remaining OMIP issues that I am aware of.

ping @taylor13