[MITgcm-devel] help with debugging flags during compilation

[David Ferreira]

Might be worth to run interactively if you can. On one of the machines I use, the STDOUT and STDERR are filled up with a bit lag, and sometimes in case of a crash they remain completely empty while I suspect something happened. In interactive mode, you may see if indeed something happens.
cheers,
david

________________________________
From: MITgcm-devel [mitgcm-devel-bounces at mitgcm.org] on behalf of Matthew Mazloff [mmazloff at ucsd.edu]
Sent: Tuesday, February 27, 2018 11:07 PM
To: <MITgcm-devel at mitgcm.org>
Cc: Bigdeli, Arash
Subject: Re: [MITgcm-devel] help with debugging flags during compilation

Hi An

In my experience this is always due to requesting too much memory (or a node thinking you are requesting too much memory). Does this every happen when you run smaller setups? (Or, perhaps, when you run the same setup but with half the vertical levels?)

-Matt




On Feb 27, 2018, at 5:41 PM, An Nguyen <antnguyen13 at gmail.com<mailto:antnguyen13 at gmail.com>> wrote:

hi Jean-Michel,

Thank you for the suggestion, no I did not run with debugMode=.TRUE. in eedata, I might try that now.  I will use -convert big_endian and -assume byterecl, and -mcmodel=large.

I think the problem we're encountering here is that it's "not working", and we just can not figure out where the mitgcmuv fails, whether it is the mitgcmuv itself or the infrastructure of the computing node that fails.  We do not get any message at all, just "exit" message by the nodes , no STDOUT or STDERR or .err or .out files to even understand where the problem is.  So I would like to run the mitgcmuv (and primarily its _ad version where we have the issue) in the debugging mode to see if I can go line-by-line until it crashes to try to narrow down where the problem is.

Thanks,
An


On Feb 27, 2018, at 8:09 PM, Jean-Michel Campin <jmc at mit.edu<mailto:jmc at mit.edu>> wrote:

Hi An,

I am not sure I understand correctly:
Trying to use the simplest CFLAGS, FFLAGS, FOPTIM setting might not be
the best to compile and run.
For instance, without:
-convert big_endian -assume byterecl
it will not be abble to read any "big-endian" binary, which could be a problem.
Or without:
-mcmodel=medium
it might not run if the memory footprint is too large.

I found that, generally, once I load the right module and set env.variable:
MPI_INC_DIR to correct location,
I can use one of the 3 "standard" optfile:
linux_amd64_gfortran
linux_amd64_ifort11
linux_amd64_ifort+impi
and it just works.
And the improvement that I would get by fine tuning of some of the compiler
options is not very significant (and in my case, not worth spending too much time).

And the nice thing about these ones is that you could use "-ieee" or "-devel"
genmake2 option to turn off all optimisation level (-ieee) or even turn on
all debug option (-devel).

Now in your case, are you running with debugMode=.TRUE., in eedata ?

Cheers,
Jean-Michel

On Tue, Feb 27, 2018 at 04:24:04PM -0500, An Nguyen wrote:
Hello mitgcm gurus,

For the last 2 years I've been having problem with the mitgcm crashing right out of the gate without producing any STDOUT or STDERR or any message at all on the various computing nodes we have at UT Austin, and the only help tech-support can provide us so far is a message saying that we need to do our own debugging.

I'd like to ask for some help with the flags needed to remove all optimization options when compiling the mitgcm (with ifort) in order to enter debug mode such as dbg or this ddt tool they suggested (https://portal.tacc.utexas.edu/software/ddt <https://portal.tacc.utexas.edu/software/ddt>) .  The genmake2 various flags are very elaborate with various options for CFLAGS, FFLAGS, FOPTIM that are really beyond my comprehension (I spent 5 hours last night fiddling around and didn't succeed), so I'm hoping to get some suggestions on what I need to set: would stripping ALL CFLAGS and FFLAGS and FOPTIM and only use

FFLAGS='-g'
FOPTIM='-O0'
CFLAGS=''

an option?  Any suggestion, including a sampled very-stripped-down optfile would be very helpful for me.  I can provide more information (within my comprehension) if needed.

Many thanks,
An

An T Nguyen, Ph.D.
Institute of Computational Engineering and Sciences
The University of Texas at Austin,
201 East 24th Street, POB 4.234,
Austin, TX 78712, USA
Phone: (512) 471-4207
<atnguyen at ices.utexas.edu<mailto:atnguyen at ices.utexas.edu>>


_______________________________________________
MITgcm-devel mailing list
MITgcm-devel at mitgcm.org<mailto:MITgcm-devel at mitgcm.org>
http://mailman.mitgcm.org/mailman/listinfo/mitgcm-devel

_______________________________________________
MITgcm-devel mailing list
MITgcm-devel at mitgcm.org<mailto:MITgcm-devel at mitgcm.org>
http://mailman.mitgcm.org/mailman/listinfo/mitgcm-devel

An T Nguyen, Ph.D.
Institute of Computational Engineering and Sciences
and Jackson School for Geosciences,
The University of Texas at Austin,
201 East 24th Street, POB 4.234,
Austin, TX 78712, USA
Phone: (512) 471-4207
<atnguyen at ices.utexas.edu<mailto:atnguyen at ices.utexas.edu>>

_______________________________________________
MITgcm-devel mailing list
MITgcm-devel at mitgcm.org<mailto:MITgcm-devel at mitgcm.org>
http://mailman.mitgcm.org/mailman/listinfo/mitgcm-devel

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.mitgcm.org/pipermail/mitgcm-devel/attachments/20180228/69591cce/attachment.html>