[gradsusr] How to get around gxout grid dying after X t's?

Christopher Gilroy chris.gilroy at gmail.com
Thu Oct 22 10:05:35 EDT 2015


So you wouldn't be able to use lterp on a full-globe .ctl file without
intermediary touching of the file?

ydef 721 linear -90.000000 0.25
xdef 1440 linear 0.000000 0.250000

The only reason I re-grid the var is because without it, it dies on the
first image, presumably because there would be a grid value every .25
degrees, which I could totally see having an issue with, let alone it
wouldn't be read-able.

I suppose I should mention (unless it was apparent, heh) that I use
opengrads instead of grads for a host of other reason but yea.

On Thu, Oct 22, 2015 at 9:40 AM, Jennifer Adams <jma at cola.iges.org> wrote:

> Hi, Chris —
> You are using re(), so I can’t speak for or test any memory leaks that
> might be in that code. I can duplicate what you are doing with re() using
> lterp() instead, and I don’t get any seg faults. Also, you have a ‘set
> font’ command in there, and there is a bug that was fixed in version 2.1.a3
> that was using up memory because the the font files were being
> re-initialized every time a character was drawn. Try using the latest
> version of GrADS and lterp() and see if you are still getting a seg fault.
>
> I created this dummy descriptor file (for a 4-degree grid) and opened is
> as a second data file, alongside the GFS output:
> dset ^foo.bin
> options template
> undef -9.99e8
> xdef 90 linear 2 4
> ydef 45 linear -88 4
> tdef 1 linear 01Jan0001 1dy
> zdef 1 linear 1 1
> vars 1
> foo 0 99 foo
> endvars
>
> And then I tried your expression with lterp:
>
> ga-> var=lterp(500/(60-((tmpprs(lev=500)-273.15 + tmpprs(lev=1000)-273.15
> + tmp2m-273.15)/2)*-3),lat.2(t=1))
>
> And I got a plot (grfill and grid on top) without any error messages or
> ballooning memory size for all time steps in the model run.
> —Jennifer
>
> On Oct 22, 2015, at 7:38 AM, Christopher Gilroy <chris.gilroy at gmail.com>
> wrote:
>
> 'define zcomp = 500/(60-((tmpprs(lev=500)-273.15 + tmpprs(lev=1000)-273.15
> + tmp2m-273.15)/2)*-3)'
>
> 'set gxout grid'
> 'set gridln off'
> 'set dignum 1'
> 'set font 15'
> 'set digsiz 0.10'
> 'set lat 18 62'
> 'set lon -130 -58'
>
> 'd re(zcomp,4)'
>
>
> Makes it to image 25/hour 138 of a loop before grads dies.
>
> I can plot that exact same var shaded without issue, but if I wanted to
> draw it shaded AND gridded, you could see the problem.
>
>
>
> On Thu, Oct 22, 2015 at 2:32 AM, James T. Potemra <jimp at hawaii.edu> wrote:
>
>> How are you plotting?  Could it be you have either a corrupt value, or a
>> really large number somehow in the mix?
>>
>> On 10/21/15 6:16 PM, Christopher Gilroy wrote:
>>
>> So I'm plotting a variable and after about 25 t's (and that's with
>> re(var, 4) even) of a loop grads dies on me with memory allocation. It's
>> not the server. I've tried reinit, clear (which I use at the end of the
>> loop to obviously clear the previous displays) undef, but I can't seem to
>> figure out why it doesn't like running like that.
>>
>> Secondly, whenever I get around to it, the internal memory limit is
>> changeable in the source, correct?
>>
>>
>> _______________________________________________
>> gradsusr mailing listgradsusr at gradsusr.orghttp://gradsusr.org/mailman/listinfo/gradsusr
>>
>>
>>
>> _______________________________________________
>> gradsusr mailing list
>> gradsusr at gradsusr.org
>> http://gradsusr.org/mailman/listinfo/gradsusr
>>
>>
>
>
> --
> -Chris A. Gilroy
> _______________________________________________
> gradsusr mailing list
> gradsusr at gradsusr.org
> http://gradsusr.org/mailman/listinfo/gradsusr
>
>
> --
> Jennifer M. Adams
> Center for Ocean-Land-Atmosphere Studies (COLA)
> 111 Research Hall, Mail Stop 2B3
> George Mason University
> 4400 University Drive
> Fairfax, VA 22030
>
>
>
>
>
>
> _______________________________________________
> gradsusr mailing list
> gradsusr at gradsusr.org
> http://gradsusr.org/mailman/listinfo/gradsusr
>
>


-- 
-Chris A. Gilroy
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://gradsusr.org/pipermail/gradsusr/attachments/20151022/c3b81d5b/attachment-0001.html 


More information about the gradsusr mailing list