Chris,
Actually it’s not exactly clear why Hyrax is struggling to me either.
I can read the variable “ntimes” from the server if I stick with the DAP2 data
response:
curl
"http://ingria.coas.oregonstate.edu/opendap/ORWA/ocean_his_4226_27-Jul-2016.nc.dods?ntimes";
| getdap -D -M -
But when I ask for alternate encodings of the response, such as the ASCII
response:
curl
"http://ingria.coas.oregonstate.edu/opendap/ORWA/ocean_his_4226_27-Jul-2016.nc.ascii?ntimes”;
And the NetCDF fileout response:
curl
"http://ingria.coas.oregonstate.edu/opendap/ORWA/ocean_his_4226_27-Jul-2016.nc.nc?ntimes";
I get similar errors. (All of these work in the latest Hyrax server on my
system)
It appears that your milage may vary depending upon the requested response
encoding which may speak to the issues with the different clients.
This is surely a bug in Hyrax-1.9.0
Nathan
> On Oct 19, 2016, at 10:13 AM, Chris Barker <chris.barker@xxxxxxxx> wrote:
>
> Thanks for the great detective work Nathan!
>
> I'll work with the operator of the server to see if they can upgrade, or it,
> indeed, it's not longer needed.
>
> I'm still a bit confused (OK, totally confused) as to why we can access data
> from some variables with other libraries than netCDF4, though -- but it does
> seem to be a server error in any case.
>
> -CHB
>
>
> On Wed, Oct 19, 2016 at 9:31 AM, Nathan Potter <ndp@xxxxxxxxxxx> wrote:
>
>
> Chris et al.,
>
> I looked at this today and I’m pretty sure the problem had been resolved in
> the current version of Hyrax.
>
> Here’s what I did:
>
> 1) Retrieved the NcML file:
>
> curl
> "http://ingria.coas.oregonstate.edu/opendap/aggregation/ocean_time_aggregation.ncml”;
> > ota.ncml
>
> 2) Read the file and saw that the aggregation is formed by scanning a top
> level directory called /ORWA.
>
> <netcdf xmlns="http://www.unidata.ucar.edu/namespaces/netcdf/ncml-2.2";>
> <aggregation dimName="ocean_time" type="joinExisting" >
> <scan location="/ORWA/" suffix=".nc" subdirs=“false” />
> </aggregation>
>
>
>
> 3) Looked in that directory: http://ingria.coas.oregonstate.edu/opendap/ORWA/
>
> 4) Checked the DDS of the first file:
> http://ingria.coas.oregonstate.edu/opendap/ORWA/ocean_his_4226_27-Jul-2016.nc.dds
>
>
> 5) Tried to get data for variable “ntimes":
> http://ingria.coas.oregonstate.edu/opendap/ORWA/ocean_his_4226_27-Jul-2016.nc.ascii?ntimes
>
> This returns an error with an informative message:
>
> ##BESError##Type# 1##Message# libdap exception building response#
> error_code # #111# Failed to read data# Could not read the variable
> #ntimes####Administrator# admin#email#address#your#domain#name##
>
> Well, modulo the abundant # characters ;)
>
> This means that Hyrax can’t read the file (from which the aggregation is
> built) for some reason.
>
> 6) I downloaded the file:
>
> curl
> "http://ingria.coas.oregonstate.edu/opendap/ORWA/ocean_his_4226_27-Jul-2016.nc”;
> > ocean_his_4226_27-Jul-2016.nc
>
> 7) And dropped into into my current Hyrax and where I am able to retrieve the
> data:
>
> curl
> "http://localhost:8080/opendap/ingria/ocean_his_4226_27-Jul-2016.nc.ascii?ntimes";
> Dataset: ocean_his_4226_27-Jul-2016.nc
> ntimes, 2283930
>
>
>
> My suspicion is that the 1.9.0 server is linked to a very out of date version
> of the NetCDF-C library.
>
> Upgrade the server!
>
>
> Sincerely,
>
> Nathan
>
>
>
>
>
>
>
>
>
> > On Oct 19, 2016, at 8:46 AM, Chris Barker <chris.barker@xxxxxxxx> wrote:
> >
> > Thanks EMilio,
> >
> > I'll reach out to Alexandre.
> >
> > -Chris
> >
> >
> > On Wed, Oct 19, 2016 at 8:39 AM, Emilio Mayorga <emiliomayorga@xxxxxxxxx>
> > wrote:
> > Just to clarify, I made references to potential misconfigurations on the
> > hyrax server only b/c I saw statements to that effect in the previous
> > emails on this thread. I'm not in a position to make assessments myself.
> > And as I mentioned, NANOOS is also not in a real position to offer
> > significant changes to that hyrax server.
> >
> > Any recommendations to upgrade to a more recent version should be made
> > directly to the server maintainer; I don't remember her name, but the model
> > PI is Alexandre Kurapov, kurapov@xxxxxxxxxxxxxxxxxxxx. Please cc me.
> >
> > Also, Chris Barker replied separately saying that their needs our almost
> > always met by THREDDS servers, so he thought our operational and actively
> > maintained NANOOS THREDDS server may meet his needs. If the hyrax server in
> > question was in fact originally deployed only to meet NOAA ORR needs, and
> > those needs can now be met by our THREDDS server, the decision might be to
> > discontinue the hyrax server. But that'll be up to Alexandre.
> >
> > Cheers,
> > -Emilio
> >
> >
> > On Wed, Oct 19, 2016 at 5:34 AM, Nathan Potter <ndp@xxxxxxxxxxx> wrote:
> >
> > I would appreciate knowing what part of the behavior/output of the
> > ingria.coas.oregonstate.edu Hyrax server has led to the comments that it is
> > not configured correctly.
> >
> > - Is it simply that the server is producing an error when trying to
> > transmit the “ntimes” variable?
> > - Is there something specific in the NcML content that speaks directly to
> > this?
> > - In the context of this thread does “configuration problem/issue” mean an
> > improperly constructed NcML file?
> >
> > Can anyone provide some insight?
> >
> > By asking these questions I am trying to understand, and not in anyway
> > dispute, the assertion that the server is “misconfigured”. I just want to
> > tease apart the possibility that we are seeing a fundamental bug problem
> > from a configuration issue.
> >
> > I do know that at NASA’s request and expense a significant number of
> > changes and improvements have been made to Hyrax’s NcML features, but this
> > work happened long after the release of version 1.9.0.
> >
> > In light of this I think the first step should be to instigate upgrading
> > the server, as version 1.9.0 is a long way back and not only does the
> > latest release (1.13.1) offer an improved NcML implementation it also
> > contains numerous security updates.
> >
> > Regardless, any clarification that could be offered w.r.t. the
> > mis-configuration assertion would be very helpful to me.
> >
> >
> > Sincerely,
> >
> > Nathan
> >
> >
> >
> >
> > > On Oct 18, 2016, at 11:30 PM, Emilio Mayorga <emiliomayorga@xxxxxxxxx>
> > > wrote:
> > >
> > > I'm afraid I don't have much helpful insight to bring into this. The
> > > model behind that Hyrax server is indeed a NANOOS model, but the hyrax
> > > server itself was not set up and is not maintained by one of us in the
> > > NANOOS DMAC team. In fact, if I remember correctly the server is somewhat
> > > duplicative of a THREDDS server we do maintain for the same model output;
> > > it was setup about two years ago, I think to support an application at
> > > NOAA ORR that took advantage of some specific hyrax capability missing in
> > > THREDDS' OPeNDAP (Chris Barker would know better than me), partly through
> > > help and persuasion from Rich Signell; again, sketchy memory here. I was
> > > never thrilled with the idea of having a hyrax server in the mix when
> > > none of us had the capacity to invest in learning how to properly
> > > maintain it, and already had a THREDDS server for the same model. I'm not
> > > surprised to hear it's an old version, too.
> > >
> > > Sorry ...
> > >
> > > -Emilio
> > >
> > >
> > > On Mon, Oct 17, 2016 at 5:36 PM, Chris Barker <chris.barker@xxxxxxxx>
> > > wrote:
> > > Folks,
> > >
> > > I manged to do a tcpdump, and can (sortof) see what's going on -- though
> > > I can't really make sense of it -- maybe one of you can?
> > >
> > > This is running the enclosed script, to it first does the successful
> > > pydap request, then the unsuccessful netCDF4 request.
> > >
> > > (though it looking like this is a poorly configured server...)
> > >
> > > -CHB
> > >
> > >
> > > On Mon, Oct 17, 2016 at 4:49 PM, Nathan Potter <ndp@xxxxxxxxxxx> wrote:
> > > By which I meant - just deference the URL:
> > >
> > >
> > > http://ingria.coas.oregonstate.edu/opendap/aggregation/ocean_time_aggregation.ncml
> > >
> > > To get the NcML file:
> > >
> > > curl
> > > http://ingria.coas.oregonstate.edu/opendap/aggregation/ocean_time_aggregation.ncml
> > >
> > >
> > >
> > > Nathan
> > >
> > >
> > >
> > > > On Oct 17, 2016, at 4:37 PM, Nathan Potter <ndp@xxxxxxxxxxx> wrote:
> > > >
> > > > Hi,
> > > >
> > > > Seems like no one has tried to actually ask for the NcML file:
> > > >
> > > > http://ingria.coas.oregonstate.edu/opendap/aggregation/ocean_time_aggregation.ncml
> > > >
> > > >
> > > > N
> > > >
> > > >
> > > >> On Oct 17, 2016, at 4:35 PM, Roy Mendelssohn - NOAA Federal
> > > >> <roy.mendelssohn@xxxxxxxx> wrote:
> > > >>
> > > >> Hi Emilio:
> > > >>
> > > >> I believe this is a NaNOOS server. If you can read over the thread,,
> > > >> any insight would be appreciated, What is in the .ncml file could be
> > > >> of interest.
> > > >>
> > > >> Thanks,
> > > >>
> > > >> -roy
> > > >>
> > > >>> On Oct 17, 2016, at 4:20 PM, Chris Barker <Chris.Barker@xxxxxxxx>
> > > >>> wrote:
> > > >>>
> > > >>> On Mon, Oct 17, 2016 at 3:57 PM, Roy Mendelssohn - NOAA Federal
> > > >>> <roy.mendelssohn@xxxxxxxx> wrote:
> > > >>> I find that if you go to the html page, many of the variables at the
> > > >>> top can't be accessed requesting ascii, so there are clearly problems
> > > >>> with how this is set up
> > > >>>
> > > >>> that does point to server issues.
> > > >>>
> > > >>> I am wondering if these are defined in the .ncml. It would be
> > > >>> interesting to see what the .ncml file looks like.
> > > >>>
> > > >>> One thing to consider also is pydap does not call the C library IIRC,
> > > >>> it is a pure python implementation
> > > >>>
> > > >>> Exactly -- so it takes the netcdf C lib out of the picture -- which
> > > >>> means there is a protocol that pydap and hyrax are speaking that lets
> > > >>> the data be accessed...
> > > >>>
> > > >>> If anyone knows how to see what actual requests are being made by the
> > > >>> two, we might be able to figure out where the failure is...
> > > >>>
> > > >>> -CHB
> > > >>>
> > > >>>
> > > >>> -Roy
> > > >>>
> > > >>>> On Oct 17, 2016, at 3:33 PM, dmh@xxxxxxxx wrote:
> > > >>>>
> > > >>>> The difference with pydap is probably that you adding a constraint
> > > >>>> that is causing the server to ignore whatever variable
> > > >>>> is causing the problem. If you ask pydap for the whole
> > > >>>> dataset, does it fail?
> > > >>>> (e.g. something like:
> > > >>>> http://ingria.coas.oregonstate.edu/opendap/aggregation/ocean_time_aggregation.ncml.ascii
> > > >>>> =Dennis Heimbigner
> > > >>>> Unidata
> > > >>>>
> > > >>>> On 10/17/2016 4:16 PM, Chris Barker wrote:
> > > >>>>> On Mon, Oct 17, 2016 at 2:36 PM, dmh@xxxxxxxx <mailto:dmh@xxxxxxxx>
> > > >>>>> <dmh@xxxxxxxx <mailto:dmh@xxxxxxxx>> wrote:
> > > >>>>>
> > > >>>>> The log and show=fetch appear to not work under python
> > > >>>>> for some reason; stdout/stderr redirect?
> > > >>>>>
> > > >>>>>
> > > >>>>> I don't think so -- and I do get a lot of "Log:prefetch" messages,
> > > >>>>> so
> > > >>>>> stdout.stderr seems to be working.
> > > >>>>>
> > > >>>>>
> > > >>>>>
> > > >>>>>
> > > >>>>> In any case I can duplicate the error using wget e.g.
> > > >>>>> wget
> > > >>>>>
> > > >>>>> 'http://ingria.coas.oregonstate.edu:80/opendap/aggregation/ocean_time_aggregation.ncml.dods
> > > >>>>>
> > > >>>>> <http://ingria.coas.oregonstate.edu:80/opendap/aggregation/ocean_time_aggregation.ncml.dods>'
> > > >>>>>
> > > >>>>>
> > > >>>>>
> > > >>>>> hmm, I don't seem to have wget, but with curl, I get the below
> > > >>>>> results,
> > > >>>>> ending in:
> > > >>>>>
> > > >>>>> Data:
> > > >>>>>
> > > >>>>> Error {
> > > >>>>>
> > > >>>>> code = -111;
> > > >>>>>
> > > >>>>> message = "libdap error transmitting DataDDS: Could not read the
> > > >>>>> variable `ntimes'.";
> > > >>>>>
> > > >>>>> -- if that's the fatal error, then yup -- not the netcdf lib -- and
> > > >>>>> yet,
> > > >>>>> we can get the data with PyDAP, and if I put this:
> > > >>>>>
> > > >>>>>
> > > >>>>> http://ingria.coas.oregonstate.edu/opendap/aggregation/ocean_time_aggregation.ncml.ascii?u[0][0][0:10][0:10]
> > > >>>>>
> > > >>>>> into my browser, I do get data.
> > > >>>>>
> > > >>>>> I have asked this on support@xxxxxxxxxxx
> > > >>>>> <mailto:support@xxxxxxxxxxx> --
> > > >>>>> and they have pointed out that that is a pretty old version of
> > > >>>>> Hyrax --
> > > >>>>> _maybe_ that's the problem.
> > > >>>>>
> > > >>>>> -CHB
> > > >>>>>
> > > >>>>>
> > > >>>>> $ curl
> > > >>>>> 'http://ingria.coas.oregonstate.edu:80/opendap/aggregation/ocean_time_aggregation.ncml.dods'
> > > >>>>>
> > > >>>>> Dataset {
> > > >>>>>
> > > >>>>> Int32 ntimes;
> > > >>>>>
> > > >>>>> Int32 ndtfast;
> > > >>>>>
> > > >>>>> Float64 dt;
> > > >>>>>
> > > >>>>> Float64 dtfast;
> > > >>>>>
> > > >>>>> Float64 dstart;
> > > >>>>>
> > > >>>>> Int32 nHIS;
> > > >>>>>
> > > >>>>> Int32 ndefHIS;
> > > >>>>>
> > > >>>>> Int32 nRST;
> > > >>>>>
> > > >>>>> Int32 ntsAVG;
> > > >>>>>
> > > >>>>> Int32 nAVG;
> > > >>>>>
> > > >>>>> Int32 ndefAVG;
> > > >>>>>
> > > >>>>> Float64 Falpha;
> > > >>>>>
> > > >>>>> Float64 Fbeta;
> > > >>>>>
> > > >>>>> Float64 Fgamma;
> > > >>>>>
> > > >>>>> Float64 nl_tnu2[tracer = 2];
> > > >>>>>
> > > >>>>> Float64 nl_visc2;
> > > >>>>>
> > > >>>>> Float64 Akt_bak[tracer = 2];
> > > >>>>>
> > > >>>>> Float64 Akv_bak;
> > > >>>>>
> > > >>>>> Float64 Akk_bak;
> > > >>>>>
> > > >>>>> Float64 Akp_bak;
> > > >>>>>
> > > >>>>> Float64 rdrg;
> > > >>>>>
> > > >>>>> Float64 rdrg2;
> > > >>>>>
> > > >>>>> Float64 Zob;
> > > >>>>>
> > > >>>>> Float64 Zos;
> > > >>>>>
> > > >>>>> Float64 Znudg;
> > > >>>>>
> > > >>>>> Float64 M2nudg;
> > > >>>>>
> > > >>>>> Float64 M3nudg;
> > > >>>>>
> > > >>>>> Float64 Tnudg[tracer = 2];
> > > >>>>>
> > > >>>>> Float64 FSobc_in[boundary = 4];
> > > >>>>>
> > > >>>>> Float64 FSobc_out[boundary = 4];
> > > >>>>>
> > > >>>>> Float64 M2obc_in[boundary = 4];
> > > >>>>>
> > > >>>>> Float64 M2obc_out[boundary = 4];
> > > >>>>>
> > > >>>>> Float64 Tobc_in[boundary = 4][tracer = 2];
> > > >>>>>
> > > >>>>> Float64 Tobc_out[boundary = 4][tracer = 2];
> > > >>>>>
> > > >>>>> Float64 M3obc_in[boundary = 4];
> > > >>>>>
> > > >>>>> Float64 M3obc_out[boundary = 4];
> > > >>>>>
> > > >>>>> Float64 rho0;
> > > >>>>>
> > > >>>>> Float64 gamma2;
> > > >>>>>
> > > >>>>> Int32 LtracerSrc[tracer = 2];
> > > >>>>>
> > > >>>>> Int32 spherical;
> > > >>>>>
> > > >>>>> Float64 xl;
> > > >>>>>
> > > >>>>> Float64 el;
> > > >>>>>
> > > >>>>> Int32 Vtransform;
> > > >>>>>
> > > >>>>> Int32 Vstretching;
> > > >>>>>
> > > >>>>> Float64 theta_s;
> > > >>>>>
> > > >>>>> Float64 theta_b;
> > > >>>>>
> > > >>>>> Float64 Tcline;
> > > >>>>>
> > > >>>>> Float64 hc;
> > > >>>>>
> > > >>>>> Float64 s_rho[s_rho = 40];
> > > >>>>>
> > > >>>>> Float64 s_w[s_w = 41];
> > > >>>>>
> > > >>>>> Grid {
> > > >>>>>
> > > >>>>> Array:
> > > >>>>>
> > > >>>>> Float64 Cs_r[s_rho = 40];
> > > >>>>>
> > > >>>>> Maps:
> > > >>>>>
> > > >>>>> Float64 s_rho[s_rho = 40];
> > > >>>>>
> > > >>>>> } Cs_r;
> > > >>>>>
> > > >>>>> Grid {
> > > >>>>>
> > > >>>>> Array:
> > > >>>>>
> > > >>>>> Float64 Cs_w[s_w = 41];
> > > >>>>>
> > > >>>>> Maps:
> > > >>>>>
> > > >>>>> Float64 s_w[s_w = 41];
> > > >>>>>
> > > >>>>> } Cs_w;
> > > >>>>>
> > > >>>>> Float64 user[Nuser = 25];
> > > >>>>>
> > > >>>>> Float64 h[eta_rho = 522][xi_rho = 310];
> > > >>>>>
> > > >>>>> Float64 f[eta_rho = 522][xi_rho = 310];
> > > >>>>>
> > > >>>>> Float64 pm[eta_rho = 522][xi_rho = 310];
> > > >>>>>
> > > >>>>> Float64 pn[eta_rho = 522][xi_rho = 310];
> > > >>>>>
> > > >>>>> Float64 lon_rho[eta_rho = 522][xi_rho = 310];
> > > >>>>>
> > > >>>>> Float64 lat_rho[eta_rho = 522][xi_rho = 310];
> > > >>>>>
> > > >>>>> Float64 lon_u[eta_u = 522][xi_u = 309];
> > > >>>>>
> > > >>>>> Float64 lat_u[eta_u = 522][xi_u = 309];
> > > >>>>>
> > > >>>>> Float64 lon_v[eta_v = 521][xi_v = 310];
> > > >>>>>
> > > >>>>> Float64 lat_v[eta_v = 521][xi_v = 310];
> > > >>>>>
> > > >>>>> Float64 lon_psi[eta_psi = 521][xi_psi = 309];
> > > >>>>>
> > > >>>>> Float64 lat_psi[eta_psi = 521][xi_psi = 309];
> > > >>>>>
> > > >>>>> Float64 angle[eta_rho = 522][xi_rho = 310];
> > > >>>>>
> > > >>>>> Float64 mask_rho[eta_rho = 522][xi_rho = 310];
> > > >>>>>
> > > >>>>> Float64 mask_u[eta_u = 522][xi_u = 309];
> > > >>>>>
> > > >>>>> Float64 mask_v[eta_v = 521][xi_v = 310];
> > > >>>>>
> > > >>>>> Float64 mask_psi[eta_psi = 521][xi_psi = 309];
> > > >>>>>
> > > >>>>> Float64 ocean_time[ocean_time = 1026];
> > > >>>>>
> > > >>>>> Float32 zeta[ocean_time = 1026][eta_rho = 522][xi_rho = 310];
> > > >>>>>
> > > >>>>> Float32 ubar[ocean_time = 1026][eta_u = 522][xi_u = 309];
> > > >>>>>
> > > >>>>> Float32 vbar[ocean_time = 1026][eta_v = 521][xi_v = 310];
> > > >>>>>
> > > >>>>> Float32 u[ocean_time = 1026][s_rho = 40][eta_u = 522][xi_u = 309];
> > > >>>>>
> > > >>>>> Float32 v[ocean_time = 1026][s_rho = 40][eta_v = 521][xi_v = 310];
> > > >>>>>
> > > >>>>> Float32 w[ocean_time = 1026][s_w = 41][eta_rho = 522][xi_rho =
> > > >>>>> 310];
> > > >>>>>
> > > >>>>> Float32 temp[ocean_time = 1026][s_rho = 40][eta_rho = 522][xi_rho =
> > > >>>>> 310];
> > > >>>>>
> > > >>>>> Float32 salt[ocean_time = 1026][s_rho = 40][eta_rho = 522][xi_rho =
> > > >>>>> 310];
> > > >>>>>
> > > >>>>> Float32 AKv[ocean_time = 1026][s_w = 41][eta_rho = 522][xi_rho =
> > > >>>>> 310];
> > > >>>>>
> > > >>>>> Float32 AKt[ocean_time = 1026][s_w = 41][eta_rho = 522][xi_rho =
> > > >>>>> 310];
> > > >>>>>
> > > >>>>> Float32 AKs[ocean_time = 1026][s_w = 41][eta_rho = 522][xi_rho =
> > > >>>>> 310];
> > > >>>>>
> > > >>>>> Float32 tke[ocean_time = 1026][s_w = 41][eta_rho = 522][xi_rho =
> > > >>>>> 310];
> > > >>>>>
> > > >>>>> Float32 shflux[ocean_time = 1026][eta_rho = 522][xi_rho = 310];
> > > >>>>>
> > > >>>>> Float32 latent[ocean_time = 1026][eta_rho = 522][xi_rho = 310];
> > > >>>>>
> > > >>>>> Float32 sensible[ocean_time = 1026][eta_rho = 522][xi_rho = 310];
> > > >>>>>
> > > >>>>> Float32 lwrad[ocean_time = 1026][eta_rho = 522][xi_rho = 310];
> > > >>>>>
> > > >>>>> Float32 swrad[ocean_time = 1026][eta_rho = 522][xi_rho = 310];
> > > >>>>>
> > > >>>>> } ocean_time_aggregation.ncml;
> > > >>>>>
> > > >>>>> Data:
> > > >>>>>
> > > >>>>> Error {
> > > >>>>>
> > > >>>>> code = -111;
> > > >>>>>
> > > >>>>> message = "libdap error transmitting DataDDS: Could not read the
> > > >>>>> variable `ntimes'.";
> > > >>>>>
> > > >>>>> };
> > > >>>>>
> > > >>>>>
> > > >>>>> --
> > > >>>>>
> > > >>>>> Christopher Barker, Ph.D.
> > > >>>>> Oceanographer
> > > >>>>>
> > > >>>>> Emergency Response Division
> > > >>>>> NOAA/NOS/OR&R (206) 526-6959 voice
> > > >>>>> 7600 Sand Point Way NE (206) 526-6329 fax
> > > >>>>> Seattle, WA 98115 (206) 526-6317 main reception
> > > >>>>>
> > > >>>>> Chris.Barker@xxxxxxxx <mailto:Chris.Barker@xxxxxxxx>
> > > >>>>
> > > >>>> _______________________________________________
> > > >>>> NOTE: All exchanges posted to Unidata maintained email lists are
> > > >>>> recorded in the Unidata inquiry tracking system and made publicly
> > > >>>> available through the web. Users who post to any of the lists we
> > > >>>> maintain are reminded to remove any personal information that they
> > > >>>> do not want to be made public.
> > > >>>>
> > > >>>>
> > > >>>> netcdfgroup mailing list
> > > >>>> netcdfgroup@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
> > > >>> ***Note new address and phone***
> > > >>> 110 Shaffer Road
> > > >>> Santa Cruz, CA 95060
> > > >>> Phone: (831)-420-3666
> > > >>> Fax: (831) 420-3980
> > > >>> e-mail: Roy.Mendelssohn@xxxxxxxx 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.
> > > >>>
> > > >>>
> > > >>>
> > > >>>
> > > >>> --
> > > >>>
> > > >>> Christopher Barker, Ph.D.
> > > >>> Oceanographer
> > > >>>
> > > >>> Emergency Response Division
> > > >>> NOAA/NOS/OR&R (206) 526-6959 voice
> > > >>> 7600 Sand Point Way NE (206) 526-6329 fax
> > > >>> Seattle, WA 98115 (206) 526-6317 main reception
> > > >>>
> > > >>> Chris.Barker@xxxxxxxx
> > > >>
> > > >> **********************
> > > >> "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
> > > >> ***Note new address and phone***
> > > >> 110 Shaffer Road
> > > >> Santa Cruz, CA 95060
> > > >> Phone: (831)-420-3666
> > > >> Fax: (831) 420-3980
> > > >> e-mail: Roy.Mendelssohn@xxxxxxxx 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.
> > > >>
> > > >
> > > > = = =
> > > > Nathan Potter ndp at opendap.org
> > > > OPeNDAP, Inc. +1.541.231.3317
> > > >
> > >
> > > = = =
> > > Nathan Potter ndp at opendap.org
> > > OPeNDAP, Inc. +1.541.231.3317
> > >
> > >
> > >
> > >
> > > --
> > >
> > > Christopher Barker, Ph.D.
> > > Oceanographer
> > >
> > > Emergency Response Division
> > > NOAA/NOS/OR&R (206) 526-6959 voice
> > > 7600 Sand Point Way NE (206) 526-6329 fax
> > > Seattle, WA 98115 (206) 526-6317 main reception
> > >
> > > Chris.Barker@xxxxxxxx
> > >
> >
> > = = =
> > Nathan Potter ndp at opendap.org
> > OPeNDAP, Inc. +1.541.231.3317
> >
> >
> >
> >
> >
> > --
> >
> > Christopher Barker, Ph.D.
> > Oceanographer
> >
> > Emergency Response Division
> > NOAA/NOS/OR&R (206) 526-6959 voice
> > 7600 Sand Point Way NE (206) 526-6329 fax
> > Seattle, WA 98115 (206) 526-6317 main reception
> >
> > Chris.Barker@xxxxxxxx
>
> = = =
> Nathan Potter ndp at opendap.org
> OPeNDAP, Inc. +1.541.231.3317
>
>
>
>
> --
>
> Christopher Barker, Ph.D.
> Oceanographer
>
> Emergency Response Division
> NOAA/NOS/OR&R (206) 526-6959 voice
> 7600 Sand Point Way NE (206) 526-6329 fax
> Seattle, WA 98115 (206) 526-6317 main reception
>
> Chris.Barker@xxxxxxxx
= = =
Nathan Potter ndp at opendap.org
OPeNDAP, Inc. +1.541.231.3317
