I'm new to this forum and don't know if this is already answered. (I searched with the keyword "hyperslab", finding no hit.) The manpage ("man ncra") and the info ("info nco") have
[-d dim,[ min][,[ max]][,[ stride]]]
for ncra. This specification indicates that
ncra -d time, input.nc output.nc
should be accepted. Instead, I get this error
ncra: ERROR in hyperslab specification for dimension time,
Is this a bug?
What I want to achieve is to average over all timesteps. I've found the following seems to work:
ncra -d time,1, input.nc output.nc
I use the testing distribution of Debian GNU/Linux, for which NCO is Version: 3.9.0-1.2 .
Cheers,
Ryo
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
is valid syntax.
the first comma must be followed by something.
the default of ncra is to average over all timesteps so
you don't need any -d argument.
-d time,1,
misses the first timestep, i.e., timestep 0.
hope this helps,
charlie
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
1) To make the interface more consistent and intuitive, I'd like to propose that all the following be accepted:
-d time
-d time,
-d time,3
-d time,3,92
-d time,3,92,
-d time,3,92,2
For example, why reject "time," while accepting "time,1," ?
2) Until item 1 is implemented, the manpage and info should be fixed. Currently, both say
-d dim,[ min][,[ max]][,[ stride]]
which means that "-d time," is accepted.
3) "the default of ncra is to average over all timesteps so you don't need any -d argument. "---Thanks for pointing that out. (I suppose you mean that the default is over the record dimension. It's not necessarily time and it's not necessarily called "time".)
4) "-d time,1, misses the first timestep, i.e., timestep 0. "---Thanks again. I've been using Fortran for a long time and forgetting which convention NCO adopts (0-based or 1-based?).
Regarding (1) and (2), I'll submit a bug/wishlist report.
Regards,
Ryo
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
> For example, why reject "time," while accepting "time,1," ?
-d is for hyperslab specifications.
"time," does not specify a hyperslab.
"time,1," does (it eliminates the first timestep).
> -d dim,[ min][,[ max]][,[ stride]]
Yes, this is inaccurate/incomplete because the requirement
is that _at least one_ of min/max/stride must be present, i.e.,
the implemented syntax requires a cumbersome "or"-operator
notation to describe. That would sully the conciseness of the
documentation :)
The question is whether to change the implementation to accept
the syntax specified, as you suggest, or change the syntax spec.
to reflect the implementation? I'm ambivalent about which to do.
I have added the issue as TODO nco977.
Charlie
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
| > For example, why reject "time," while accepting "time,1," ?
|
| -d is for hyperslab specifications.
| "time," does not specify a hyperslab.
| "time,1," does (it eliminates the first timestep).
I think that depends on your perspective.
When you say "time,1," specifies a hyperslab, you implicitly
assume that
(1) Unspecified parameters take their respective default values.
According to this (implicit) rule, you assume
max = last record
stride = 1
for "time,1,".
Apply rule (1) to "time," and you'll get
min = 0
max = last record
stride = 1
and will conclude that "time," does specify a hyperslab,
which happens to cover the entire time axis.
This is what I meant by "consistent"; it's consistent
under rule (1).
| > -d dim,[ min][,[ max]][,[ stride]]
|
| Yes, this is inaccurate/incomplete because the requirement
| is that _at least one_ of min/max/stride must be present, i.e.,
| the implemented syntax requires a cumbersome "or"-operator
| notation to describe. That would sully the conciseness of the
| documentation :)
I'm sure you can write a one-line specification that describes
all possibilities. But, that would be hard for the user to read and
understand. Instead, you can write something along the lines
of this:
--- START: EXAMPLE ----
-d dim,min,max,stride
where you can omit any or all of min, max, and stride. Commas
can also be omitted if unambiguous. For example,
-d dim
-d dim,,max
-d dim,min,,stride
--- END: EXAMPLE ----
Regards,
Ryo
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hi there,
I'm new to this forum and don't know if this is already answered. (I searched with the keyword "hyperslab", finding no hit.) The manpage ("man ncra") and the info ("info nco") have
[-d dim,[ min][,[ max]][,[ stride]]]
for ncra. This specification indicates that
ncra -d time, input.nc output.nc
should be accepted. Instead, I get this error
ncra: ERROR in hyperslab specification for dimension time,
Is this a bug?
What I want to achieve is to average over all timesteps. I've found the following seems to work:
ncra -d time,1, input.nc output.nc
I use the testing distribution of Debian GNU/Linux, for which NCO is Version: 3.9.0-1.2 .
Cheers,
Ryo
-d time,
is invalid syntax while
-d time,,max
is valid syntax.
the first comma must be followed by something.
the default of ncra is to average over all timesteps so
you don't need any -d argument.
-d time,1,
misses the first timestep, i.e., timestep 0.
hope this helps,
charlie
Thank you for the response, Charlie.
1) To make the interface more consistent and intuitive, I'd like to propose that all the following be accepted:
-d time
-d time,
-d time,3
-d time,3,92
-d time,3,92,
-d time,3,92,2
For example, why reject "time," while accepting "time,1," ?
2) Until item 1 is implemented, the manpage and info should be fixed. Currently, both say
-d dim,[ min][,[ max]][,[ stride]]
which means that "-d time," is accepted.
3) "the default of ncra is to average over all timesteps so you don't need any -d argument. "---Thanks for pointing that out. (I suppose you mean that the default is over the record dimension. It's not necessarily time and it's not necessarily called "time".)
4) "-d time,1, misses the first timestep, i.e., timestep 0. "---Thanks again. I've been using Fortran for a long time and forgetting which convention NCO adopts (0-based or 1-based?).
Regarding (1) and (2), I'll submit a bug/wishlist report.
Regards,
Ryo
Ryo,
Thank you for your comments.
> For example, why reject "time," while accepting "time,1," ?
-d is for hyperslab specifications.
"time," does not specify a hyperslab.
"time,1," does (it eliminates the first timestep).
> -d dim,[ min][,[ max]][,[ stride]]
Yes, this is inaccurate/incomplete because the requirement
is that _at least one_ of min/max/stride must be present, i.e.,
the implemented syntax requires a cumbersome "or"-operator
notation to describe. That would sully the conciseness of the
documentation :)
The question is whether to change the implementation to accept
the syntax specified, as you suggest, or change the syntax spec.
to reflect the implementation? I'm ambivalent about which to do.
I have added the issue as TODO nco977.
Charlie
Hi Charlie,
Thank you for your message!
| > For example, why reject "time," while accepting "time,1," ?
|
| -d is for hyperslab specifications.
| "time," does not specify a hyperslab.
| "time,1," does (it eliminates the first timestep).
I think that depends on your perspective.
When you say "time,1," specifies a hyperslab, you implicitly
assume that
(1) Unspecified parameters take their respective default values.
According to this (implicit) rule, you assume
max = last record
stride = 1
for "time,1,".
Apply rule (1) to "time," and you'll get
min = 0
max = last record
stride = 1
and will conclude that "time," does specify a hyperslab,
which happens to cover the entire time axis.
This is what I meant by "consistent"; it's consistent
under rule (1).
So, I'm for accepting all of these
dim[,[min]][,]
dim,min,[max][,]
dim,[min],[max],[stride]
(I may have missed some possibilities.)
| > -d dim,[ min][,[ max]][,[ stride]]
|
| Yes, this is inaccurate/incomplete because the requirement
| is that _at least one_ of min/max/stride must be present, i.e.,
| the implemented syntax requires a cumbersome "or"-operator
| notation to describe. That would sully the conciseness of the
| documentation :)
I'm sure you can write a one-line specification that describes
all possibilities. But, that would be hard for the user to read and
understand. Instead, you can write something along the lines
of this:
--- START: EXAMPLE ----
-d dim,min,max,stride
where you can omit any or all of min, max, and stride. Commas
can also be omitted if unambiguous. For example,
-d dim
-d dim,,max
-d dim,min,,stride
--- END: EXAMPLE ----
Regards,
Ryo