Menu

-d syntax

Ryo
2009-07-07
2013-10-17
  • Ryo

    Ryo - 2009-07-07

    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

     
    • Charlie Zender

      Charlie Zender - 2009-07-07

      -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

       
      • Ryo

        Ryo - 2009-07-07

        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

         
        • Charlie Zender

          Charlie Zender - 2009-07-08

          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

           
          • Ryo

            Ryo - 2009-07-08

            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

             

Log in to post a comment.

Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.