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

20020111: Some servutil.c changes I want to make

>From:  Scott Lindstrom <address@hidden>
>Organization:  Space Science and Engineering Center
>Keywords:  200201041558.g04FwHN15124 McIDAS-X servutil

Scott,

>I almost have the level 1b servers working, but I've made a couple
>servutil.c changes that I've made locally so the server works in linux
>like it does elsewhere.  I want to check them in,
>and am running them by you now to see what you think.

OK.

>In GetFileList, I have initialized curpos to zero.  No big deal, I
>hope.  

In the copy of servutil.c that I am looking at, there is no curpos
variable.  Where are you finding this exactly?  If you mean cur.pos,
then this is already initialized to zero by virtue of:

    FILELIST    cur={0};                    /* FILELIST struct of image info */

>Also in GetFileList, I changed the 
>
>rc = glob( filename, GLOB_NOSORT, NULL, &fmatches );
>
>to
> 
>rc = glob( filename, NULL, NULL, &fmatches );
>
>(This is generating a list of filenames that match the filemask).
>
>In other words, the glob on filenames returns a sorted list now.
>Tom, can you tell me why the default for this was not followed?
>(Return a sorted list is the default).

Since the list of files has to be sorted into a time order (by reading
the time from the file data, not its name), forcing the glob to return
a sorted list seemed like extra work.  Changing the glob to do a sorted
list should not affect anything since the same work still has to be
done.  Question: are you making your Level 1B server use "information"
in the file name itself?

>On linux, GLOB_NOSORT
>resulted in the 1st file alphabetically being returned last
>(I'm not sure how it was being sorted, but it was different
>from the sgi machine, at least).  So if you asked for position
>1 in a dataset consisting only of masked files, you didn't get
>the first dataset alphabetically, which I believe is supposed
>to happen.

This comment seems to indicate that you will be relying on the file
name to make a correctly (i.e., time) sorted list.  If true, what
happens when the user creates a dataset of Level 1B images with
arbitrarily named files?

>Also in GetFileList, the incrementing of cur.pos in the
>Select all matches EXCEPT directories loop was doing bizarre
>things, so I now increment curpos and assign the value to
>cur.pos.

I do not really understand your comment "doing bizarre things".  All
the code is doing is incrementing a integer structure element.  I never
noticed that this was not working correctly (i.e., it seems to work
correctly for the NEXRAD, NOWRAD, and GINI ADDE severs that use the
same code).  If there is something strange going on here, we should get
to the bottom of it and not try to wire around it.

>In GetImgRes I have changed the type of the variables used
>in the nav calls (dum1,dum2,lat,lat2,lon,lon2,fline,felem) 
>from float to Freal.  Doesn't really change much, but it 
>reduces the number of compiler warnings :)

This sounds innocent enough.

>The only big change is the glob change.  DO you foresee any
>problems with it?

I don't see any problems with the glob change, but I am worried about
the cur.pos incrementing issue.  Again, we should get to the bottom of
why this is acting bizarre on your setup.

Tom

>From address@hidden Fri Jan 11 09:26:53 2002

re: curpos
>Oops.  I notice I have made a new variable named curpos and
>initialized it.  This is used in the incrementing problem
>or unknown cause that I found as noted below.

>By default, The level 1b server lists files alphabetically by filename, 
>although you can't really tell from the IMGLIST output.  For my example, 
>I have 6 files (these are mostly names directly from saa)

>A1027026.L1257972.10bit
>A1027026.L1257973.10bit
>A1216230.L1516063.GAC.10bit
>A1216230.L1516064.HRPT.10bit
>A1225280.L1528877.HRPT.10bit
>A1225280.L1528878.GAC.10bit

>that when IMGLIST'ed look like: 

>IMGLIST
>LV1B/GAC10.ALL                                                               
>Image file directory listing
>for:LV1B/GAC10                                          
>Pos Satellite/         Date       Time      Center  Band(s)
>    sensor                                 Lat Lon
>--- -------------  ------------  --------  ---- ---- ------------ 
>  1  NOAA-15       10 NOV 99314  01:03:11    20   78 1-5
>  2  NOAA-15        9 NOV 99313  23:25:18    37   55 1-5
>  3  NOAA-15       20 SEP 01263  00:34:50    38   77 1-5
>  4  NOAA-15       20 SEP 01263  00:34:49    44   88 1-5
>  5  NOAA-15       24 SEP 01267  00:41:13    41   89 1-5
>  6  NOAA-15       24 SEP 01267  00:41:13    34   78 1-5

>(You can time-order them if you want, by specifying position -5, btw).

>Anyway, the files are put in alphabetic order by PushFileByName, but
>the position number that is assigned comes out of the order they are
>returned by GLOB, not the actual position in the ordered list.  So
>if I followed the IMGLIST above by trying to list out position 1, I
>would actually get position 6 listed, and vice versa because position
>1 was the 6th one found, and 6 was the first one found.  (the
>positions work in the .ALL listing because the files don't have to
>be searched on the list of files -- they're just popped off and
>sent) None of this aberrant behavior would bother me -- I could
>just change the search to skip through n file names rather than
>matching position n in the list -- but it did bother me that
>the behavior was different on linux than on the "regular" unix 
>flavor boxes (sweetpea/brutus/popeye/wimpy).

>I recall it behaving as if the pointer was being incrementing
>rather than the integer.  Unfortunately, I can't recall which
>platform I was seeing this on.  I'm having Dave run purify on
>the code to see if there are leaks occurring in the level 1b
>server that were causing the problem.  After he does that I'll
>yank out the change and see if I can still observe the effect.

>Scott
>-- 
>Scott S. Lindstrom   | A lawyer can be disbarred; Can
>address@hidden |  a meteorologist be disgusted?
>http://www.ssec.wisc.edu/~scottl/homepage1.html