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

20000502: 20000501: 20000223: gf driver

Chris,

If you are generating gifs to the console display, then yes, you
really want ntl to be running so that the shared color map exists
between all gempak programs, and any other programs like browsers, desktops,
etc. aren't competing with the cron programs for the colors.

If you do a lot of gif generation, then running a virtual X server such as Xvfb
works well so that you don't have to worry about your desktop colors
and conflicts with cron jobs. In those cases, you would then have a shear:1
display to draw to.

The output you see with >0.0u 0.0s 0:07 0% 0+0k 0+0io 0pf+0w
is indicative of running the unix "time" command with a job that shows tha
cpu usage. Typically, you would run "time eta_sfc.csh" if you wanted to
keep track of how much cpu usage a program took, or if you had
quotas invoked on your users. Otherwise, something in your environment
may be defined. Since the script is run from cron with csh -f, you
should not be inheriting your environment in those cases.

Steve Chiswell
Unidata User Support



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

>Steve -
>
>Here's what I have done since I received your last email.  I tried to run
>the script /usr/local/gempak/scripts/models/eta_sfc.csh to verify that I
>could write gifs, and it ran normally!  Not understanding why it was
>working, I rebooted the machine and tried it again, and it appeared to be
>working fine.  Today I came in and tried it again.  This time, I hit
>ctrl-c halfway through the script.  I cleared out the message queues using
>'ipcrm -q' and verified there were no gplts left running.  I ran the same
>script and it did produce the gifs.  However, it constantly scrolled :
>
>0.0u 0.0s 0:07 0% 0+0k 0+0io 0pf+0w
>0.0u 0.0s 0:03 0% 0+0k 0+0io 0pf+0w
>0.0u 0.0s 0:00 0% 0+0k 0+0io 0pf+0w
>
>But it made the gifs OK.  Perhaps you can clarify a couple of things for
>me.  First, I assume that ntl must be invoked on the console at all times
>when I'm running scripts from the cron?  Is this for color allocation?  I
>believe it started core dumping last time when I tried to run scripts
>without ntl running.  Second, what do the 0.0u 0.0s etc... lines mean?  In
>the past, they have meant that something was hosed and I couldn't write
>any gifs.  Now I seem to be able to write gifs but they still make me
>uncomfortable.  
>
>Thanks Steve.
>
>Chris
>
>PS  I'm running scripts from the /usr/local/gempak/scripts/models 
>directory using the 'gempak' userid.  The display is set in the scripts as
>my machine, 'shear:0'.  I believe the scripts are set up properly, but I
>could be wrong.  The login I sent you is still valid.
>
>
> On Mon, 1 May 2000, Unidata Support wrote:
>
>> 
>> 
>> Chris,
>> 
>> I logged in and was sucessful in producing gif output.
>> 
>> I verified that your default visual is 8 bits, and the gf binary
>> has not been rebuilt since Feb 7, and ntl is being run and owned by yourself
> .
>> 
>> Can you provide me with details as to what working directory,
>> display, userid, gempak program or cron/script is involved?
>> 
>> Thanks for any information you can provide me with.
>> 
>> Steve Chiswell
>> Unidata User Support
>> 
>> 
>> 
>> >From: address@hidden (Chris Hennon)
>> >Organization: UCAR/Unidata
>> >Keywords: 200005012001.e41K19G23042
>> 
>> >Steve -
>> >
>> >That would be great.  Here's the login information:
>> >
>> >
>> >Anxious to hear if you find anything.  
>> >
>> >Chris
>> >
>> >
>> >On Fri, 28 Apr 2000, Unidata Support wrote:
>> >
>> >> 
>> >> Chris,
>> >> Its possible that the patches made the X libraries incompatible with
>> >> the running binaries, or that the configuration of the machine was change
> d.
>> >> 
>> >> I'll take a look around if you send me a login.
>> >> 
>> >> Steve Chiswell
>> >> 
>> >> >From: address@hidden (Chris Hennon)
>> >> >Organization: UCAR/Unidata
>> >> >Keywords: 200004281202.e3SC2GG07749
>> >> 
>> >> >Steve -
>> >> >
>> >> >Sorry to keep harassing you about this, but I am still having problems
>> >> >with my gempak routines core dumping when I try to write gifs.  There ar
> e
>> >> >no dead message queues, no rogue gplt processes, and the LD_LIBRARY_PATH
>> >> >is properly set.  When I was having this problem before I got the latest
>> >> >Solaris patches and that seemed to solve the problem.  But, I rebooted t
> he
>> >> >other day and now I'm having the same old problem with the SIGBUS errors
>> >> >and so forth.  Would it be possible for you to get on my system and see 
> if
>> >> >you can find anything?  This problem has been occurring ever since I
>> >> >installed pl15 on my machine.  Please let me know what you think.  Thank
> s.
>> >> >
>> >> >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 Wed, 23 Feb 2000, Unidata Support wrote:
>> >> >
>> >> >> 
>> >> >> Chris,
>> >> >> 
>> >> >> I would suggest checking to make sure you didn't reboot into
>> >> >> a 24bit X configuration using the xdpyinfo command after making
>> >> >> sure that no message queues are hanging around. You might also check t
> hat
>> >  yo
>> >> > ur
>> >> >> LD_LIBRARY_PATH is set- some environmental variables may have been cha
> nge
>> > d.
>> >> >> 
>> >> >> Steve Chiswell
>> >> >> Unidata User Support
>> >> >> 
>> >> >> 
>> >> >> 
>> >> >> 
>> >> >> 
>> >> >> >From: address@hidden (Chris Hennon)
>> >> >> >Organization: .
>> >> >> >Keywords: 200002232021.NAA23701
>> >> >> 
>> >> >> >Steve -
>> >> >> >
>> >> >> >Today I rebooted my machine and now my gf driver is hosed again.  Sam
> e
>> >> >> >symptoms as before, until you copied your gf driver executable into m
> ine
>> > .
>> >> >> >I don't know what to make of this.  Please advise.  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   |
>> >> >> >================================================
>> >> >> >
>> >> >> >On Mon, 7 Feb 2000, Unidata Support wrote:
>> >> >> >
>> >> >> >> 
>> >> >> >> Chris,
>> >> >> >> 
>> >> >> >> I rebuilt the distribution, but get the same results when trying to
>> >> >> >> set the display to shear:0. Sending to my machine here works ok.
>> >> >> >> 
>> >> >> >> I copied over my solaris executable of $GEMEXE/gf (moved the one bu
> ilt
>> >> >> >> on your machine to $GEMEXE/gf.old. All appears to work fine using
>> >> >> >> or copy. You will want to verify this on your own of course.
>> >> >> >> 
>> >> >> >> At this point, this result would lead me to beleive there is someth
> ing
>> >> >> >> in the X server that has either been patched or updated along the w
> ay.
>> >> >> >> I will need to look at the library calls used by gf and see if any
>> >> >> >> patches have been issued along the way. 
>> >> >> >> 
>> >> >> >> I also noticed that your ~ldm/decoders directory still has old vers
> ion
>> > s o
>> >> > f
>> >> >> >> the dc executables in there (from last August, so you will probably
>  wa
>> > nt 
>> >> > to
>> >> >> >> make sure you are running updated version of the decoders).
>> >> >> >> 
>> >> >> >> Steve Chiswell
>> >> >> >> *******************************************************************
> ***
>> > ***
>> >> > ***
>> >> >> >> Unidata User Support                                    UCAR Unidat
> a 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 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/     
>> ****************************************************************************
>> 
>