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

[McIDAS #PRA-170907]: High resolution fulldisk GOES

This archive contains answers to questions sent to Unidata support through mid-2025. Note that the archive is no longer being updated. We provide the archive for reference; many of the answers presented here remain technically correct, even if somewhat outdated. For the most up-to-date information on the use of NSF Unidata software and data services, please consult the Software Documentation first.

  • Subject: [McIDAS #PRA-170907]: High resolution fulldisk GOES
  • Date: Fri, 28 Jun 2013 08:11:46 -0600
Hi João,

re:
> Sorry for reopening this discussion, but my scripts have stopped working!

Are you saying that they were working and then the stopped?  If
yes, what was changed between when they were working and when they
stopped?

re:
> Again, I intended to create high resolution files by forcing a second frame
> to large size.
> I get the following error, when running a cron job shell script, which
> calls mcbatch.k.
> 
> IMGDISP SFD 2 BAND=1 GRAY=Y TEXT=X 251 2
> IMGDISP:
> IMGDISP: Invalid Frame Number.
> IMGDISP: 2nd positional argument is too big --> 2
> IMGDISP: Must be valid 'Frame Number' integer value within range 1 thru 1.
> IMGDISP:
> 
> This besides having the following command before mcbatch.k
> mcenv -f 1@480x640 -f 1@10000x15000
> 
> I know for sure that the .BAT file is ok, as I can generate image calling
> batch.k directly.

Two things:

- I can not comment specifically without seeing the script being run

- it is possible that the scripts are not correctly exiting
  the McIDAS environment so they are leaving behind allocated
  shared memory segments, and these allocated segments are
  keeping new invocations from working correctly

  You can check this hypothesis by running the following
  command:

  ipcs

  If there are a number of shared memory segments owned by the
  user running the McIDAS scripts, you will need to delete
  them using:

  ipcrm

  Please review the man page for ipcrm for details on how to run
  it.

  Also, if you do find logs of shared memory segments hanging
  around, you will also need to clean up (delete) subdirectories
  of the .mctmp directory which can be found in the HOME directory
  of the user that is running the scripts.

  If your scripts are not correctly returning the shared memory
  to the OS, you will need to review your scripts to find out
  why they are not exiting properly.  A series of McIDAS commands
  run from the:

mcenv <options> < EOF
command1
command2
...
exit

EOF

  construct will create shared memory segments, use them and then
  return them to the OS.  If this segment is exited prematurely,
  the shared memory segments will not be returned to the OS.

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: PRA-170907
Department: Support McIDAS
Priority: Normal
Status: Closed