I agree with Karl's points. I'd recommend using the Gauss weights to
actually compute cell bounds as opposed to just including area weights in
the file. That's because the method of constructing cell bounds that are
consistent with the weights isn't all that obvious, and for applications
that do conservative regridding of a field between different grids, being
able to calculate the intersections of the cells in the two grids is an
essential part of the calculation, and cell bounds are required for it.
Brian
On Wed, Jun 27, 2007 at 10:46:22AM -0700, Karl Taylor wrote:
> Hi John and all,
>
> A couple of comments:
>
> I mentioned earlier that for a given spherical harmonic truncation the
> number of guassian latitudes and longitudes is not determined uniquely.
> As is noted in one of Brian's links,
> "The actual values of J and P (number of latitude and longitude grid
> cells) are often not set equal to the lower limit in order to allow use
> of more efficient transform programs." Perhaps this is a somewhat
> tangential point as far as CF is concerned.
>
> I don't see any major advantage to including the information that the
> grid is gaussian. I'm not sure why a user (or piece of software) would
> need to know this unless either the cell bounds and/or the cell areas
> were not included in the file, in which case the user could calculate
> these if he knew that it were a gaussian grid. It would be much easier
> for software to handle a variety of grids if for all of these the bounds
> were available, and the software didn't have to recognize lots of
> different types of grids.
>
> Note that the gaussian weights are conventionally defined as being
> proportional to the grid-cell area, but normalized to sum to 2.0 (or in
> some cases, I think, to 1.0). Thus, there seems to be no need to store
> the weights, when equivalently areas can already be stored.
>
> Karl
>
> John Caron wrote:
> > thanks Brian!
> >
> > would you also recommend storing the gaussian weights in the file? somehow otherwise documenting this?
> >
> > Brian Eaton wrote:
> >> Hi John,
> >>
> >> In order to construct latitude cell bounds so that the cell areas give
> >> identical integrals over the surface of a unit sphere to those that would
> >> be obtained by Gaussian integration, we do the following:
> >>
> >> Let phi(j), j = 1, nlat be the Gauss points ordered from S.P. to N.P.
> >>
> >> Let phi_bnd(j), j = 1, nlat+1 be the latitude cell edges which satisfy
> >>
> >> phi_bnd(j) < phi(j) < phi_bnd(j+1) for all j = 1, nlat
> >>
> >> and phi_bnd(1) = -pi/2, phi_bnd(nlat+1) = pi/2.
> >>
> >> Let gw(j), j = 1, nlat be the Gauss weights corresponding to Gauss points
> >> phi(j).
> >>
> >> In psuedo code:
> >>
> >> sin_phi_bnd(1) = -1.0
> >>
> >> do j = 1, nlat
> >>
> >> sin_phi_bnd(j+1) = sin_phi_bnd(j) + gw(j)
> >>
> >> end do
> >>
> >> Then compute corresponding latitudes by taking arc sine.
> >>
> >> Note that since sin_phi_bnd(1) = -1, and since the Gauss weights sum to
> >> 2.0, then sin_phi_bnd(nlat+1) will equal 1.0 to within the accuracy that
> >> the Gauss weights sum to 2.0. We generally set sin_phi_bnd(nlat+1) = 1.0
> >> and let the accumulated error in the sum of the Gauss weights (hopefully at
> >> the double precision roundoff level) be included in the last latitude cell.
> >>
> >> Brian
> >>
> >>
> >>
> >> On Tue, Jun 26, 2007 at 10:08:57AM -0600, John Caron wrote:
> >>> Hi Karl:
> >>>
> >>> Is there a standard way that the latitude bounds should be calculated that reflects the gaussian?
> >>>
> >>> If I do include the weights, sounds like I should include a description of how they were calculated. I used "the roots of the ordinary Legendre polynomial of degree NLAT using Newton's iteration method". Does that seem sufficient and useful?
> >>>
> >>> BTW, it appears you didnt send to list, so i forwarded.
> >>>
> >>> Karl Taylor wrote:
> >>>> Dear John,
> >>>>
> >>>> I think that CF doesn't bother identifying gaussian grids or weights as
> >>>> such, but simply stores the latitude values and the latitude bounds.
> >>>> This avoids the problem that there is no unique way of defining weights
> >>>> for a given spherical harmonic truncation (although conventionally
> >>>> nearly everyone does this in the same way).
> >>>>
> >>>> I hope someone will correct me if I've said anything incorrect.
> >>>>
> >>>> cheers,
> >>>> Karl
> >>>>
> >>>> John Caron wrote:
> >>>>> I dont see a standard for encoding gaussian weights for a gaussian
> >>>>> Latitude grid (eg GRIB GDS type 4 "Gaussian Lat/Lon"). Does this seem
> >>>>> needed? If so, any suggestions?
> >>>>> _______________________________________________
> >>>>> CF-metadata mailing list
> >>>>> CF-metadata at cgd.ucar.edu
> >>>>> http://www.cgd.ucar.edu/mailman/listinfo/cf-metadata
> >>>>>
> >>> _______________________________________________
> >>> CF-metadata mailing list
> >>> CF-metadata at cgd.ucar.edu
> >>> http://www.cgd.ucar.edu/mailman/listinfo/cf-metadata
> > _______________________________________________
> > CF-metadata mailing list
> > CF-metadata at cgd.ucar.edu
> > http://www.cgd.ucar.edu/mailman/listinfo/cf-metadata
> >
> _______________________________________________
> CF-metadata mailing list
> CF-metadata at cgd.ucar.edu
> http://www.cgd.ucar.edu/mailman/listinfo/cf-metadata
Received on Wed Jun 27 2007 - 12:08:32 BST
