Re: - exceeding 32-bit counting?

I'm reading all of it in with -R. I have 32gb of memory on the system.
I close all applications/processes before hand, run purge from shell,
and check with top (usually abut 30 gb free).

Example failure

grdimage: project grid files
grdimage: Grid projection from size 0x0 to 44051x50973
GMT_grd_is_global: no!
GMT_boundcond_param_prep determined edgeinfo: gn = 0, gs = 0, nxp = 0, nyp = 0
GMT Fatal Error: GMT_grd_project requesting negative n_items
(-2049555673) - exceeding 32-bit counting?
grdimage: Allocates memory and read data file

1000 dpi works, 1100 does not. I need the product to be 1250
dpi.......so I'm stuck at this wall.

On Sun, Feb 16, 2014 at 7:38 PM, Paul Wessel <[email protected]> wrote:
> Hard to tell without the verbose output but you mentioned earlier your grid is 17 Gb.  Depending on -R you are reading a small/huge portion of that into memory.  Then you are adding those 8 Gbs to hold the rgb array. If it is close to holding the 17 Gb grid then you need 25 Gb to do this job, plus then some.  Other things running at the same time (browsers, mailtool, etc) also consumes memory.  Do you have 32 Gb+  I.e., can we rule out lack of physical memory?  I mean, if you change the dpi and at beyond 1000 it bails I would think that is the reason.  Are you being literal, i.e., that dpi = 1001 fails but 1000 works?
>
> -p
>
> On Feb 16, 2014, at 2:23 PM, andrealphus <[email protected]> wrote:
>
>> So, knowing for sure that I'm on a 64bit OS, with 64bit GMT, any
>> suggestions on what could be causing this or how to track it down?
>>
>> uname -a
>> Darwin maukapuu_static.home 10.8.0 Darwin Kernel Version 10.8.0: Tue
>> Jun  7 16:32:41 PDT 2011; root:xnu-1504.15.3~1/RELEASE_X86_64 x86_64
>> i386 MacPro5,1 Darwin
>>
>> file `which grdimage`
>> /global/gmt/bin/grdimage: Mach-O 64-bit x86_64 executable
>>
>> On Wed, Feb 12, 2014 at 1:24 PM, andrealphus <[email protected]> wrote:
>>> Hi Paul,
>>>
>>> Yea I didnt think converting the grid to an nd would do anything, but
>>> knowing I'm running a 64 bit kernel, and a 64 bit grdview executable,
>>> I started looking for anything.
>>>
>>> Yup, I'm aware of the large memory issues - I'm ok with it (so is my
>>> system......errr....usually).
>>>
>>>
>>>
>>> On Wed, Feb 12, 2014 at 11:51 AM, Paul Wessel <[email protected]> wrote:
>>>> For got to say that given your -J -E settings, regardless of what memory is required to just read your grid into memory, the implied r/g/b array for the image that is also allocated would be close to 8Gb of memory alone. [ 3 x (35.4088 * 1250) x (50 * 1250)].
>>>> -p
>>>>
>>>> On Feb 12, 2014, at 6:08 AM, andrealphus <[email protected]> wrote:
>>>>
>>>>> I've seen a few posts regarding this error, but nothing that seemed to
>>>>> relate....
>>>>>
>>>>> command;
>>>>>
>>>>> ...
>>>>> grdimage $GRD $region -JX35.4088i/50i -C$CPT -E1250 -Q -V -K -O >> $psfile
>>>>> ...
>>>>>
>>>>>
>>>>> it fails at this grdimage call if the resoultion is set to anything
>>>>> greater than 1000 (with the given media size, which is the same as the
>>>>> JX size).
>>>>>
>>>>> The grid its calling ($GRD) is large (17 gb), and I originally thought
>>>>> the issue was because it was a default .grd (format #18), which is 32
>>>>> bit, yes?
>>>>>
>>>>> I reformatted this to a netcdf double 64 bit (format #19), via;
>>>>>
>>>>> grdreformat -V ARCTIC_40m_PS_75N_xyz.grd ARCTIC_40m_PS_75N_xyz_64b.nd=nd
>>>>>
>>>>> And tried the above grdimage call again......same error.
>>>>>
>>>>> Any idea?
>>>>>
>>>>> -ashton
>>>>>
>>>>> To unsubscribe, send the message "signoff gmt-help" to [email protected]
>>>>
>>>> To unsubscribe, send the message "signoff gmt-help" to [email protected]
>>
>> To unsubscribe, send the message "signoff gmt-help" to [email protected]
>
> To unsubscribe, send the message "signoff gmt-help" to [email protected]

To unsubscribe, send the message "signoff gmt-help" to [email protected]