array too large to handle

[GerritGroot]

Hi all,

I've got a problem with some matrices that according to the compilers I tried "are too large to handle," although I'm nearly sure that I've got enough RAM memomry to allocate these matrices (about 3 Gig).

The code doesn't compile, with Microsoft's Developer Studio, not with G77 and neither with OpenWatcom.

Is there any, preferably free, compiler that will do?
Or am I doing somethig else wrong in the declarations?

Thank you in advance,

Gerrit

 

[xwb]

Most compilers will only cope with a 1Gb heap and a 1Gb stack so having lots of memory may not solve your problem. 1) Do you know which declarations are giving your problems?
2) Have you tried smaller sizes?

 

[GerritGroot]

Yeah, with smaller sizes the code works perfectly. The point is that for the current application I cannot reduce the size.

Even compiling on a virtual memory disk or whatsoever would be okay for me (time for an extra coffee or compilation at night or so)

Is there a way to use the memory that's available and to get over the limitations of the compiler?

 

[gummibaer]

I do not have any experience in this matter but checked on the Salford documentation.

There are routines to handle memory from the storage heap. And the linker has - as far as I understand it - an option to define heap reserve. However I could not find any reference to any limitations.

I do not know if this could be of use to you.

The Salford package is available in a free personal edition. This is a full version licensed for personal use only and not licensed for research and commercial use.

Norbert

 

[GerritGroot]

Hi,

I downloaded the Salford compiler and compiled the code at the dos prompt (it seems a program without GUI).

It's running, but during runtime it changes values of variables in a non-expected way, even parameters are changed.

The code has been checked thoroughly and runs perfect for smaller matrices, so it seems that the out of memory is making fortran getting crazy (it spite of the fact that it's running).

Any ideas how to increase the allowed memory in this compiler (or in any other)?

I appreciate any help,

Gerrit

 

[gullipe]

Hello

How big are your matices?? I have at least once used HUGE descriptor to indicate that the array is bigger than ca 64000 bytes (bigger than one segment):

byte vbits[HUGE](2000000)

and that worked well in the Microsoft Fortan compiler that I use. I also increased the stack and segment size by using the following switches in the linker:

link /stack:11520 /seg:240 ....

but maybe you cannot use this in the Salford compiler.

Best wishes
GulliPe

 

[GerritGroot]

Hi,

I included [HUGE] in Microsoft's Developer Studio the way you do in your example, like for example:

INTEGER mxi
PARAMETER(mxi=10000)
REAL xr[HUGE](mxi)

, but I get the warning message: "obsolete attribute HUGE"

It seems that I understood you wrong, the program compiles with some warnigs now, but doesn't work, like before.

I didn't find linker switches so far and wonder whether this switch exists as well in G77.

What's the differende between stack and segment anyway?

If this happens to be beyond the scope of this forum, please refer me to some documentation on the web.

Thanks,

Gerrit

 

[gullipe]

Hi Gerrit

A real array of 10000 elements is not much and does not need a HUGE descriptor (I think). Is it possible that you are reading or writing past the end of some array? Your statement "It's running, but during runtime it changes values of variables in a non-expected way, even parameters are changed" could indicate that.

Best wishes
GulliPe

 

[GerritGroot]

I see, so there must be an error in the code then.
Still wondering why it works prefectly for smaller matrices though.

The specification is the following:

PARAMETER (mgem= 3)
PARAMETER (mpoi= 40026)
PARAMETER (mpan= 39762)
PARAMETER (mpte= 147)
PARAMETER (mepo= 4)
PARAMETER (mepa= 1)
PARAMETER (mmax= 15360)
PARAMETER (mseg= 79782)

COMMON/geomet/npoi (mgem),npan (mgem),nstr (mgem),
& pptc (3,mpoi),ncon (4,mpan),
& nwak (3,mpte),
& cptc (3,mpan),pnov (3,mpan),
& area (mpan)
COMMON/refval/aref (mgem),dlon (mgem),
& dlat (mgem),vref (mgem)
COMMON/bodfrm/cmrp (3,mgem),orgn (3,mgem),
& orgv (3,mgem),
& eula (3,mgem),eulv (3,mgem)
COMMON/singul/ddst (mpan),sdst (mmax)
COMMON/extpts/eptc (3,mepo),neco (4,mepa),
& epot (mepo),eol1 (mepo),
& eol2 (mepo),
& eptv (3,mepo),expr (mepo)
COMMON/matrix/acof (mmax,mmax),bcof (mmax),
& indx (mmax)
COMMON/vorlin/nvor (2,mseg),nasc (2,mseg),
& gamm (mseg)
COMMON/trledg/kvr1 (mpte),kvr2 (mpte),
& kedg (mpte+mgem),
& kmu1 (mpte),kmu2 (mpte),
& kctu (mpte+mgem),
& kmd1 (mpte),kmd2 (mpte),
& kctd (mpte+mgem)
COMMON/kinemt/cptv (3,mmax),
& cppv (3,mmax),
& cpds (mmax)
COMMON/wakevl/ptol (3,mpoi),ptve (3,mpoi)
COMMON/sigma/bsig (mmax),asig (mmax,mmax)
COMMON/solut/bsol (mmax),div,iadd (mmax)
COMMON/symmet/iflmat,isym,geoang (mgem)
COMMON/geotip/rmax,fiang

If this is not asking for too much to the compiler, according to the experts here, I am afraid I'll have to look in the code again, oofff :-( That's a tough conclusion!

Thanks and regards.

Gerrit

 

[GerritGroot]

Just thinking about it. If the matrix is not too large and it's an error in the code indeed, it doesn't explan why g77 says "arrays too large to handle" at the moment of compiling it.

Does ayone know what the difference is between stack memory and segment memory and how to change that in g77?

Sorry, I'm just a technical user...

Gerrit

 

[gummibaer]

Well, I do mot know if you have some bug in your code such as exceeding declaration limits, but the array acof(mmax,mmax) in /matrix/ seems pretty large. 15360 x 15360 elements of real*4 (I assume) is near to 944 Mbyte of memory. Same for asig in common block /sigma/. This would sum up to be near to 2Gbyte not counting the minor arrays.

What do you do with these arrays ? Is this a FEA ? Do you need all those arrays - especially acof and asig - at the same time ? Do the matrizes have a special shape, that is e.g. only the elemts on the diagonal are different from 0 or other ?

Norbert

 

[GerritGroot]

It could be programmed a bit more efficient, but the code was already half written so I was forced to continue with this. Nevertheless, looking at the physics behind the problem, changing the code I wouldn't win that much memory either (it's not FEA).

Thanks anyway, I appreciate all the help I use to get on this forum.

Maybe someone knows whether there's an option in g77 to allocate more memory. Is there?

Thanks,

Gerrit