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

[McIDAS #WLU-125107]: McIDAS Questions

Hi Paul,

re:
> Thanks for your response concerning the NEX* files.

No worries.

re:
> we have been trying to do upgrades and I have a few more questions.
> 
> I think our problem was that we were appending to a log file and that file
> was so large it caused high latencies in I/O. I have remedied the problem
> by writing stnrd/erro out to /dev/null for the loggin of our mcidas kickoff
> scripts.

We have also seen that failing to rotate logs can lead to extremely
large log files, and this can impact system performance even on very fast
machines.

re:
> Here are the two questions at this time.
> 
> First, I saw that McIDAS-V has support for SVG files. Will McIDAS-X do
> that?

No, McIDAS-X does not support the SVG (Scalable Vector Graphics) format.
The types of save formats in McIDAS-X are listed in the HELP for the
FRMSAVE command:

HELP FRMSAVE
FRMSAVE -- Saves a McIDAS frame to a GIF, PPM, BMP, JPEG or PostScript file
   FRMSAVE frame name <keywords>
   FRMSAVE window name TYPE=COMBINE <keywords>

Parameters:
   frame | image frame number to save (def=current)
   window | combined window number (created with COMBINE command); the
            range is 0-9; you must also specify TYPE=COMBINE with this
            option
   name | name of the file in which to save the frame; if you don't
          specify an extension, .GIF is appended if FORM=GIF, .PPM is
          appended if FORM=PPM, .BMP is appended if FORM=BMP, .JPG is
          appended if FORM=JPG, .PS is appended if FORM=PS, and .CPS
          is appended if FORM=CPS
Keywords:
   GRA= | graphics frame to save with the image; valid only for
          TYPE=FRAME; see the Remarks (def=number specified in 'frame'
          if session does not have independent graphics; def=last-
          associated graphics frame if session has independent graphics)
   FORm= | format of saved file; valid entries are GIF, PPM, BMP, JPG,
           PS, and CPS for graphics interchange, portable pixmap, bitmap,
           JPEG, PostScript, and color PostScript formats, respectively
           (def=GIF for TYPE=FRAME; def=JPG for TYPE=COMBINE)

re:
> we want to save frames using SVG formats rather than gifs and hope
> that will be possible soon.

Unfortunately, it is not possible at this time, and, quite frankly, I have
never heard any comments from the SSEC folks that they are contemplating
adding SVG as a viable save format.

re:
> Second, I am running the command dsinfo.k NEX1/IMAGE (where NEX1 is aliased
> as NEXRCOMP/1KN0R-NAT)
> The output finds AMRC, BLIZZARD and, CIMSS with info but then the process
> hangs and it does not return any more. What would cause that?

The syntax for DSINFO invocations is:

DSINFO -- Lists ADDE datasets on local and remote servers
   DSINFO type group

The default for the 2nd positional parameter to be specified, 'group',
is ALL:

HELP DSINFO
DSINFO -- Lists ADDE datasets on local and remote servers
   DSINFO type group
Parameters:
   type  | data type; valid types are GRID, IMAGE, NAV, POINT, TEXT,
           or ALL (def=ALL)
   group | group name (def=all groups)

What is happening is that DSINFO only checks the first character of
the 1st positional parameter to see what type of dataset (e.g., GRID,
IMAGE, NAV, POINT, TEXT, or ALL) to list information for. In your case,
it is picking up the 'N' in NEX1/IMAGE and assuming that you are asking
for information on NAV type datasets.  Also since you are not specifying
a specific group name, it is trying to list out information on all ADDE
datasets it finds in your McIDAS-X client routing table (the table that
DATALOC creates and maintains).  In effect, your DSINFO invocation is
being interpreted as:

DSINFO NAV ALL

Why this hangs is a mystery to me; it is likely an indication
of a bug in DSINFO.


You can demonstrate the importance of the first character of the
first positional parameter by running:

DSINFO IMAGE NEXRCOMP
DSINFO I NEXRCOMP
DSINFO IWXY NEXRCOMP

Each invocation should give you the exact same output.

re:
> Hope all is well Tom! Wish I could have a beer with you sometime!

I'm doing OK.  I was in China working with folks from two Chinese
Met Agency offices for two weeks, and it was very interesting.  I'm
back in the office now trying to catch-up on a variety of things,
but mainly doing support for sites that are spinning back up their
data ingest (LDM), decoding (GEMPAK and McIDAS) and use after being
off for the summer.

Getting together for a beer (or three ;-) whenever you are in town
sounds great!

Cheers,

Tom
--
****************************************************************************
Unidata User Support                                    UCAR Unidata Program
(303) 497-8642                                                 P.O. Box 3000
address@hidden                                   Boulder, CO 80307
----------------------------------------------------------------------------
Unidata HomePage                       http://www.unidata.ucar.edu
****************************************************************************


Ticket Details
===================
Ticket ID: WLU-125107
Department: Support McIDAS
Priority: Normal
Status: Closed
===================
NOTE: All email exchanges with Unidata User Support are recorded in the Unidata 
inquiry tracking system and then made publicly available through the web.  If 
you do not want to have your interactions made available in this way, you must 
let us know in each email you send to us.