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

20021030: NFS mounting point for Gempak - re sat pointers

>From: gempak <address@hidden>
>Organization: UCAR/Unidata
>Keywords: 200210301827.g9UIRxX14776

>Steve,
>  We NFS mounted the data after the /var/data/ldm/ point, and everything seems
>  
>to work in Gempak, except we can't get satellite images.  The directory 
>structure takes us to the images which are pointers (links) back to
>  
>   /var/data/mcidas/AREA...
>   
>   Since /var/data/ldm is also a pointer from /usr/user/ldm/data as well as fr
> om 
>   /usr/var/data
>   
>   Can we NFS mount at /usr/user?  I'm worried about gettign into some sort of
>  
>endless loop of poitners - links.
>   
>   If I mount before /var then the links will still work.
>   
>   Does this make sense, or am I missing something fundamental here?
>   
>   Thank you for your patience.
>   Nancy
>   
>   address@hidden
>   address@hidden
>


Nancy,

The NFS mount point can be anywhere. If both the server and the client
machines have the /usr/user path, then that would be ideal. The
$GEMDATA would likely be /usr/user/ldm/data/gempak.

If your area files are under /var/data/mcidas, I'm also assuming
that this is /usr/user/mcidas, and if so, would be convenient using
the NFS mount point above. 

In GEMPAK, the satellite images are rooted at the $SAT location. You
have 2 options. 

1) here, I have the ldm-mcidas decoder pnga2area create the files
using the tree structure expected by GEMPAK as shown:
http://www.unidata.ucar.edu/packages/gempak/tutorial/pqact/images.tbl

2) If your files are named AREA0120, AREA0121, etc, then you can generate
symbolic links from those files to a GEMPAK tree structure where the
file name provides the data/time band information as above using
the areaInfo program. This would be used in the GUI programs for
correctly ordering the loops (since the AREA file names are circular
and do not give the order).

Steve Chiswell