udf-dlm-develop

Re: [udf-dlm-develop] udf-dlm and archive

[Steve G. <ge...@ss...>]

>Good news. Martha helped me getting Archive Access running under IDL - the
>DLM works seamless with the archive software! I can highly recommend the
>Archive clinet-server approach, it makes downloading data a non-issue.
>This is certainly a feature which shines.

Good.   We'll give it a try here.

You could put out some FUV data which we don't have stored.
Try 1999339, 2000013 or 2000015.

As I understand it, we have to put your machine into a
file here, and perhaps enable the "promote" function.

With that done, Harald should be able to run an IDL/DLM program
here, ask for data from 1999/339, and UDF will go get it from your
server.  I better go back and read Chris's documentation.

[udf-dlm-develop] udf-dlm and archive

[Joerg-Micha J. <jm...@Or...>]

Good news. Martha helped me getting Archive Access running under IDL - the
DLM works seamless with the archive software! I can highly recommend the
Archive clinet-server approach, it makes downloading data a non-issue.
This is certainly a feature which shines.

Joerg-Micha



+-------------------------------------------------------------------------+
   Jörg-Micha Jahn, Ph.D.

   Space Science Department               Phone:   (210) 522-2491
   Southwest Research Institute           FAX:     (210) 520-9935
   6220 Culebra Road                      E-mail:  jm...@sw...
   San Antonio, TX 78238-5166, USA        
+-------------------------------------------------------------------------+

[udf-dlm-develop] RE: udf-dlm-develop digest, Vol 1 #23 - 1 msg

[Kusterer, M. <Mar...@jh...>]

Jörg-Micha,
I got the autopromote to work on both Unix and Linux. Currently I have the
archive resting on Linux box and it will promote to both Unix and Linux
databases correctly. 

Pardon me if I ask you stuff that you already checked. Did you set the env
UDFPROMOTE=1 or 2? Is the /UDF/TOOLS/bin/Server job running? Did you check
the archive database that the data is really in it? Did you check the local
database that the data you want to promote is not already in it? I used 

dBList HENA.HD.DBF

to check the archive. and dBAsk to check the local database.

Are the files that you are using good? I had a bad, old file that I was
trying to promote and it would plot it with the TclTK software but it
wouldn't work with the Archive.

If I can think of anything else I will send it on also. Good Luck!

Martha

> -----Original Message-----
> From:	udf...@li...
> [SMTP:udf...@li...]
> Sent:	Thursday, March 30, 2000 3:03 PM
> To:	udf...@li...
> Subject:	udf-dlm-develop digest, Vol 1 #23 - 1 msg
> 
> 
> Send udf-dlm-develop mailing list submissions to
> 	udf...@li...
> 
> To subscribe or unsubscribe via the web, visit
> 	http://lists.sourceforge.net/mailman/listinfo/udf-dlm-develop
> or, via email, send a message with subject or body 'help' to
> 	udf...@li...
> You can reach the person managing the list at
> 	udf...@li...
> 
> When replying, please edit your Subject line so it is more specific than
> "Re: Contents of udf-dlm-develop digest..."
> 
> 
> Today's Topics:
> 
>   1. UDF-DLM AutoPromote (Joerg-Micha Jahn)
> 
> --__--__--
> 
> Message: 1
> Date: Thu, 30 Mar 2000 09:34:20 -0600 (EST)
> From: Joerg-Micha Jahn <jm...@Or...>
> To: udf...@li...
> Subject: [udf-dlm-develop] UDF-DLM AutoPromote
> Reply-To: udf...@li...
> 
> 
> 
> I am currently testing Chris Gurgiolo's UDF Archive server which allows
> autopromote of data (i.e. if you request data not locally available, the
> software will go out, retrieve the data, and install it locally - all this
> w/o extra user action).
> 
> As soon as the data server is running on pluto (all I am waiting for is
> that the sysadmin people create the appropriate accounts), this will be
> made available for testing from remote sites.
> 
> I wanted to let you know, however, that the autopromote feature appears 
> not yet to work using the dlm (Martha, did you get it to work at APL?). I
> will get input from Chris as to how he has done it in UDF, and pass the
> information along to others. It's a useful feature which should be
> incorporated. I realize that people can only attack that once a data
> archive server is available to the public.
> 
> Jörg-Micha
> 
> 
> 
> +-------------------------------------------------------------------------
> +
>    Jörg-Micha Jahn, Ph.D.
> 
>    Space Science Department               Phone:   (210) 522-2491
>    Southwest Research Institute           FAX:     (210) 520-9935
>    6220 Culebra Road                      E-mail:  jm...@sw...
>    San Antonio, TX 78238-5166, USA        
> +-------------------------------------------------------------------------
> +
> 
> 
> 
> 
> 
> 
> --__--__--
> 
> _______________________________________________
> udf-dlm-develop mailing list
> udf...@li...
> http://lists.sourceforge.net/mailman/listinfo/udf-dlm-develop
> 
> 
> End of udf-dlm-develop Digest

[udf-dlm-develop] UDF-DLM AutoPromote

[Joerg-Micha J. <jm...@Or...>]

I am currently testing Chris Gurgiolo's UDF Archive server which allows
autopromote of data (i.e. if you request data not locally available, the
software will go out, retrieve the data, and install it locally - all this
w/o extra user action).

As soon as the data server is running on pluto (all I am waiting for is
that the sysadmin people create the appropriate accounts), this will be
made available for testing from remote sites.

I wanted to let you know, however, that the autopromote feature appears 
not yet to work using the dlm (Martha, did you get it to work at APL?). I
will get input from Chris as to how he has done it in UDF, and pass the
information along to others. It's a useful feature which should be
incorporated. I realize that people can only attack that once a data
archive server is available to the public.

Jörg-Micha



+-------------------------------------------------------------------------+
   Jörg-Micha Jahn, Ph.D.

   Space Science Department               Phone:   (210) 522-2491
   Southwest Research Institute           FAX:     (210) 520-9935
   6220 Culebra Road                      E-mail:  jm...@sw...
   San Antonio, TX 78238-5166, USA        
+-------------------------------------------------------------------------+

RE: [udf-dlm-develop] question on setting IDL_DLM_PATH

[Sahm, S. <ss...@se...>]

Hi Martha,

I put the files on our anonymous site at:

fusion.sec.noaa.gov

cd /pub/image

I hope this works!

Susan

[udf-dlm-develop] version 0.53

[Harald F. <hf...@ap...>]

Hi all,

As I was the person mostly complaining about the problem with jumping around in 
time and getting errors, I have to give my statement about the new version of 
the IDL-DLM interface.

I ran the new version with all my programs and many times in a row, and I could 
not produce a new core dump or segmentation fault. It is my opinion, that this 
problem is solved now.

So let's head for the others.

Harald


=========================================================
Harald U. Frey 
Space Sciences Lab	   phone: 510-643-3323
University of California   fax:   510-643-2624      
Berkeley, CA 94720-7450    email: hf...@ss...

Re: [udf-dlm-develop] Found it!!!

[Steve G. <ge...@ss...>]

I wrote a C program to do the same UDF reads that Harald
did, and it appeared to work.  So the problem is probably
not within UDF itself.

RE: [udf-dlm-develop] Found it!!!

[Sahm, S. <ss...@se...>]

Congratulations!!! Now you'll really have a good weekend!
Susan

-----Original Message-----
From: Harald Frey [mailto:hf...@ap...]
Sent: Friday, February 04, 2000 12:05 PM
To: udf...@li...
Subject: [udf-dlm-develop] Found it!!!


The "nasty problem" became a "Question of Honor" and I traced it down to the

source. The whole problem occurs, if you open a UDF file and don't(!) read
to 
the end of it, so that udf_eof(fh) does not become 1.

I have attached an IDL program, which shows this behavior. In the first
round I 
open three files and read all data to their end. In the second round I open
the 
files, but read only one record at the beginning of the file. And then the 
sequence crashes, when I try to access a file with later data. The same
happens 
if I don't read anything but only open and close the files.

This is my log of the attached program

IDL> test_udf_dlm
% Loaded DLM: UDF.
Starttime, stoptime
    1999     337       7      21      11     530
    1999     337       7      27      21     538
Starttime, stoptime
    1999     186       1      42      16     686
    1999     186       2      56      26     798
Starttime, stoptime
    1999     189      12      54       5     447
    1999     189      18      52      15     730
   
We repeat the previous sequence but read only one record
   
Starttime, stoptime
    1999     337       7      21      11     530
    1999     337       7      21      11     530
Starttime, stoptime
    1999     186       1      42      16     686
    1999     186       1      42      16     686
Starttime, stoptime
    1999     189      12      54       5     447
    1999     189      12      54       5     447
% UDF_OPEN: no data for this time period
% Execution halted at:  TEST_UDF_DLM       70 
/disks/sprite/disk1/hfrey/idl/image/dlm/udf-dlm-0.52/test_udf_dlm.
  pro
%                       $MAIN$                 
% Program caused arithmetic error: Floating overflow

Harald

=========================================================
Harald U. Frey 
Space Sciences Lab	   phone: 510-643-3323
University of California   fax:   510-643-2624      
Berkeley, CA 94720-7450    email: hf...@ss...



_______________________________________________
udf-dlm-develop mailing list
udf...@li...
http://lists.sourceforge.net/mailman/listinfo/udf-dlm-develop

[udf-dlm-develop] Found it!!!

[Harald F. <hf...@ap...>]

The "nasty problem" became a "Question of Honor" and I traced it down to the 
source. The whole problem occurs, if you open a UDF file and don't(!) read to 
the end of it, so that udf_eof(fh) does not become 1.

I have attached an IDL program, which shows this behavior. In the first round I 
open three files and read all data to their end. In the second round I open the 
files, but read only one record at the beginning of the file. And then the 
sequence crashes, when I try to access a file with later data. The same happens 
if I don't read anything but only open and close the files.

This is my log of the attached program

IDL> test_udf_dlm
% Loaded DLM: UDF.
Starttime, stoptime
    1999     337       7      21      11     530
    1999     337       7      27      21     538
Starttime, stoptime
    1999     186       1      42      16     686
    1999     186       2      56      26     798
Starttime, stoptime
    1999     189      12      54       5     447
    1999     189      18      52      15     730
   
We repeat the previous sequence but read only one record
   
Starttime, stoptime
    1999     337       7      21      11     530
    1999     337       7      21      11     530
Starttime, stoptime
    1999     186       1      42      16     686
    1999     186       1      42      16     686
Starttime, stoptime
    1999     189      12      54       5     447
    1999     189      12      54       5     447
% UDF_OPEN: no data for this time period
% Execution halted at:  TEST_UDF_DLM       70 
/disks/sprite/disk1/hfrey/idl/image/dlm/udf-dlm-0.52/test_udf_dlm.
  pro
%                       $MAIN$                 
% Program caused arithmetic error: Floating overflow

Harald

=========================================================
Harald U. Frey 
Space Sciences Lab	   phone: 510-643-3323
University of California   fax:   510-643-2624      
Berkeley, CA 94720-7450    email: hf...@ss...

Re: [udf-dlm-develop] nasty problem 2.

[Steve G. <ge...@ss...>]

Ed, please find the entire FUV UDF tree available
on our ftp site:

  ftp: sprite.ssl.berkeley.edu
  user: anonymous
  pass: whatever
  cd pub/image
  bin
  get fuvtree.tar.gz

I'm still working on the new FUV VIDFs and PIDFs.
I'll send those too when I'm done.

For now, the VIDF and PIDFs you have should be
OK for studying Harald's problem.

Re: [udf-dlm-develop] nasty problem 2.

[Ed S. <es...@la...>]

Harald,

I give up for tonight.  I've tried to read Chris's code, to see
how it positions itself under various circumstances, and I just
can't figure it out.  

Although my gut feel is that it has to do with the multiple
entries in the database, and the out-of-order-ness, I cannot
make a good case for this.  It may be something else entirely.

The one thing I'm certain of is that Chris will say "oh, that's
simple... when you see that error, if it's a Tuesday, just
call FrobbleDyGrook(), unless it's a full moon".  Chances are
pretty good that there's _some_ UDF function to deal with this.

So whatever happens tomorrow, please ship me a copy of your
entire data tree.  I'll try to track down the error as deep
as I can, then ask Chris for advice.


Incidentally, thank you for your PIDF-debugging hints.  I
am certain that others can find that useful.

Regards, and good night,
^E

[udf-dlm-develop] core dump

[Harald F. <hf...@ap...>]

I though I should send this experience to the group, maybe it helps somebody who 
still gets segmentation fauls or core dumps.

Our experience here is that this is ALWAYS caused by mistakes by the programmer. 
What we did here is certainly very old-fashioned, but helped us to trace so far 
all problems. In the pidf there is one line like this

    int num_sensors = 171;                         $$ no. of sensors

We changed this number first to 5, working only with the first 5 sensors, where 
it is unlikely (though not impossible) that there is an error in there. Then we 
increased this number to 50, 100 and checked if we got our segmentation fault. 
After it happened at 100 we got back to 80 etc, until we came close to the bad 
sensor by 5. Then it was easy to find the wrong statement and it always turned 
out to be our mistake.

So, if somebody still fights with segmentation faults, try this method (I still 
learned it in the university as a method to determine the square root of any 
number. Do you remember these times?)

Harald


=========================================================
Harald U. Frey 
Space Sciences Lab	   phone: 510-643-3323
University of California   fax:   510-643-2624      
Berkeley, CA 94720-7450    email: hf...@ss...

Re: [udf-dlm-develop] nasty problem 2.

[Harald F. <hf...@ap...>]

Here a quick log of my udf_times result. I have 5 files and at the end of each 
line of time-print, I added the number of the file, the time refers to. You see 
that at some point we get out of synch with 1,2,3,4,1,2,3,4,3,1, etc. and file 
number 5 appears quite late, probably because we added this file just about 2 
weeks ago.


IDL> key=UDF_Key(vinst_to_full_path('IMF12LSI'))
IDL> times=udf_times(key)
IDL> help,times
TIMES           STRUCT    = -> UDF_TIMES Array[18]
IDL> for i=0,17 do print,times[i].btime
{    1999     186   1  42  16     686       0.0000000}		1.
{    1999     187  11  30  19     695       0.0000000}		2.
{    1999     187  23  58  55     273       0.0000000}		3.
{    1999     189  12  54   5     447       0.0000000}		4.
{    1999     186   1  42  16     686       0.0000000}		1.
{    1999     187  11  30  19     695       0.0000000}		2.
{    1999     187  23  58  55     273       0.0000000}		3.
{    1999     189  12  54   5     447       0.0000000}		4.
{    1999     187  23  58  55     273       0.0000000}		3.
{    1999     186   1  42  16     686       0.0000000}		1.
{    1999     187  11  30  19     695       0.0000000}		2.
{    1999     189  12  54   5     447       0.0000000}		4.
{    1999     337   7  21  11     530       0.0000000}		5.
{    1999     186   1  42  16     686       0.0000000}		1.
{    1999     187  11  30  19     695       0.0000000}		2.
{    1999     187  23  58  55     273       0.0000000}		3.
{    1999     189  12  54   5     447       0.0000000}		4.
{    1999     337   7  21  11     530       0.0000000}		5.

We will do the moving of all files tomorrow, Steve has already left for today. 
Let me work on the error tracing a little bit, before I start taring files.

Harald

=========================================================
Harald U. Frey 
Space Sciences Lab	   phone: 510-643-3323
University of California   fax:   510-643-2624      
Berkeley, CA 94720-7450    email: hf...@ss...

Re: [udf-dlm-develop] nasty problem 2.

[Ed S. <es...@la...>]

How utterly weird.  I've never seen that here, but perhaps it's
because Los Alamos is at 7,000 feet elevation, thus closer to
the projected IMAGE orbit.  Perhaps UDF is sensitive to that?

Ya know, I'm not entirely sure if I'm joking here or not.

What I _am_ certain of is that UDF is not designed for the
purposes we're using it.  UDF seems to like having a program
run it, and letting the OS clean up.  The IDL model, where
you sit in an active session for hours/days/weeks, is not
to UDF's liking.  

That's the explanation for the problem.  We still need to
find a solution.

You mention that you rebuilt the database.  Are you certain
that it rebuilt correctly?

Could you try mv'ing away the files 

	$UDF_DATA/IMAGE/IMAGE-1/Database/FUV*.HD.*

(don't delete them, in case something else breaks)

...and _then_ try again to rebuild the database?


If that doesn't help, could you mail me the results of

  IDL> print,udf_times(key)

...to see if there's something out-of-sequence that UDF could
be choking on?

Also, I really think we need to trace the errors returned by
file_open(), ToThisTime(), file_pos(), and so on.  If you
don't feel comfortable instrumenting the code, could you
perhaps make a tarfile of your _exact_ data tree, and send
it my way?  

Thanks,
^E

PS sorry about such a late reply.  It's been a hectic evening.

[udf-dlm-develop] nasty problem 2.

[Harald F. <hf...@ap...>]

In response to Ed's email:

* I had 0.51 running, but even now with 0.52 the same problem persists.

* I am as sure as you can be with UDF, that I have the right key.

* From a brand new IDL session the command 
fh = udf_open(key, [1999,337,7,21,11,530], [1999,337,7,27,21,538])
works just fine.

* Here is the log of my latest try, which interestingly enough, now also happens 
to crash from the IDL prompt. So I don't need my widget program anymore. My 
comments are shown with *****

IDL> key=UDF_Key(vinst_to_full_path('IMF12LSI'))
IDL> fh = udf_open(key, [1999,337,7,21,11,530], [1999,337,7,27,21,538])
IDL> help,key,fh
KEY             ULONG     =    101220482
FH              INT       =      601
IDL> d=udf_read(fh)
IDL> udf_close,fh
****** First try in new session just fine. ****** 
IDL> key=UDF_Key(vinst_to_full_path('IMF12LSI'))
IDL> fh = udf_open(key, [1999,337,7,21,11,530], [1999,337,7,27,21,538])
IDL> help,key,fh   
KEY             ULONG     =    101220482
FH              INT       =      601
IDL> udf_close,fh
******* The same file again and everything is fine ****** 
IDL> key=UDF_Key(vinst_to_full_path('IMF12LSI'))
IDL> fh = udf_open(key, [1999,186,1,42,16,686], [1999,186,2,56,26,798])
IDL> d=udf_read(fh)
IDL> udf_close,fh
****** Second try with going back in time was successful too. ****** 
IDL> key=UDF_Key(vinst_to_full_path('IMF12LSI'))
IDL> fh = udf_open(key, [1999,189,12,54,5,447], [1999,189,18,52,15,730])
% UDF_OPEN: no data for this time period
% Execution halted at:  $MAIN$                 
IDL> help,key,fh
KEY             ULONG     =    101220482
FH              INT       =      601
****** Now going forward in time does not work. ****** 
IDL> exit
image1 [25] idl
IDL Version 5.3 (sunos sparc). (c) 1999, Research Systems, Inc.
Installation number: 8082.
Licensed for use by: Space Physics Research Group
******** Opening a new IDL session ****** 
IDL> key=UDF_Key(vinst_to_full_path('IMF12LSI'))
IDL> fh = udf_open(key, [1999,189,12,54,5,447], [1999,189,18,52,15,730])
IDL> d=udf_read(fh)
IDL> help,key,fh
KEY             ULONG     =    101220482
FH              INT       =      601
IDL> udf_close,fh
******** The previous problem is no problem in the new session ****** 
IDL> key=UDF_Key(vinst_to_full_path('IMF12LSI'))
IDL> fh = udf_open(key, [1999,337,7,21,11,530], [1999,337,7,27,21,538])
% UDF_OPEN: no data for this time period
% Execution halted at:  $MAIN$                 
******** The very first try of the previous session is now a problem, because it
******** is later than the previously called time period.


Another interesting by-product is, that we rebuilt our UDF database. With the 
command
times=udf_times(key)
I previously got 12 starting and ending times (for 5 files), and now I get 18 
starting and ending times. Each time is shown 5 times, except the last one, 
which is only 2 times in the database. May not be related to the problem, but 
who knows this for sure with UDF?

Harald


=========================================================
Harald U. Frey 
Space Sciences Lab	   phone: 510-643-3323
University of California   fax:   510-643-2624      
Berkeley, CA 94720-7450    email: hf...@ss...

Re: [udf-dlm-develop] nasty problem

[Ed S. <es...@la...>]

Harald,

Some quick things to try:

  * Do you have UDF-DLM 0.52 ?  There's some file_pos() vs. FilePosRec()
    nonsense fixed in 0.52; perhaps that's causing the positioning errors?

  * Are you sure you have the right key?

  * From a brand-spanking-new IDL session: what happens if you do:

     IDL> fh = udf_open(key, [1999,337,7,21,11,530], [1999,337,7,27,21,538])

  * If the above works, what happens if you UDF_CLOSE, then try it again?

Unfortunately, if none of this helps, all I can really suggest is putting 
in some printf()s in the UDF_OPEN code, perhaps seeing exactly what error
gets returned from ToThisTime(), or the filepos* routines.

Regards,
^E

[udf-dlm-develop] nasty problem

[Harald F. <hf...@ap...>]

Hi everybody,

I've been fighting with a nasty problem for several hours now, and I still don't 
have an idea about the cause. Maybe somebody has seen something similar, or has 
some ideas, where to look.

The FUV display software is IDL widget-based. When I open for instance several 
SI files after one another (the same for WIC), everything is still fine, as long 
as I go back in time. Whenever I have opened/read/closed a WIC file for say DOY 
187 and then try to open a new file for say DOY 337, I get the following message

UDF_OPEN: no data for this time period

The VERY BAD(!) thing is, I can not reproduce this kind of error, if I try the 
same thing outside of my widget environment. 

This is the part of IDL code which produces the error message

;=====================
	; open file and check for error
Catch, err_sts
print,'Start, stoptime: '
print,start_time,end_time,err_sts
IF (err_sts EQ 0) THEN fh  = UDF_Open(key, start_time, end_time) $
    ELSE print, !Error_State.Msg
Catch, /Cancel
;=====================

and this is the output of the print statements

Start, stoptime: 
    1999     187      11      30      19     695
    1999     187      16      22      29     959
           0
Start, stoptime: 
    1999     186       1      42      16     686
    1999     186       2      56      26     798
           0
Start, stoptime: 
    1999     337       7      21      11     530
    1999     337       7      27      21     538
           0
Start, stoptime: 
    1999     337       7      21      11     530
    1999     337       7      27      21     538
          -2
UDF_OPEN: no data for this time period

And I know for sure, that the last time period 1999-337-7-21-11 contains data, 
because everything is fine if I start with this time.

By the way I run

IDL> print,!version
{ sparc sunos unix 5.3 Nov 11 1999}

Any ideas are appreciated,
Harald

=========================================================
Harald U. Frey 
Space Sciences Lab	   phone: 510-643-3323
University of California   fax:   510-643-2624      
Berkeley, CA 94720-7450    email: hf...@ss...

[udf-dlm-develop] Readable PIDFs, and errors therein

[Eduardo S. <es...@la...>]

Folks,

Out of curiosity, I ran my fpidf script on all the PIDFs.  There's 
still a large number of errors.  

To make things easy for you, I've written a quick wrapper script that
HTMLizes the output and indexes it.  Results are at:

	http://mena.lanl.gov/udf/pidfs/

This is a page with links to readable PIDFs for all instruments.  
Some have script-detected errors: if your browser supports Cascading 
Style Sheets, these will show up in red.

I strongly urge all teams to look at the results for their instrument
(even the ones without indicated errors).  You may save yourself a lot 
of wasted effort.

Regards,
^E

Re: [udf-dlm-develop] question on setting IDL_DLM_PATH

[Ed S. <es...@la...>]

  > It works but it keeps IDL from seeing it's own DLM

*sigh*.  Yes, I know.  It's a problem with how IDL does things.

If you have IDL 5.3, there's a clean fix (I've tested it).  Otherwise,
use one of the variations documented in the INSTALL file.

Thanks,
^E

[udf-dlm-develop] question on setting IDL_DLM_PATH

[Kusterer, M. <Mar...@jh...>]

Hi,
On a  HP, to see the UDF DLM, I copy the library and dlm to the
$UDF_HOME/lib and 

setenv IDL_DLM_PATH +$UDF_HOME/lib

 It works but it keeps IDL from seeing it's own DLM that loads the JPEG
functions (write_jpeg, read_jpeg and query_jpeg). Has anyone had problems
with this? I can't seem to find the way to load IDL_DLM_PATH so that IDL
will add it's own default to what I have selected.

I found a temporary solution by unset IDL_DLM_PATH , then getting into IDL
and typeing $DLM_PATH to get the default IDL DLM library location. Then I
just added the IDL default ($IDL_DIR/bin/bin.hp) to my UDF DLM path.
setenv IDL_DLM_PATH $IDL_DIR/bin/bin.hp:$UDF_HOME/lib


thanks,
martha

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Martha Bolz Kusterer 4-178	 Balt. (443) 778-7276   or
Space Department		 Wash. (240) 228-7276 (office)
Applied Physics Laboratory	 (443) 778-1093 (FAX)
111000 Johns Hopkins Road	mar...@jh... (Internet)
Laurel, MD 20723-6099

[udf-dlm-develop] Preliminary support for UNITS

[Eduardo S. <es...@la...>]

Dear all,

I have just checked in some major edits to udf.c:

  UDF_OPEN() now accepts a UNITS= keyword, which can be a scalar or vector.

  Either way, the number(s) passed to UNITS are *NOT* UDF unit numbers!
  They are _ordinal_ numbers, selecting the Nth (zero-based) unit defined
  for a given sensor.  That is, if we have a PIDF as follows (HENA):

  Group  0: Neutral Hydrogen Pixels
     0 SSD H Elevation 0     0    s0    0,4,7,8
     1 SSD H Elevation 1     1    s0    0,4,7,8
     2 SSD H Elevation 2     2    s0    0,4,7,8

  ...then:

     calling with "UNITS=0" will select unit 0 for all sensors
     calling with "UNITS=1" will select unit 4
     calling with "UNITS=2" will select unit 7
     calling with "UNITS=3" will select unit 8
     calling with "UNITS=99" will select unit 8

     calling with "UNITS=[0,1,2,3]" will select unit 0 for sensor 0, 
     4 for 1, 7 for 2, and 8 for 3.  Although that's silly for this 
     VINST, it might make sense for others, and the capability is 
     there if you need it.

    The default is "999", which just means "the last defined unit".

There's still quite a ways to go.  In particular, I need to fix 
some of the named structure handling, add lots of error checking, 
and update the documentation before it can be released. 

If you have an immediate need for this functionality, "cvs update"
will get you the latest code.

Hope this helps,
^E

[udf-dlm-develop] Solved: problem for HENA with UDF DLM and new PIDF/VIDF

[Kusterer, M. <Mar...@jh...>]

Hi,
Thanks to Ed for figuring out the problem with the new PIDF files. Yes the
tbl_app_flag and tlb_app_oper values were indeed switched in Unit 7 and 8 in
IMHIMCPH, IMHIMCPL, IMHIH, IMHIHE, IMHICNO virtual instruments. I changed
them to match the notes in the VIDF and the newest version of the DLM works
with the newest VIDF/PIDF. I found that before I fixed them I also couldn't
get the ADump program to output those units.

Chris, could you please make that change in the official version of the
PIDFS for HENA.

thanks a bunch!!

martha

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Martha Bolz Kusterer 4-178	 Balt. (443) 778-7276   or
Space Department		 Wash. (240) 228-7276 (office)
Applied Physics Laboratory	 (443) 778-1093 (FAX)
111000 Johns Hopkins Road	mar...@jh... (Internet)
Laurel, MD 20723-6099

Re: [udf-dlm-develop] fpidf.pl: Displaying "tables" and "operations"

[Steve G. <ge...@ss...>]

At 03:32 PM 1/27/00 -0700, you wrote:
>Steve,
>
>Thanks for your prompt reply.  I have read the PIDF documentation,
>but that section isn't as clear to me as it is to you!  I just
>see that the number of tables and operations is the same, but I
>don't really understand how they're related.  Your note does
>confirm my beliefs, though.

I guess, like many things about UDF, it's not real clear.
But it really does work that way.  I've set up several tables now,
and can verify this is how the tables/ops are applied.

>Incidentally, the docs are available via HTTP at
>
>	http://pluto.space.swri.edu/~frio/
>
>Much easier than using ftp.

Nobody ever tells me about these changes -- well you did now. <grin>  
Now there's no need for the ftp URL that Chris passed out.
The HTTP sure runs faster on my machine.

>Finally, this list is archived and available to the entire world.
>Posting account names and passwords may not be wise.  I have sent
>a note off to the appropriate root accounts, notifying them of
>the security breach and asking them to change the password.

Sorry about that.  I think all the stuff that's accessible via
that login is read-only.  Anyway, the SwRI PLUTOcrat should
change the password once in a while.

Re: [udf-dlm-develop] fpidf.pl: Displaying "tables" and "operations"

[Ed S. <es...@la...>]

Steve,

Thanks for your prompt reply.  I have read the PIDF documentation,
but that section isn't as clear to me as it is to you!  I just
see that the number of tables and operations is the same, but I
don't really understand how they're related.  Your note does
confirm my beliefs, though.

Incidentally, the docs are available via HTTP at

	http://pluto.space.swri.edu/~frio/

Much easier than using ftp.

Finally, this list is archived and available to the entire world.
Posting account names and passwords may not be wise.  I have sent
a note off to the appropriate root accounts, notifying them of
the security breach and asking them to change the password.

Sorry about not having made that clear in the mailing list intro.

Again, thanks for your helpful reply,
^E

Re: [udf-dlm-develop] fpidf.pl: Displaying "tables" and "operations"

[Steve G. <ge...@ss...>]

At 02:46 PM 1/27/00 -0700, you wrote:
>Could someone please confirm for me whether "tables" and "operations"
>are associated with each other?

The Unit entry lists, for example:
  int tbl_app_flag = 10;
  int tbl_app_flag = 20;
  int tbl_app_oper = 1;
  int tbl_app_oper = 2;

This means that table 10 is applied with operation 1
then            table 20 is applied with operation 2

Chris's online docs go into some detail on this.
Point your browser to:

   ftp://fr...@pl.../image1/frio/UDFDevelop/MiniWeb/Master.html

When asked for password, enter "5lager5".

Select THE PIDF
Scroll to UNIT INFORMATION BLOCK, 
 then     tbl_app_flag

Warning: on my machine, MSIE doesn't ask for the password,
and thus denies you access to the data.  NETSCAPE works OK.