<html><head></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; color: rgb(0, 0, 0); font-size: 14px; font-family: Calibri, sans-serif; "><div>Hi. &nbsp;I doing runs on Nautilus with some rather large grids, which are not being broken up on more than just a few (2 to 8) MPI processes.</div><div><br></div><div>I'm noticing that there's a grid size of about 385^3 which I can't exceed, without Cactus/Carpet beginning to behave strangely, e.g. AHFinderDirect no longer works, and memory errors abound.</div><div><br></div><div>Obviously there's the possibility that I have errors in the way I specify the grids in my parameter files. &nbsp;But I'm wondering:&nbsp;</div><div><br></div><div>Have other people had success doing "very" large runs on, say, a shared memory architecture where MPI / &nbsp;domain decomposition are not employed? &nbsp; If so, than I've probably just made a mistake in my par file. &nbsp;If not...</div><div><br></div><div><br></div><div>I'm wondering if this has to do with trouble address memory locations, &nbsp;and &nbsp;I notice that the type "int" is used in places, e.g. in the definition of CFINDEX3D,..</div><div><br></div><div><div>static inline int CCTK_GFINDEX3D (const cGH *GH, int i, int j, int k);</div><div>static inline int CCTK_GFINDEX3D (const cGH *GH, int i, int j, int k)</div><div>{</div><div>&nbsp; return (i + GH-&gt;cctk_lsh[0]*(j + GH-&gt;cctk_lsh[1]*k));</div><div>}</div><div><br></div><div>Should these "int" declarations be changed to "long" or "unsigned int" in order to access larger numbers?</div></div><div><br></div><div><br></div><div>Thanks.</div></body></html>