[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

19991214: most recent response from David Knight re: NLDN

Sandy,

Here are the messages I got from David Knight yesterday.  Contrary to
what I remembered, David notes in his second paragraph below that 'aspen'
"does alot of other processing that depends on system time", so 'aspen'
is not a candidate for NLDN Y2K testing.

He does say, however:  "I might be able to find another machine, change
its date, and give it an nldn feed if he thinks this would be useful".

I will blast David back a note asking for a machine on which we can
do the testing INCLUDING changing the date.

Tom

------- Forwarded Message

>From: "David J. Knight" <address@hidden>
>Subject: Re: 19991214: NLDN Y2K IDD header discussion (revived) (cont.)
>Organization: .
>Keywords: 199912141659.JAA03927


Hi Tom,

> 
> Sandy has been able to get the package to build.

Great. I didn't know that. I hadn't heard anything, and hadn't seen
nldntest account activity on aspen for quite some time. I noticed that
Sandy (or somebody using the nldntest account) had ftp'd the files back
to unidata so had some hope though.

There is a second NLDN feed going to ttyb on aspen.  Sandy could use
that feed for testing if he wants.  Unfortunately aspen does alot of
other processing that depends on system time, but, I might be able to
find another machine, change its date, and give it an nldn feed if he
thinks this would be useful.

> 
> >I can send you the bulk of that email that describes the various
> >processes again if you'd like.
> 
> This would be helpful for Sandy.

I'll do that momentarily

> 
> >As you know, we no longer have local expertise with this code or with
> >C++. Also since this an unsupported effort no funds were available to
> >hire a short term programmer to sort this our for us.
> 
> No problem.  We will be working on this.

Great. I'm *very* happy to hear that. It wasn't clear from you last
email. As I said I *think* it will work on Jan 1 but am grateful to
have somebody else look it over.


> >I see basically the following options at this point:
> 
> Us working on and fixing the code if needed?

That one sounds the best :)

> 
> Just when you had me feeling warm and fuzzy, you drop the bucket of
> ice water :-)

Yeah, sorry about that. I really do think it will probably work.
Certainly I have nothing to suggest that it will not (except general
public hysteria about this event)

> 
> >So here is my best guess, and what I hope, will happen Jan 1 when we
> >bring striker back up (all our machines are being shut down Dec 31
> >since the University is shutting down networking gear there is little
> >point in staying up, and, this provides additional protection should
> >something really strange happen jan 1). The nldn feed will start back
> >up, data will go out with yyjjjhh foremat where yy will be 00.
> 
> Given that the file name is created with the strftime function you list
> above, this is what I believe will happen.  Sandy's work should verify
> (refute) this AND give us a system that can be build/modified if/when
> needed.

This would be ideal! Thanks.


> I would rather have people change their patterns
> to something that would allow CCYY or YY.  This is, in fact, the
> pattern I send out with the ldm-mcidas decoders.  I like either of
> these names better than a file that is named YYYJJJHHMbMe.

I agree YYYY or YY is certainly better than YYY

> 
> 
> >I'm open to other suggestions as well.
> 
> A couple fo  things:
> 
> o we can make the annuncement; this gets the onus off of you
> o we will be looking at the code to make sure that it will keep
>   working
> 
> How does that sound?

That sounds good.

> 
> My note of yesterday was an attempt to not step on your toes in regards
> to how the products are named.  It was not meant to raise red flags or
> an indication that we are not going to work on this (several of your
> comments make it sound like you do not belive this).
> 

I wasn't sure exactly what you had in mind. I was concerned that you
might have planned to send out an email without knowing if the code was
going to continue working.

Frankly I don't care much whether we use yyyy or yy for the product
header. I have a slight preference for yy since that is what is
currently used, and we happen to file all our LDM files locally with
just yy. I guess there is no harm in having everybody use a pattern
that will match either yyyy or yy though (except it does make the
pattern a little more complicated). Since the code will have to be
changed to use yyyy I'll let you guys decide if you want to stick with
yy, or switch to yyyy.  Either is fine with me (one problem though, if
we match ccyy or yy I don't se an obvious way to file products in yy
should somebody choose to continue this).

Coincidently we are having a new dish and receiver installed today to
insure continued reciept of this data. It is turning into a lightning
heavy day ...

Thanks again, and sorry for the confusion on the status.
Later,
David
David Knight
Department of Earth and Atmospheric Sciences   Tel: (518)-442-4204
SUNYA   ES-228                                 Fax: (518)-442-4494
Albany, NY  12222                              Email: address@hidden


------- End of Forwarded Message

>From address@hidden  Tue Dec 14 10:04:09 1999

Tom,
here is that email again
David
----- Begin Included Message -----

From address@hidden Mon Jun 14 15:18:57 1999
Date: Mon, 14 Jun 1999 15:18:54 GMT
From: "David J. Knight" <address@hidden>
To: address@hidden
Subject: Re: 19990518: NLDN Y2K IDD header discussion


Hi Tom,
      Sorry it has taken me so long to get back to you about
this. I have good news and bad news. The good news is I think
I have sorted out what the various pieces of code do,
and located the source. The bad news it I can't get
any of it to compile!!!
      Needless to say this leaves me more than a little uncomfortable!
We're running 4 year old binaries with no way to recreate them
if required. Learning c, c++ has been on my list of things
to do for some time, but, I'm not likely to learn enough
of it to get this working any time soon.

We have set up an account on our machines for testing
of the nldn stuff. The username in nldntest nldn41
on aspen.atmos.albany.edu. You mentioned you'd like to
look at the code to check for y2k compliance. Perhaps
you'd also be willing to see if you can get it to compile
at all. I just don't know enough c or c++ to get anywhere
with it myself. Any help you can give in this area would
be *most* appreciated.

There are basically three processes involved.

1) ingest
   reads the data from the serial port and puts into raw files
   on disk. I believe the most current source is in 
   /home/nldntest/ingest/srcg++
   (I have tried hacking a little on this stuff, so, also
    put /home/nldntest/ingest.tar which includes the original stuff)

2) nldnldm
   This reads the raw file created by ingest. Creates 6 minute
   bins, then pqinserts in the ldm product queue
   Original source in nldnldm.tar, my crude attemps at
   hacking are in the nldnldn directory. Looks basically
   like a problem with the binning and gettimeofday stuff...

3) ldm
   distributes to other Universities.

I'm desperately hoping that Unidata sees enough value in
having this data provided to Universities (we serve 50+ now)
to help us get the code y2k compliant, and compilable.
We'll provide all the help and support we can at this end.

David

ps. below is an exchange of email I had with Ron that provides
some more details.

----- Begin Included Message -----

From address@hidden Thu May 27 12:33:11 1999
Date: Thu, 27 May 1999 08:33:04 -0400
From: "Ronald W. Henderson" <address@hidden>
X-Accept-Language: en
MIME-Version: 1.0
To: "David J. Knight" <address@hidden>
Subject: Re: NLDN LDM on striker
Content-Transfer-Encoding: 7bit

Dave:

Its been a while but I try to see if you are correct with you assessment:


"David J. Knight" wrote:

> Hi Ron,
>      We're finally sitting down and trying to sort out the nldn/ldm stuff on
> striker. Partly because Unidata wants to see if it will be y2k compliant,
> and partly because it has long been on my list of things to look into one
> day.
>
> I know it has been awhile, but am hoping you might be able to provide some
> information and assistance in this effort.
>
> I think I'm getting some handle on it. It seems there are three processes
> involved.
>
> ingest4.1.3 - which appears to read data from serial port and
>               write thunder_(date).flsx and thunder_(date).stax
>               files in /striker1/nldningestdata

This is written in C++ (I believe I did compile it under G++ though. Also
supports auto file change after a configured amount of flashes that have been
written..


>
>
> nldnldm     - appears to read the current data file being created
>               by ingest, then, separates out into flash bins
>               (maybe writes them in /striker1/nldnldmdata/binfiles)
>               It appears that nldnldm actually calls a few other
>               executables to do its work, finally calling a script
>               insertnldn which in turn calls nldnpqinsert to
>               insert data into the ldm product queue
>

I wrote this one. The program is commented fairly well. It also tracks the 
latest
files produced by the ingest program...



>
> ldm         - basically stock configuration that sends the data
>               to downstream sites and processes locally.

Your are familar with this program.. I thought this was just a script....

>
>
> Does this sound about right? Can you fill in any details?
>
> I think I've found the source for ingest4.1.3 in /home/rwh/src/ingest
>
> This appears to be very old code written mostly by Arsalon and Mitch using
> CenterLine CC (I wonder why this package instead of normal cc).
> I suspect this is based on (or may in fact be) the ingest code used
> by thunder to read serial port. I tried to recompile this code, but,
> of course enough has changed since it was written that it won't
> even compile using the existing Makefile. Do you think that GDS
> might be maintaining this code?

Should compile just fine using g++


>
>
> I also think I have found the source for the nldnldm stuff
> in /home/rwh/src/netcdf/nldn
>
> Based on the path name, I assume nldnldm puts the  data into
> netcdf format at some point? Again, this code will not compile
> with the Makefile. Since this stuff is probably at least partly
> based on Unidata software I'm hoping they will be able to help
> me sort this stuff out. Unfortunately I'm not very familiar with
> c, and, it could take awhile to learn enough to be able to
> sort out this code myself. But, I hate running binaries that
> I can't even recompile if needed!
>
> I know it has been awhile, and that you are probably busy,
> but any details you could fill in, or help you could provide
> would be greatly appreciated! I'm guessing you could probably
> update the code in an evening or so - maybe a consulting
> deal could be arranged.
>
> David
>
> p.s. If you decide to look at it you'll find the Centerline
> stuff has moved from /marx4 to /marx3 (we plan to mostly
> retire marx this summer)
>
> David Knight
> Department of Earth and Atmospheric Sciences   Tel: (518)-442-4204
> SUNYA   ES-228                                 Fax: (518)-442-4494
> Albany, NY  12222                              Email: address@hidden
>

--
             _ - - _       _ - - _
           .         .   .         .
         .             .             .  Ronald W. Henderson
        .             . .    ~ * ~    .  Chief Technology Officer
       .             .   .*        *   .  UNIFIED Technologies, Inc.
       .*            .  *.           * .  Rensselaer Technology Park
       .  *          .*  .            *.  105 Jordan Road
        .   *       * . .             .  Troy, N.Y. 12180
         .     "  "    .             .  (518) 283-1003 Phone
           .         .   .         .  (518) 283-1189 Fax
             -  _  -       -  _  -   address@hidden
--------------------------------------------------------------------


----- End Included Message -----



----- End Included Message -----