mpp_io_read.F90, line 442: 1525-108 Error encountered while attempting to allocate a data object.

362 views
Skip to first unread message

Imran Aziz Ahmed

unread,
Feb 25, 2014, 10:40:53 PM2/25/14
to mom-...@googlegroups.com

Help needed with MOM4 code - mpp_io_read.F90", line 442: 1525-108 Error encountered while attempting to allocate a data object. The program will stop.



Hi folks:

We are facing some issues while executing MOM4. I have pasted the error message above. I have tried all possible flags, but the error persists.

Here's the link which we were trying to follow:
        http://www.pmel.noaa.gov/maillists/tmap/ferret_users/fu_2005/msg01075.html

The code fails at:
     allocate(Axis(ndim))

Can you please tell me if there is any fix for the above problem?

Thanks!

Best regards,
-Imran Aziz Ahmed

Russ Fiedler

unread,
Feb 25, 2014, 11:06:12 PM2/25/14
to mom-...@googlegroups.com

Hi,

This is an IBM system error message.

You are running out of memory and the program can't allocate any more memory.

Here's a link to an IBM FAQ on common errors including yours and how to fix it.

http://www.ibm.com/developerworks/aix/library/au-portfortan.html#mem

The easiest way is to remove the limit before executing the probram.

In bash:

ulimit -s unlimited

csh/tcsh:

unlimit stacksize

There may be other limits involved in your job script. If so, have chat with your system people.

Cheers,
Russ
--
You received this message because you are subscribed to the Google Groups "MOM Users Mailing List" group.
To unsubscribe from this group and stop receiving emails from it, send an email to mom-users+...@googlegroups.com.
To post to this group, send email to mom-...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/mom-users/a47a60e3-6cf3-4cac-8c00-9bdde2c192d5%40googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Stephen Griffies

unread,
Feb 25, 2014, 11:13:27 PM2/25/14
to mom-...@googlegroups.com
Russ,

You are amazing!  

Many thanks for your continued help.

Steve 




Russ Fiedler

unread,
Feb 25, 2014, 11:19:49 PM2/25/14
to mom-...@googlegroups.com
Hi Steve,

I've seen that sort of message often enough to guess what was going on.

It's pretty frustrating though. Copy/paste the error message into a search engine and it came up with the compiler FAQ as the top entry...

Hope things are well with you.

Russ

Imran Aziz Ahmed

unread,
Feb 26, 2014, 12:56:04 AM2/26/14
to mom-...@googlegroups.com
Hi Russ,

Yes, you are right. This is an error from an IBM system. However, setting the stack size to unlimited doesn't solve the issue.

Here's the link which we were trying to follow:
            
http://www.pmel.noaa.gov/maillists/tmap/ferret_users/fu_2005/msg01075.html


Is the bug been resolved? Any other clues, Russ?

We are running out of ideas :-(

Thanks!

Best regards,
-Imran Aziz Ahmed

Nicholas Hannah

unread,
Feb 26, 2014, 1:05:07 AM2/26/14
to mom-...@googlegroups.com
Hi Aziz,

A possibility: MOM is getting confused by the format of a netcdf file you are reading in (indicated by the link you included). In which case the 'ndim' value may be corrupt/bad. The allocate() will then be called with a value which may be too big (which would explain the error you're seeing).

You could try some of the following:

- use print or a debugger to make sure the value being passed to allocate() is reasonable.
- turn or array bounds checking, so that if ndim is bad it will be picked up when indexing into Axis()
- check the format of your netcdf file, check that it doesn't have the problem outlined in the ferret thread. 

Nic

 


Russ Fiedler

unread,
Feb 26, 2014, 1:29:38 AM2/26/14
to mom-...@googlegroups.com
Hi,

I don't think it's anything to do with the format of the netcdf file  unless you are getting a huge value of the dimension. You might want to print out n like Nic suggested.

There's also a utility that lets you know how much memory you are using. You could make a call just before the allocation to see if you are running close to your limits.

In the thread https://groups.google.com/forum/#!topic/mom-users/OiewvCaWigI
in message 6 Zhi suggests tracking memory usage with

-----

  To debug the issue, you may add the following into the code you want to check,

  use memutils_mod,            only: print_memuse_stats

  call print_memuse_stats(text)
Where text is input string of your choice to be used to identify the location of the code.
------

Putting this in the code just before the crash may help.



I think you need to check how much memory you are requesting in your batch job and how much is available. You are probably running into some local system issues.

Information that will help is:
What is the size of you problem how many cpus and how much memory are you requesting?

You systems people should have some log file that may help you.

Cheers,
Russ

Imran Aziz Ahmed

unread,
Feb 26, 2014, 2:20:43 AM2/26/14
to mom-...@googlegroups.com
We are using nearly 256 GB RAM per node and this code fails even on a smaller number of cores (when I used 4 cores per node) :-(


Stephen Griffies

unread,
Feb 26, 2014, 6:48:24 AM2/26/14
to mom-...@googlegroups.com
Hi,

Sorry to ask the obvious at this point, since you likely have much invested in MOM4. But, why are you fussing around with MOM4?  It may be worth moving to MOM5, particularly if you are in a "development" mode.  MOM5 has resolved many system-related issues.  Clearly there will always be more such issues, but it is nice to work with code that presumes to have addressed many of the known issues. 

Stephen 




Russ Fiedler

unread,
Feb 26, 2014, 6:03:31 PM2/26/14
to mom-...@googlegroups.com

As to the netcdf problem that Martin Schmidt brought up about old versions of Ferret/MOM and not having a coordinate axis "bnds" I have some input files which are of the same format that he mentions and mom4p1 has no problems with them at all.

 dimensions:
    grid_x_T = 3600 ;
    bnds = 2 ;
    grid_y_T = 1500 ;
    Time = UNLIMITED ; // (12 currently)
variables:
    double grid_x_T(grid_x_T)
        grid_x_T:long_name = "grid_x_T" ;
        grid_x_T:units = "degree_east" ;
        grid_x_T:modulo = 360. ;
        grid_x_T:point_spacing = "uneven" ;
        grid_x_T:cartesian_axis = "X" ;
        grid_x_T:bounds = "grid_x_T_bnds" ;
    double grid_x_T_bnds(grid_x_T, bnds) ;

and no variable "bnds".

So, yes, it looks like it was fixed in mom4p1 or earlier


Russ

Imran Aziz Ahmed

unread,
Feb 27, 2014, 9:57:34 PM2/27/14
to mom-...@googlegroups.com

thanks a lot for the awesome suggestion stephen! :-)
it's time we moved to MOM5.

best regards,
-i m r a n



Reply all
Reply to author
Forward
0 new messages