Hi Folks
If I can summarise this rudely (with my reactions in brackets as):
- Bert suggested we should have a way of saying "these n variables form part
of a vector". (Sounds good)
- Jonathan suggested that this is a post processing issue (no), and that
vectorial relationships were simply a special case of associations (yes).
- Bert says: well, I still think we should do this (me too), but ok, I'll
introduce a configuration file (and loose any portability of the concept).
So I'm mainly with Bert on this one. I think
1) We should be able to label assocations between variables in a standardised
way and
2) We should be able to name those associations in a standardised way, and
3) both of those methods should be extensible (both in the standard, and by
the user - in the latter case I mean in the same way as a user can use a long
name if there is no standard name).
I think this would be a substantive change to CF, but one that would support a
lot of higher processing (and maybe help us with various irregular grid
issues we have coming, particularly if those relationships included the URIS
of external files). It would not break backwards capability in the sense that
the lack of relationships shoudl not be a problem. I do think this is
something the data producer should do. Bert has given some fine examples of
how a computer has no chance with our existing naming conventions.
Bert: can you come up with an appropriate methodology for doing this?
Bryan
On Monday 20 March 2006 10:18, Bert Jagers wrote:
> Dear Jonathan,
>
> > > My program works the other way around. You select a quantity and then
>
> you
>
> > > press plot
> >
> > If your program offers the user a list of what is in the file, or of
>
> stdnames
>
> > available, why can't it produce a vector plot whenever either of the
>
> components
>
> > is selected? Given one of them, the program can find the other easily.
>
> Yes, if the program has the right logic to find it. Because of the
> variations in the standard names, those names did not seem to me as a
> reliable means for automatic detection of vector quantities. Are there no
> quantities containing earthward and northward that do not form a vector
> quantity together (e.g. flux_through_grid_cell_face_in_x_direction and
> _y_direction) ?
>
> > > I don't think that I said anything about requiring files to define
> > > vector quantities.
> >
> > Quite right, you didn't. I had incorrectly assumed you were talking about
> > putting the component as a dimension, but actually you were talking about
> > taking it out of the standard name and putting it in a separate
> > attribute. However, I feel the same. Why should we make a special case
> > for this?
>
> There
>
> > are lots of ways the standard name could be factorised and associations
>
> that
>
> > can be made between sets of standard names. These associations are
>
> properties
>
> > of how you use the data, I think, than intrinsically of the data, so they
>
> are
>
> > the responsibility of the data-reader rather than the data-writer. I
> > don't see why the relationship between the components of a stress tensor
> > (six of them if it is symmetric) is less fundamental than the one you
> > point out.
>
> I would indeed support any request to handle stress tensor components in
> the same way as vector components (of course at surfaces you don't have all
> stress components). However, I do not completely agree with you that these
> associations are properties of the how you handle the data. When
> generically interpolating data from one mesh to another, you should be
> careful to treat vector quantities as such and not their components as
> independent scalars (this may be allowed for eastward and northward
> components given the right coordinate system, but isn't allowed for grid
> dependent x- and y-components and magnitude & direction pairs. In my
> opinion, being a vector quantity is most often a physical property not a
> postprocessing quantity (although there are also purely user dependent
> vector quantities that have no physical interpretation at all, e.g.
> (salinity,temperature), that may give useful plots and animations but are
> not based on any physical vector
> interpretation).
>
> The easiest way forward for me is to avoid the discussion and to introduce
> a configuration file that users can edit to support the vector quantities
> they want to use. Yet, I still think there is a reason for having a CF
> convention in order to be able to specify the vectorial relationship
> between variables.
>
> > > By the way, are these eularian or lagrangian velocities to be
> > > precise? I.e. is the Stokes drift of waves included?
> >
> > That precision hasn't been requested yet. If you have an application
> > where
>
> we
>
> > need to distinguish, please propose new names. We can accommodate names
>
> which
>
> > are more or less discriminating, appropriate for different users.
>
> I will check and propose new names.
>
> By the way: in case the naming convention "change_in_" is introduced it
> should probably require the user to specify its context (e.g. to what
> period it relates) otherwise such quantities are useless without further
> outside information.
>
> Best regards,
>
> Bert
>
> _______________________________________________
> CF-metadata mailing list
> CF-metadata at cgd.ucar.edu
> http://www.cgd.ucar.edu/mailman/listinfo/cf-metadata
--
Bryan Lawrence
Director of Environmental Archival and Associated Research
Head of the NCAS/British Atmospheric Data Centre
CCLRC, Rutherford Appleton Laboratory
Phone +44 1235 445012; Fax ... 5848; Web: home.badc.rl.ac.uk/lawrence
Received on Mon Mar 20 2006 - 06:55:42 GMT
