RE: AMBER: nmode calculation

From: Ross Walker <>
Date: Mon, 24 Jan 2005 11:13:59 -0800

Dear Mingche
The problem you have is that on a 32 bit machine, although you have 4 GB of
memory, you can only actually allocate blocks as large as 2GB. Hence trying
to allocate 3.2GB on a 32bit machine will invariably fail. Short of recoding
nmode to use some kind of system that breaks the hessian up into small
blocks and works out where the contents of each block is stored (this would
allow more than 2GB to be used on a 32 bit machine but would require a lot
of work and the resulting code would be 'VERY' slow.) the only other option
is to use a 64 bit machine such as an SGI Altix.
The other problem you have, on the sgi in 64 bit mode, is that the way
memory allocation works, using single pointers, you need a sufficiently big
block of 'Linear' memory. What this means in practice is that your computer
may have 3GB of free memory but only 1.2GB available as a sequential block.
Thus allocation of 1.7GB will fail.
0GB 0.8GB 2.0GB 2.1GB
Maximum allocatable block is 1.2GB. You can test out how much memory is
actually allocatable on your machine by writing a simple c program that
allocates and then frees larger and large blocks of memory. Test the pointer
that malloc returns and as soon as this is null you have hit the maximum
single block of memory that can be allocated.
Are you the only user of the machine? Try doing a complete reboot and then
make sure you login as the only user. You may then be able to allocate a
much bigger block of memory.
So, without a re-write of nmode to use lots of smaller arrays rather than
one big array you are unlikely to be able to run the size of calculation you
want to do on a 32 bit machine or in a multi-user environment on a 64 bit
all the best
|\oss Walker

| Department of Molecular Biology TPC15 |
| The Scripps Research Institute |
| Tel:- +1 858 784 8889 | EMail:- |
| | PGP Key available on request |

Note: Electronic Mail is not secure, has no guarantee of delivery, may not
be read every day, and should not be used for urgent or sensitive issues.


From: [] On Behalf Of
mingche Pan
Sent: 24 January 2005 07:34
Subject: AMBER: nmode calculation

Dear amber users,

I posted this email two days ago, but my last email has been messed up, and
I didn't get any response yet. So I post again.


I'd like to do some nmode calculations. My system is rather big, having 6660
atoms (need ~1.7 G memory with amber6, and ~3.2G memory with amber8). I have
tried different ways on different machines to test nmode compilation and
execution, but no luck. I summarized the testing results as below.


On Dell PowerEdge 1750, 3.2G dual Intel Xeon (32 bits system), 4G memory


MAXMEMX= 110,000,000

Compilation: OK

Execution: OK for small system

MAXMEMX= 120,000,000 - 260,000,000

Compilation: OK

Execution: Segment fault, core dumped by only typing 'nmode' command

MAXMEMX >= 270,000,000
Compilation: failed, "x" is too large to handle, "store_x_" is too large.

Execution: -----


MEMDRV = 400,000,000, MAXATOM = 7000, etc.

Compilation: OK

Execution: failed due to insufficient memory (ASSERTion 'ier == 0' failed in
nmode.f at line 105.)


On SGI, 64bit, 64G memory

Amber6: MAXMEMX= 500,000,000

Compilation: using '-64' instead of '-n32', succeeded!

Execution: works for small system, but core dumped after running my job, but
no Segment fault error by typing 'nmode' command

Amber8: MEMDRV = 400,000,000, MAXATOM = 7000

Compilation: using '-64' instead of '-n32', OK

Execution: works for small system; core dumped again for my system!!!!
Different error message, it says memory available is only 260,000,000 (2G),
asking to increase the memory!!!


My questions are:

Is it possible to get nmode to work with my system on Dell machine?

What is the problem with nmode calculations on SGI machine? How can I get it
to work? (on bo! th machines, I have no limitations of disk and memory

Can anyone give me a hand? Thanks for any suggestion!!



The AMBER Mail Reflector
To post, send mail to
To unsubscribe, send "unsubscribe amber" to
Received on Mon Jan 24 2005 - 19:53:01 PST
Custom Search