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

20010514: 20010507: 20010507: oabsnd and swap space

Chris,
I'm not saying that you can't run more than 1 GEMPAK program at the same time.
What I can say is:
1) if you have a program that frequently exits abnormally, and leaves behind
   a gplt, or other process, then the likelihood is that system resources will
   start to run short.

2) If 2 processes ask for a gplt at the same time, it is possible for both 
programs
   to be issued the same message queue ID by the system. This happens because
   until the program actually gets the gplt process running, the system will 
keep
   handing out the same available message queue. Using _gf programs where the 
   gplt and gf processes are linked to the application reduces the total
   number of processes running on your system at any one time, and avoids the
   use of message queues- thereby avoiding the possible conflict above.

3) If multiple programs are running at the same time, you should have ntl 
running
   on the display so that all processes use the shared color map so you don't 
run out of
   colors on the display (you can run ntl on a screen:1 as well). Or, use the 
gif device
   driver that doesn't require an X display to be running (you'll have to use 
message queues
   for the gif driver - except with the radmap_sw program which I do have 
linked with gif insted of gf).

Nothing has changed in the underlying message queue system between 5.4 and 5.6, 
or the
shared color system- so that isn't a cause for differences.

when you say that models take 2-3 hours to run, are you saying that the time 
over which the data
arrives is 2-3 hours, or are you saying that the GEMPAK programs take that long 
to run?
I can help you organize actions to kick off when the LDM receives necessary 
grids, or
determine when all the pieces of data exists so that you don't have to run 
programs
multiple times to recreate plots as more data arrives. Let me know if I can 
help you.

Steve Chiswell
Unidata User Support






>From: address@hidden (Chris Hennon)
>Organization: UCAR/Unidata
>Keywords: 200105142213.f4EMDfp11331

>Steve -
>
>This issue seems to have been resolved after a reboot, though I am not
>sure why.
>
>Just to clarify,
>are you saying that two or more gempak programs cannot be running at the
>same time?  When I was using 5.4 and before the rebuild, I sometimes had 4
>or 5 scripts cranking along at the same time with no problem.  I've
>followed your suggestions, using the _gf programs where possible and using
>master scripts for large jobs.  But there are still issues with
>overlapping jobs - for example, surface fields get plotted every hour, but
>to run the NGM,ETA, and AVN models takes at least 2-3 hours to run.
>
>Thanks ahead.
>
>Chris
>
>================================================
>| Chris Hennon        Ohio State University   |
>| Tropical Meteorology      address@hidden   |
>|                                              |
>| Dept of Geography   Office: 1155 Derby Hall  |
>| 1036 Derby Hall     Phone : (614) 292-2704   |
>| Columbus, OH 43210  Fax   : (614) 292-6213   |
>================================================
>
>On Mon, 7 May 2001, Unidata Support wrote:
>
>> 
>> Chris,
>> 
>> I was actually refering to the grid dimensions, can you send me the
>> GDINFO for your grid file?
>> 
>> Steve Chiswell
>> Unidata User Support
>> 
>> 
>> 
>> >From: address@hidden (Chris Hennon)
>> >Organization: UCAR/Unidata
>> >Keywords: 200105071933.f47JXqp00391
>> 
>> >Steve -
>> >
>> >The upperstr.grd file is pretty big:
>> >
>> >twister:[/usr/local/gempak/grids]% ls -l
>> >-rw-r--r--   1 gempak   ldm      2575360 Apr 12 23:30 upperstr.grd
>> >
>> >oabsnd is version 5.6.a, as is dcuair.  
>> >
>> >Chris
>> >
>> >================================================
>> >| Chris Hennon             Ohio State University   |
>> >| Tropical Meteorology      address@hidden   |
>> >|                                              |
>> >| Dept of Geography   Office: 1155 Derby Hall  |
>> >| 1036 Derby Hall     Phone : (614) 292-2704   |
>> >| Columbus, OH 43210  Fax   : (614) 292-6213   |
>> >================================================
>> >
>> >On Mon, 7 May 2001, Unidata Support wrote:
>> >
>> >> 
>> >> Chris,
>> >> 
>> >> What is the size of the $HOME/grids/upperstr.grd file?
>> >> What version of GEMPAK are you running (eg 5.6, 5.6.C)?
>> >> Are you running a different version of the dcuair decoder?
>> >> 
>> >> For example:
>> >>  GEMPAK-OABSND>version
>> >> 
>> >>  GEMPAK Version 5.6.c.1
>> >> 
>> >> % dcuair -help
>> >> ....
>> >> >Version 5.6.c.1<
>> >> 
>> >> 
>> >> Steve Chiswell
>> >> Unidata User Support
>> >> 
>> >> 
>> >> >From: address@hidden (Chris Hennon)
>> >> >Organization: UCAR/Unidata
>> >> >Keywords: 200105071647.f47Gltp15071
>> >> 
>> >> >Steve -
>> >> >
>> >> >I double checked and all looks well there:
>> >> >
>> >> >twister:[/usr/local/gempak/scripts/upperair]% cd $GEMEXE
>> >> >twister:[/usr/local/gempak/bin/sol]% ls -l gplt
>> >> >-rwxr-xr-x   1 gempak   ldm       496276 Apr 23 13:45 gplt*
>> >> >twister:[/usr/local/gempak/bin/sol]% cd ../../scripts/upperair
>> >> >twister:[/usr/local/gempak/scripts/upperair]% oabsnd
>> >> > SNFILE    Sounding data file                $RAW_UPA/20010507_upa.gem
>> >> > GDFILE    Grid file                         $HOME/grids/upperstr.grd
>> >> > SNPARM    Sounding parameter list           tmpc
>> >> > STNDEX    Stability indices                  
>> >> > LEVELS    Vertical levels                   925
>> >> > VCOORD    Vertical coordinate type          PRES
>> >> > DATTIM    Date/time                         12
>> >> > DTAAREA   Data area for OA                   
>> >> > GUESS     Guess file*time                    
>> >> > GAMMA     Convergence parameter             0.3
>> >> > SEARCH    Search radius/Extrapolation       20/EX
>> >> > NPASS     Number of passes                  2
>> >> > QCNTL     Quality control threshold          
>> >> > Parameters requested: SNFILE,GDFILE,SNPARM,STNDEX,LEVELS,VCOORD,DATTIM,
>> >> > DTAAREA,GUESS,GAMMA,SEARCH,NPASS,QCNTL.
>> >> > GEMPAK-OABSND>r
>> >> >Could not fork
>> >> > [GEMPLT -101]  NOPROC   - Nonexistent executable.
>> >> > [OABSND -3]  Fatal error initializing GEMPLT.
>> >> >twister:[/usr/local/gempak/scripts/upperair]%
>> >> >
>> >> >Chris
>> >> >
>> >> >================================================
>> >> >| Chris Hennon          Ohio State University   |
>> >> >| Tropical Meteorology      address@hidden   |
>> >> >|                                              |
>> >> >| Dept of Geography   Office: 1155 Derby Hall  |
>> >> >| 1036 Derby Hall     Phone : (614) 292-2704   |
>> >> >| Columbus, OH 43210  Fax   : (614) 292-6213   |
>> >> >================================================
>> >> >
>> >> >On Mon, 7 May 2001, Unidata Support wrote:
>> >> >
>> >> >> 
>> >> >> Chris,
>> >> >> 
>> >> >> OABSFC requires that "gplt" be found. The non-existent
>> >> >> executable seems to indicate that $GEMEXE/gplt is either
>> >> >> not bring found, that you don't have permission to execute it, 
>> >> >> or that for some reason the system is not able to execute gplt.
>> >> >> 
>> >> >> Since it says non-existent, it sounds like the program is
>> >> >> not being found. See if there is any problem with your $GEMEXE
>> >> >> environmental variable (which is set when you sourced Gemenviron),
>> >> >> and double check that gplt is executable as well.
>> >> >> 
>> >> >> The attempt to execute gplt occurs when you run the analysis,
>> >> >> eg, not when you first start up oabxxx.
>> >> >> 
>> >> >> Steve Chiswell
>> >> >> Unidata User Support
>> >> >> 
>> >> >> 
>> >> >> 
>> >> >> >From: address@hidden (Chris Hennon)
>> >> >> >Organization: UCAR/Unidata
>> >> >> >Keywords: 200105071618.f47GIbp13844
>> >> >> 
>> >> >> >Steve -
>> >> >> >
>> >> >> >I've run into a curious problem.  I'm trying to run "oabsnd" for just
>  on
>> > e
>> >> >> >level and one variable and the program exits with a NOPROC - Nonexist
> ent
>> >> >> >executable and "Could not fork" errors.  I think I have plenty of swa
> p
>> >> >> >space:
>> >> >> >
>> >> >> >swap -s
>> >> >> >total: 67792k bytes allocated + 167728k reserved = 235520k used, 1596
> 08k
>> >> >> >available
>> >> >> >
>> >> >> >There are no rogue processes around that I can see.  There are no dea
> d
>> >> >> >message queues.  In the past, I have run oabsnd under the same condit
> ion
>> > s
>> >> >> >without a problem, even with more levels and more variables.  The sup
> por
>> > t
>> >> >> >archives all seem to indicate a problem with either swap space or orp
> han
>> > ed
>> >> >> >processes but it doesn't appear that I have those issues.  Any ideas?
>> >> >> >Thanks.
>> >> >> >
>> >> >> >Chris    
>> >> >> >
>> >> >> >================================================
>> >> >> >| Chris Hennon               Ohio State University   |
>> >> >> >| Tropical Meteorology      address@hidden   |
>> >> >> >|                                              |
>> >> >> >| Dept of Geography   Office: 1155 Derby Hall  |
>> >> >> >| 1036 Derby Hall     Phone : (614) 292-2704   |
>> >> >> >| Columbus, OH 43210  Fax   : (614) 292-6213   |
>> >> >> >================================================
>> >> >> >
>> >> >> 
>> >> >> **********************************************************************
> ***
>> > ***
>> >> >> Unidata User Support                                    UCAR Unidata P
> rog
>> > ram
>> >> >> (303)497-8644                                                  P.O. Bo
> x 3
>> > 000
>> >> >> address@hidden                                   Boulder, CO
>  80
>> > 307
>> >> >> ----------------------------------------------------------------------
> ---
>> > ---
>> >> >> Unidata WWW Service                        http://www.unidata.ucar.edu
> /  
>> >    
>> >> >> **********************************************************************
> ***
>> > ***
>> >> >> 
>> >> >
>> >> 
>> >> *************************************************************************
> ***
>> >> Unidata User Support                                    UCAR Unidata Prog
> ram
>> >> (303)497-8644                                                  P.O. Box 3
> 000
>> >> address@hidden                                   Boulder, CO 80
> 307
>> >> -------------------------------------------------------------------------
> ---
>> >> Unidata WWW Service                        http://www.unidata.ucar.edu/  
>    
>> >> *************************************************************************
> ***
>> >> 
>> >
>> 
>> ****************************************************************************
>> Unidata User Support                                    UCAR Unidata Program
>> (303)497-8644                                                  P.O. Box 3000
>> address@hidden                                   Boulder, CO 80307
>> ----------------------------------------------------------------------------
>> Unidata WWW Service                        http://www.unidata.ucar.edu/     
>> ****************************************************************************
>> 
>