FYI Guys,
The problem I referred to (at least for x-894,y=2020) appears to be
confined to timestep 99 and for depth layers 20-33. I grabbed what I could
and it is not a problem for me. The next file on my list was
http://tds.hycom.org/thredds/dodsC/GLBa0.08/expt_90.8/2011<http://tds.hycom.org/thredds/dodsC/GLBa0.08/expt_90.8/2011.html>
where again I want the same location. This file, for reasons that suggest
there is a problem, there are ONLY 6 TIMESTEPS and the same error
(OPeNDAP/netCDF Error code 1002) shows up in timestep 5.
I'll be grabbing as much of the data as I can from 2003-2012 and will let
you know if the problem crops elsewhere. I did the same exercise back in
March for other x,y cell not far away and encountered no issues then.
Not sure if that info will help,
Mick
On Tue, Jun 19, 2012 at 5:41 PM, Mick Spillane <mick.spillane@xxxxxxxx>wrote:
> Hi Roy,
> I am accessing the file using Ferret with the command
>
> use
> "http://tds.hycom.org/thredds/dodsC/GLBa0.08/expt_90.8/2010<http://tds.hycom.org/thredds/dodsC/GLBa0.08/expt_90.8/2010.html>
> "
>
> where this URL is from the web page
>
> http://tds.hycom.org/thredds/GLBa0.08/expt_90.8.html?dataset=GLBa0.08/expt_90.8/2010
>
> This mode of access from ferret implies (I believe) that I am accessing
> the netCDF version. I then define variables to point to one set of vertical
> profiles at x=894, y=2020 (and depth levels 1:32) then step in time writing
> U,V to a netCDF file that I will process later.
>
> This process typically works fine and it did for the entirety of another
> dataset in the same experiment and for this one until timestep 99 when the
> error message appeared. Jumping ahead to timestep 121 the process works
> from there to the end (step 365). I haven't yet determined when the good
> behavior resumes but strangely if I do an ASCII listing across the problem
> area (Z level by Z level) the numbers look recoverable.
>
> So from my point of view the problem is not huge and I can work around it
> with some effort. Hope this helps you track down the issue so it can be
> resolved for other users for whom a workaround is not an option.
>
> Thanks to both you and Nathan for the prompt response.
>
> Mick
>
> On Tue, Jun 19, 2012 at 5:24 PM, Roy Mendelssohn <roy.mendelssohn@xxxxxxxx
> > wrote:
>
>> Hi Mick:
>>
>> I don't know I can answer your question, but i know a little more info
>> would probably help.
>>
>> Is it correct to assume you are using the html page at
>> http://tds.hycom.org/thredds/dodsC/GLBa0.08/expt_90.8/2010.html? If so,
>> are you requesting binary or ascii format? Even more, can you copy the URL
>> that is created before you do the extract (in the "Data URL" box).
>>
>> What happens if you try two separate extracts, one for each component?
>>
>> Thanks.
>>
>> -Roy
>>
>> On Jun 19, 2012, at 5:14 PM, Nathan Potter wrote:
>>
>> >
>> >
>> > Mick,
>> >
>> > Looks like you're working with a THREDDS Data Server (TDS Version 4.2.9
>> - 20111108.1758). I'm cc'ing them on this because,well, it's their product.
>> >
>> > Good luck!
>> >
>> > Nathan
>> >
>> >
>> > On Jun 19, 2012, at 5:09 PM, Mick Spillane wrote:
>> >
>> >> While accessing U,V data at a single location (x=894, y=2020) from the
>> dataset
>> >> Data set:
>> http://tds.hycom.org/thredds/dodsC/GLBa0.08/expt_90.8/2010
>> >> the access proceeded smoothly until timestep 99 when the following
>> appeared:
>> >> **netCDF error
>> >> OPeNDAP Error: An internal error was encountered in
>> Vector.cc at line 627:
>> >> The server sent declarations and data with mismatched sizes.
>> >> Please report this to support@xxxxxxxxxxx
>> >> (OPeNDAP/netCDF Error code 1002)
>> >> Data set:
>> http://tds.hycom.org/thredds/dodsC/GLBa0.08/expt_90.8/2010
>> >> LIST/FORMAT=CDF/file=JapanAltSiteA_01Jan2010_31Dec2010.nc/app ua,va
>> >> Command file, command group, or REPEAT execution aborted
>> >>
>> >> The U variable for that timestep appears to be fine and V looks good
>> to depth cell 20 when the problem arises. The problem appears to be there
>> in the following days/timesteps -- how far I haven't yet determined.
>> >>
>> >> Hope this helps sort out the issue. If it gets fixed in the next
>> couple of days I'd appreciate a heads-up if that is possible. Otherwise
>> I'll figure a work-around or just avoid those days.
>> >>
>> >> Sincerely yours,
>> >> Mick Spillane
>> >
>> > = = =
>> > Nathan Potter ndp at opendap.org
>> > OPeNDAP, Inc. +1.541.231.3317
>> >
>> >
>> >
>> >
>> > _______________________________________________
>> > thredds mailing list
>> > thredds@xxxxxxxxxxxxxxxx
>> > For list information or to unsubscribe, visit:
>> http://www.unidata.ucar.edu/mailing_lists/
>>
>> **********************
>> "The contents of this message do not reflect any position of the U.S.
>> Government or NOAA."
>> **********************
>> Roy Mendelssohn
>> Supervisory Operations Research Analyst
>> NOAA/NMFS
>> Environmental Research Division
>> Southwest Fisheries Science Center
>> 1352 Lighthouse Avenue
>> Pacific Grove, CA 93950-2097
>>
>> e-mail: Roy.Mendelssohn@xxxxxxxx (Note new e-mail address)
>> voice: (831)-648-9029
>> fax: (831)-648-8440
>> www: http://www.pfeg.noaa.gov/
>>
>> "Old age and treachery will overcome youth and skill."
>> "From those who have been given much, much will be expected"
>> "the arc of the moral universe is long, but it bends toward justice" -MLK
>> Jr.
>>
>>
>
