[CF-metadata] CF convention for vector quantities

From: Bert Jagers <Bert.Jagers>
Date: Mon, 20 Mar 2006 09:24:44 +0100

Dear Jonathan,

Thank you for your reply.

> > "eastward_sea_water_velocity" and "northward_sea_water_velocity"
> etc.
>
> Unlike you, I think the association between pairs of quantities like this
is
> something which should reside in your application that processes the data,
and
> not in the data itself. This is for various reasons including
>
> (1) The components are generally regarded as different variables in models
and
> observational datasets. They are not always present in the same file. We
can't
> therefore introduce a general sea_water_velocity with the components as a
> dimension. This might sometimes work, but much data already exists which
is not
> written in this way, and data would continue to be written with components
> separated anyway. Hence your software could not depend on the association
being
> done for you in the file. You'd always need the ability to make the
> association yourself. If you have that ability, you can always use it.

I agree that there will be a large base of legacy files without the
attributes to indicate that component together form a vector quantity.
However, that does not mean that we shouldn't introduce some preferred
approach. Of course, always combining components together manually is an
option, but not user friendly if you need to draw vector plots on a regular
basis. I don't want to be asked everytime what components I want to combine
into a vector plot. So, you'll probably say: use a scripting or programming
language to do the standardised plotting. That is definitely an option
during the development phase of software, or for automatic reporting on the
results of operational models. However, for interactive inspection of data
from different sources that is a less favourable approach. In such cases,
little more than the automatic recognition of the quantities could be
programmed. And that is just what I want to do. You could say: use
conventions of your own. I don't like that, because then I would still be
faced with all kinds of application specific conventions if the program is
to be used for similar yet different simulation software that all advertise
as writing out netCDF files according to CF conventions.

> (2) The variables are systematically named already. You can derive an
northward
> from a eastward name easily, for instance, with s/eastward/northward/. One
> solution might be for your program to expect the user to specify the
vector
> quantity by the name of either of its components rather than generically.

My program works the other way around. You select a quantity and then you
press plot, instead of saying I want to plot a vector and this is my first
component and optionally a second component. Of course the user is also able
to compose a vector quantity of any two arbitrary scalar quantities. I just
don't like to force the user into using the latter approach for all vector
quantities from netCDF files in general.

> (3) Although the association between horizontal components of vectors is a
> common association that has to be made, it's by no means the only one, so
I'd
> argue it's not appropriate to make it a special case. Why should we not
also
> want to include the vertical component of a vector too?

Yes, vertical component should also be possible, of course. However, the
vertical name is not a trivial permutation of the horizontal names as
indicated by:

eastward_wind
northward_wind
upward_air_velocity

> Should we require stresses always to be supplied as 6- or 9-component
tensors?
> Should we require that large_scale and convective precipitation be stored
together?

Sorry, I don't think that I said anything about requiring files to define
vector quantities. Just thought that having some standardised way for
specifying that variables have a special relationship (in some sense similar
to the definition of vertical coordinate systems) would be useful. So, yes
that would also apply for tensors and maybe other quantities. However, it
should be optional, but in such a case relationships would not be
automatically be detected.

> > two other issues are related to this question:
> >
> > A) Distinction between components in east and north direction and
components
> > in the two grid directions: in which direction are the two components
> > defined? It seems that "sea_water_x_velocity" and "sea_water_y_velocity"
are
> > used for components in the grid direction although in local coordinate
> > systems x and y are generally associated with the two main coordinate
> > directions whereas the grid may be curvilinear. Most likely
> > "direction_of_sea_water_velocity" and "sea_water_speed" should form
together
> > a vector quantity. Central question: which types of vector components
are
> > needed?
>
> You're right, a vector might be represented as (eastward,northward), (x,y)
or
> (direction,speed). All of these are acceptable and might be in a file
together.
> I don't think that presents a difficulty - do you?

No, I don't have any problem with these definitions; they all have their
advantages. However, why is it

eastward_sea_water_velocity
northward_sea_water_velocity
(component naming at the start of the names)

sea_water_x_velocity
sea_water_y_velocity
(component naming at the end of the names)

sea_water_speed
direction_of_sea_water_velocity
(component naming mixed at start and end of the names)

They all combine with "upward_sea_water_velocity" as the vertical velocity
component. By the way, are these eularian or lagrangian velocities to be
precise? I.e. is the Stokes drift of waves included?

> > B) Staggering of data. The ROMS and Delft3D applications that we are
looking
> > at work both with staggered numerical schemes. So, in fact the two
velocity
> > components are provided at two different location sets. Before we can
deal
> > with these vector quantities correctly we need some standardization on
> > staggered data. I know there have been some preliminary discussions on
this
> > matter in the context of CF2, but what is a realistic time schedule for
> > these discussions to continue and settle?
>
> There are two timescales: (1) a few months for deciding the future
governance
> arrangements of CF. (2) finding time to do the thinking and make a
complete
> proposal. That depends on people volunteering to do it.

I am very interested in these developments if they set new standards within
a reasonable period and the more so if they have a relation with the ESMF
framework concepts and the XMDF format of USACE that have set standards for
staggered and unstructured grids. ...

Best regards,

Bert
Received on Mon Mar 20 2006 - 01:24:44 GMT