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

20010807: Problems at UPRM (cont.)

>From: Unidata Mcidas Account <address@hidden>
>Organization:  University of Puerto Rico
>Keywords:  200106202036.f5KKab115440 McIDAS ADDE DATALOC DSINFO IMGLIST

Luis,

>   For some weird reason the ~mcidas/.mcidasrc file existed but was empty.
>I copied another one I had on another account there and added the -f line.

I would recommend that you simply delete the empty file and have it
recreated for you the next time you start a McIDAS session by running:

mcidas

>I'm not physically right now at the university so I'll have to wait until
>later today to check it that works fine.

OK.

>Of course, I have one more
>question.  Can I define a mydata set for each of the images I want to
>archive?  And save each one into a different area file?  I'm afraid I'll
>overwrite images before they've been archived correctly.  Or that I'll
>copy the incorrect image to an archive.

Yes.  You could, for example, create a more customized dataset for output
and be more specific as to the AREA files that are included in those
sets.  Here is one idea (the dataset descriptors might be different as
will be the AREA file number you use, but this should illustrate the
point):

DSSERVE ADD UPRM/GE-VIS AREA 2140 2149 "UPRM archive GOES-East North America VIS
DSSERVE ADD UPRM/GE-IR  AREA 2150 2159 "UPRM archive GOES-East North America IR
DSSERVE ADD UPRM/GW-WV  AREA 2170 2179 "UPRM archive GOES-West Western US H2O

This setup will all you to save 10 images in each set:

UPRM/GE-VIS -> AREA2140 - AREA2149
UPRM/GE-IR  -> AREA2150 - AREA2159
UPRM/GE-WV  -> AREA2170 - AREA2179

If you only wanted to save one of each, you could change the DSSERVE commands
to:

DSSERVE ADD UPRM/GE-VIS AREA 2140 2140 "UPRM archive GOES-East North America VIS
DSSERVE ADD UPRM/GE-IR  AREA 2150 2150 "UPRM archive GOES-East North America IR
DSSERVE ADD UPRM/GW-WV  AREA 2170 2170 "UPRM archive GOES-West Western US H2O

If you wanted the AREA file numbers to be consecutive, this could be:

DSSERVE ADD UPRM/GE-VIS AREA 2140 2140 "UPRM archive GOES-East North America VIS
DSSERVE ADD UPRM/GE-IR  AREA 2141 2141 "UPRM archive GOES-East North America IR
DSSERVE ADD UPRM/GW-WV  AREA 2142 2142 "UPRM archive GOES-West Western US H2O

and so on.  You still have to make sure, however, that the AREA files that
are part of the UPRM dataset are not already in use.

Let's assume that you setup your dataset like what is listed in the last
example above.  The IMGCOPY command you run might look like:

IMGCOPY GINIEAST/GPR1KVIS UPRM/GE-VIS.1 SIZE=ALL
                                      ^
Notice how the position in the output dataset is no longer the AREA file
number.  The only reason it was in the example in the previous email was
that the set of images in MYDATA/IMAGES is the same as all possible
images that use AREA file naming conventions:

MYDATA/IMAGES.1    <-> AREA0001
  ...
MYDATA/IMAGES.234  <-> AREA0234
  ...
MYDATA/IMAGES.9999 <-> AREA9999

In the last UPRM definition above the mappings are specific:

UPRM/GE-VIS.1 <-> AREA2140
UPRM/GE-IR.1  <-> AREA2141
UPRM/GE-WV.1  <-> AREA2142

The position number is the relative position of the image in a dataset.

>Should I be concerned?

Always :-)

>   I'm going to make the scripts that will archive the images today.
>What I plan to do is add them as cron jobs depending on how often the
>images are refreshed.  I'm going to start out with the 1km hi res vis
>today(since it's the one Amos wants the most) and if everything works
>fine, then all I have to do is port the script for all the different kinds
>of adde images I want to archive.

Sounds good.  You could make the script general enough to do any/all images.
This way you would not have to maintain more than one script.  It would
be more complicated internally, of course, but the long term maintenance
would be less.

>And later on I'll make a script for the
>area2png archiving, which if I'm not mistaken is lower priority.

OK.  This could also be rolled into the same script so that everything
happens at once.

>   As for the upgrading to 7.80, I think I'll hold on for a while to this
>working copy you installed.  I've been working for months on this and I
>finally have everythying up and running.

The only reason I suggested the upgrade was so that you could move away
from the old Fkey menu and start using the GUI which has easy access to
the GINI images built in.  It really is a lot nicer.

>If I mess something up while
>upgrading, I'll have to find a tall place with sharp, pointy objects in
>the bottom, and jump. =)

The good thing about upgrading is that you can keep the old installation
around and switch back to its use if you ran into any problems.

>It's very difficult for me to show Amos any
>progress until I can show him the archived images.  Once I do that, I'll
>spend some time on the upgrade process.

OK.

>   Thanks again.

You are welcome.  Talk to you later...

Tom