I'm having several problems with the Intel "efc" Fortran compilers
adn their documentation on an SGI Altix:

     I want to build the MM5 meteorology model, augmented with
     the MCPL output module (for interfacing with atmospheric
     chemistry and chemical-emissions models).  MM5 is the leading
     research-and-production weather forecast model; MCPL itself
     is a lengthy monolithic (but not terribly complex) code.
     I am trying to work in OpenMP-parallel mode.

     I am working on an SGI Altix "merlin" (RH7.3, 32-processor
     IA-64 box), accessed via "ssh" from an x86 (Fedora Core 1)
     desktop machine "hilbert".

     With the "efc" version 7.1, I get the following results:
     I can build the entire model under any of: "-g" "-O" "-O3".

     When I run it on one processor, all of the builds work.
     When I run it on 2, 4, or 8, all of the builds claim "address
     error" and core-dump, ostensibly within MCPL.  Hand calculation
     says I need 12MB per-thread stack; I've attempted runs with
     that set to 24 MB, 32 MB, and (trying to be ridiculous) 320 MB,
     and all configurations still give that error.

     Moreover, when I attempt to look at the core-file with the Intel
     "idb" debugger, I have problems.  The optimized executables don't
     have enough symbol table information to see what's really going
     on.  The debugger itself core-dumps on the core-file generated
     by the debug-executables.

     With "efc" version 8.0, the model refuses to build -- the problem
     seems to be that Intel's version of "fpp" can't handle "#ifdef".
     And I'm having trouble reading the documentation trying to find
     out how to get around that:

     The docs are ostensibly in HTML, in the same directory tree as
     the compiler binary on "merlin".  When I attempt to look at them
     with "mozilla" on "merlin",  the browser starts up some
     "mozilla-xremote" thing that actually runs "mozilla" on "hilbert".
     I can find no way to get it to display "merlin"-local files
     instead of "hilbert"-local ones.  When I attempt to look at the
     docs with "konqueror", the other browser available on "merlin",
     I find that the HTML is so badly screwed up that "konqueror won't
     display  them.

WHY THE *HELL* CAN'T INTEL WRITE HTML DOCUMENTS IN STANDARD-CONFORMING
HTML, INSTEAD OF SOME SCREWED-UP FORMAT THAT CLAIMS TO BE HTML, BUT
CANNOT BE VIEWED AT ALL ON THE MOST PROBABLE PLATFORM FOR RUNNING THIS
COMPILER SET ??????

Can anyone help me?

-- 

Carlie J. Coats, Jr., Ph.D.                 carlie.coats@baronams.com
Chief Systems Architect
Environmental Modeling Center                    phone: (919)248-9241
Baron Advanced Meteorological Systems              fax: (919)248-9245
3021 Cornwallis Road                                 P. O. Box 110064
Research Triangle Park, N. C.  27709-5064                         USA

"Carlie J. Coats" <carlie@jyarborough.com> wrote in message
news:vURqc.2702$dq4.566@nwrddc01.gnilink.net...
>
> I'm having several problems with the Intel "efc" Fortran compilers
> adn their documentation on an SGI Altix:
>
>      I want to build the MM5 meteorology model, augmented with
>      the MCPL output module (for interfacing with atmospheric
>      chemistry and chemical-emissions models).  MM5 is the leading
>      research-and-production weather forecast model; MCPL itself
>      is a lengthy monolithic (but not terribly complex) code.
>      I am trying to work in OpenMP-parallel mode.
>
>      I am working on an SGI Altix "merlin" (RH7.3, 32-processor
>      IA-64 box), accessed via "ssh" from an x86 (Fedora Core 1)
>      desktop machine "hilbert".
>
>      With the "efc" version 7.1, I get the following results:
>      I can build the entire model under any of: "-g" "-O" "-O3".
>
>      When I run it on one processor, all of the builds work.
>      When I run it on 2, 4, or 8, all of the builds claim "address
>      error" and core-dump, ostensibly within MCPL.  Hand calculation
>      says I need 12MB per-thread stack; I've attempted runs with
>      that set to 24 MB, 32 MB, and (trying to be ridiculous) 320 MB,
>      and all configurations still give that error.
>
>      Moreover, when I attempt to look at the core-file with the Intel
>      "idb" debugger, I have problems.  The optimized executables don't
>      have enough symbol table information to see what's really going
>      on.  The debugger itself core-dumps on the core-file generated
>      by the debug-executables.
>
>      With "efc" version 8.0, the model refuses to build -- the problem
>      seems to be that Intel's version of "fpp" can't handle "#ifdef".
I would not advise attempting OpenMP with a version of ifort 8.0 older than
version 8.0.044 (about 6 weeks old).  Do not use -static link with ifort 8;
that sets a fixed 2MB stack size limit, unless SGI has changed that in their
thread library.  Stack use is likely to be more than you estimate, but
you've covered that.  Do not turn on -p profiling. -O1 -mp is likely the
most reliable level of optimization.  If there is a problem with a current
version, please make use of your premier.intel.com bug report account.  I
think someone at Intel has tackled MM5, but not on the SGI version of linux,
which could be involved.  Please attempt to get your binutils up to date;
the first reliable gnu binutils for IPF came out about 10 months ago.  I
don't know if SGI may have done their own binutils fixes.  With a good
binutils, gdb may sometimes be more helpful than idb.  It's possible you
might be able to build and install gnu binutils separately from your system
installation and set it up to be the linker for ifort, in case that will
narrow down the problem.
>      And I'm having trouble reading the documentation trying to find
>      out how to get around that:
>
The usual way to display the docs when running on IA64 linux is with xpdf
using the .pdf files).  Installation of xpdf is optional on linux distros I
use.

Note that Intel hosts a forum for Intel Fortran, with continual attention
beyond the line of duty from such as Steve Lionel.

Disclaimer:  I can't speak for Intel nor SGI nor anyone else....

In <aISqc.69333$zi3.25335@newssvr25.news.prodigy.com>, Tim Prince:

[Snip...Tim, please trim redundant followup lines...]

> The usual way to display the docs when running on IA64 linux is with xpdf
> using the .pdf files).  Installation of xpdf is optional on linux distros I
> use.

There's also "acroread" (Adobe Acrobat Reader) on most recent Linux distros
(although it may not be installed by default) for typical .pdf files.

I will grant Carlie it's VERY frustrating the distros don't set this up for
a "plugin" (or whatever they want to call it) from gitgo with any installed
browsers (it may be Adobe licensing restrictions; I just dunno).

-- 
Regards, Weird (Harold Stevens) * IMPORTANT EMAIL INFO FOLLOWS *
Pardon any bogus email addresses (wookie) in place for spambots.
Really, it's (wyrd) at airmail, dotted with net. DO NOT SPAM IT.
Standard Disclaimer: These are my opinions not Internet America.

"Tim Prince" <tprince@computer.org> wrote in message
news:aISqc.69333$zi3.25335@newssvr25.news.prodigy.com...

[...]

>
> Disclaimer:  I can't speak for Intel nor SGI nor anyone else....
>

And just who do you speak for?, looks like you don't even speak for
yourself! It's a noted characteristic of your posts that you seldom
respond, so why post?, you're wasting bandwidth and more.

It's regrettable that you don't simply defer to Intel, forum, the sub
premier (<< adequate support www, etc.) instead of encouraging freeloading
Linux types to usurp c.l.f. at the expense of Windows users who underwrite
this so-called open sourer OS as a free lunch for the less-than-deserving
parasites.

-- 
E&OE

Ciao,
Gerry T.
______
"A cynic is one who knows the price of everything and the value of
nothing." -- Oscar Wilde.