Closed #314 via #317.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
That's good for me, thanks @JonathanGregory
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
I have updated the pull request
https://urldefense.us/v3/__https://github.com/cf-convention/cf-conventions/pull/317__;!!G2kpM7uM-TzIFchu!j5sMTufUekY0HbDkylC29GsZhOicrvn4eaiu8d7agPsFgB2NY8H-NKq-dNTw405OXfD2DYUwfRg$
to include the proposed deprecation text. If there are no further comments,
it
> Should we implement this change without the deprecation, and rely on Ethan's
> new issue #328 to take care of it later?
I was suggesting moving forward with the deprecation language for this issue
and revisiting it once item #328 comes to a conclusion. There are a few other
deprecation items
Thanks for your clarifications @JonathanGregory and @zklaus.
I think I've understood this more clearly now.
And I'm happy to say, I'm agreeing with what you are both saying !
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
I will reply to Klaus @zklaus in Ethan's new issue
https://urldefense.us/v3/__https://github.com/cf-convention/cf-conventions/issues/328__;!!G2kpM7uM-TzIFchu!ibQ4P3meoyrC9uwAd1iip77AQk67EcOV7rCcsNq4DIbGxVqkE4rDRfGMb24jQycKgNfma2--WjM$
--
You are receiving this because you are subscribed to
Should we implement this change without the deprecation, and rely on Ethan's
new issue
https://urldefense.us/v3/__https://github.com/cf-convention/cf-conventions/issues/328__;!!G2kpM7uM-TzIFchu!kH6ZExMv8GfrsQ1rwaFmv7R6TLZDF_DgB7U5nt79UJw9BKMrQV3U-Av7AYUE9TkeingvS3__8XI$
to take care of it
Hi all - The paragraph in the [rules
document](https://urldefense.us/v3/__https://cfconventions.org/rules.html__;!!G2kpM7uM-TzIFchu!ka812U3rXTGiXhFTJ9vi-8Qw_cLVDhuM3XUJIQUi2EWbPJthBpBBagU3XRf6sgpMrh4w-Uane_Q$
) that mentions deprecation seems focused on recent (or even the most recent)
> I would have thought that the the creation of all new CF-1.8 datasets should
> be deprecated.
Just listening in here + heard something that affects us, (i.e
Dear Jonathan,
Oh - what a difference a day makes!
Thanks for the text. I think it is fine, but it states that it is still OK to
produce CF-1.8 datasets if they don't contain this particular formula - is that
what we want? I would have thought that the the creation of all new CF-1.8
datasets
Dear @davidhassell
According to my computer, the 20th is tomorrow, but I expect you are thinking
ahead, or perhaps in Australia? :smile: Thank you for raising this point. I
suggest that we insert the following statement just after the title for the
"sigma over z" coordinate in Appendix D:
>
Hello - the 20th May is here, and no further comments have arisen. Thanks to
all for the interesting discussion - and especially to @johnwilkin for the
excellent diagrams.
Before we merge, however, it is noteworthy that this issue has identified and
corrected a fundamental flaw in the
Thank you, @JonathanGregory. It all looks good to me.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
Dear all
I have updated
https://urldefense.us/v3/__https://github.com/cf-convention/cf-conventions/pull/317__;!!G2kpM7uM-TzIFchu!hPr5vmxfnooIphvTSPP4gMo2T-kIe0SaA8_aEsA6ORgLciy51w8t2qam2s45X7wLDGnVjCThHaI$
again (at last, I'm beginning to feel that I know what I'm doing with git and
github!)
That sounds good to me, too.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
Yes, thanks, I agree with Klaus that we should deprecate it, so that a warning
is given by the checker. I think we should also check its value, because even
if deprecated it may be used by software. Jonathan
--
You are receiving this because you are subscribed to this thread.
Reply to this
Another option would be to declare `nsigma` deprecated. This way it would be
around for some time to come, but new data would avoid using it and it would be
clear that that is correct. In a future release, such backward-incompatible
changes could be bundled. For reference, I link here to [the
Dear @JonathanGregory - good points. Keeping `nsigma` is fine by me.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
Dear @davidhassell
I have changed the text about `nlayer` as you suggest. Thanks for the
correction.
I propose that we should keep `nsigma` because removing it would be
backward-incompatible, in the sense that existing data created with previous
versions of the convention would be invalid
Thanks, @JonathanGregory.
A couple of comments:
* Could we say "`nlayer` is the **size of the** dimension of the vertical
coordinate variable.", adding "size of the"
* Keeping an optional `nsigma` term variable does go against [Guiding Principle
Dear @johnwilkin and @davidhassell
I have updated the pull request
https://urldefense.us/v3/__https://github.com/cf-convention/cf-conventions/pull/317__;!!G2kpM7uM-TzIFchu!gNi1MQMOoR8izJVB0GwcJ1bjfo0kwnkOd8_806TceY2WwtttKyVAgm8MdPlN_VBGgbgOC1mDtAc$
. Is it OK now?
Thanks for your help
Dear @davidhassell and @johnwilkin
Thanks for your comments, and for the new diagram, John. Omitting the bounds is
a problem for many types of vertical coordinate variable, not just this one.
Bounds can be provided for both `sigma` and `zlev` in the usual way; the CF
convention has a special
> I am now quite troubled by the use nsigma, though! How it is applied is
> surely dependent on whether one assumes one-based or zero-base indices k, as
> @JonathanGregory pointed out. And the possibility of it becoming incorrect
> when the vertical dimension is subsetted is not good. These
Hello @johnwilkin and @JonathanGregory,
Thanks for these points.
I think that the use of the `positive` attribute to determine the direction is
sufficient and elegant - that works for me.
I am now quite troubled by the use `nsigma`, though! How it is applied is
surely dependent on whether
I think this suggestion is helpful. The sense of the numbering is readily
determined by diff(zlev) or diff(sigma). But if we have sigma dimensioned by
`nlayer`, do we need to enforce or recommend what sigma value to assign for
unused layers? In the case of numbering from the surface down, for k
Quoting my earlier comment
> The reason for putting missing data in the other is so that the data-reader
> or program can easily tell which way round (top down or bottom up) the levels
> have been arranged along the dimension.
There is another easy way to do this: we should be able to depend
Dear @johnwilkin
Thanks for your comment. I think `zlev` and `sigma` both have to be dimensioned
by `nlayer`, since they're formula terms of a coordinate variable of that
dimension. That's also implied by the text, since the same `k` is used to index
both of them. However, for any `k`, only
I don't think zlev should be _required_ to have missing values where they are
not _used_. A user might start with a solely z-based coordinate, say, zlev =
-5000 (k=1) by 500 to 0 (k=11) and c_depth=0 (or n_sigma=0) but subsequently
tinker with increasing values of c_depth and n_sigma. This eats
Dear @davidhassell
Thanks for raising this point. I agree with your suggestion (when we spoke)
that it would be better to *require* `sigma` and `zlev` to contain missing data
at levels to which they do not apply. In that case, if the first element `zlev`
contains missing data, or the first
Hello,
In the proposed text we have:
_The parameter `sigma(k)` is defined only for the `nsigma` layers nearest the
ocean surface, while `zlev(k)` is defined for the deeper layers. If the layers
are numbered top-down i.e. with `k = 1` nearest the surface and increasing
numbers for greater
Hello @JonathanGregory and @johnwilkin,
Thanks. The PR looks good to me, but I'd like to check it with my cf-python
implementation (or vice versa), and I won't be able to do that until after the
weekend, I will get back to you next week.
David
--
You are receiving this because you are
@johnwilkin, thanks for your comment on the pull request, which I repeat here
for the record:
> I think this will work OK. Regardless of how the modeler orders the k index
> it is a universal convention that sigma, or s, increases upward from -1 at
> the bottom (or of c_depth) to 0 at the sea
I have created pull request
https://urldefense.us/v3/__https://github.com/cf-convention/cf-conventions/pull/317__;!!G2kpM7uM-TzIFchu!n_1QRK0k0KXGcWD3Bz7KTim1SQmJbVCOt9UNuh2mXmurbB3365N63Yx0frz49vwxtnSv6Y9v_MU$
to implement this. If @johnwilkin and @davidhassell (who originally
discovered this
Dear @johnwilkin
Thanks. That's very helpful. Yes, I agree with you. `sigma` should be stored in
the file in a variable named by `formula_terms`, as `zlev` is. In fact that is
what Appendix D already specifies. It would be unnecessarily restrictive to
require the sigma levels to be equally
One more point ... working from sigma(k) encoded in the file would set the
scene to use ocean_s_coordinate or ocean_s_coordinate_g1 (g2) over z coordinate
with minimal added hassle.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on
We need auxiliary information for sigma(k) to make the definition generic.
Something like this ... check my math and whther it's < or <=
If k numbers from top to bottom then (left side of diagram attached)
for 1 < k <= Nsigmawe have sigma(k) = -k/Nsigma
Dear @johnwilkin
Thanks for you comment. Yes, that's good point. I think it's a separate
problem, but I agree the text should be reworded to avoid the implicit
numbering convention. In fact I don't think the numbering needs to be stated at
all. It could just describe the treatment of the sigma
I think there is a problem here with an implicit assumption about the numbering
convention for whether k=N is the surface or the bottom. In
ocean_sigma_coordinate is does not matter if a user numbers from the surface
sigma(1) = 0 to bottom sigma(N) = -1, or as in the ROMS model for example
38 matches
Mail list logo
