This archive contains answers to questions sent to Unidata support through mid-2025. Note that the archive is no longer being updated. We provide the archive for reference; many of the answers presented here remain technically correct, even if somewhat outdated. For the most up-to-date information on the use of NSF Unidata software and data services, please consult the Software Documentation first.
> John, > > OMG! The 4.1+ timeUnitsChange combo fixed it! I'm not even going > to try to figure out which one! ;-) > > Thanks!!!! party time most excellent! > > -Rich > > On Tue, Sep 29, 2009 at 7:45 PM, Rich Signell <address@hidden> wrote: > > John, > > > > We will soon go from 24 hour forecasts to 48 hour forecasts, so we'll > > want the FRMC. But it would be nice to have a "eliminate duplicate > > time values" from the joinExisting, for sure! > > > > I don't understand the FRMC behavior, however. There should not be any > > duplicate coordinate values for the 1st time value. (it only occurs > > once, in the first file in the FRMC). So why does it get a zero > > value? Is it because the dateFormatMark pulled from the filename > > does not match the 1st time value? its because there are 12 time steps in the first file and 13 in the second (at least with the files i was testing). timeUnitsChange = true forces the fmrc to read all the coordinates up front, which correctly deals with the problem. But I will try upgrading to 4.1 > > and adding the timeUnitsChange. I thought that only applied if the > > time units changed. Now why did I think that? ;-) yeah, its a kludge! Ticket Details =================== Ticket ID: YDW-329913 Department: Support THREDDS Priority: Critical Status: Closed