[cam-users] 1) compilation error 2) Fortran and C hint/question 3) netCDF 3.5.1 question/hint (4 byte / 8 byte Integer)

[Peter Paul Smolka]

On Mon, 19 Jul 2004, Maisa Rojas Corradi wrote:

> Date: Mon, 19 Jul 2004 11:02:01 -0400 (CLT)
> From: Maisa Rojas Corradi <maisa at dgf.uchile.cl>
> To: cam-users at ucar.edu
> Subject: [cam-users] compilation error
>
> Hello aain,
> I posted this message last week, but didn't get any replay...does someone
> know the answer???
> many thanks!

Synopsis:

1) Answer to the question (compiler options)

2) Question about Timing/ESMF in Fortran, link to an URL
on problems with C (= hopefully not affecting ESMF/Timing).

3) Hint / question regarding the new netCDF 3.5.1.:
Issue mentioned on the 3.5.1. netCDF page "issue related to
passing of eight byte integers solved".

End of synopsis.

Dear Maisa,

1) from the lines you included t_startf_ and related routines have not
been found.

Deducing from CAM2:

There they are part of the timing library around ...bs models bs cam bs
utils ... where bs stands here for backslash or slash depending on
the system used.

There the routines consist of a Fortran part and a C part. The latter
sometimes makes life complicated.

Depending on the compiler you use, script variables like
FORTRANUNDERSCORE or FORTRANDOUBLEUNDERSCORE and related
need to be set (correct name of the routines while linking).

So I would suspect:

1) Experimentelly you might have tried out another architecture.
If yes: Delete the experimental files and recompile/relink using
that, which applied. Then, if you run a script, the recompile should
be done with the right options and the problem is expected to disappear.

2) Your C-Compiler uses the wrong options. Make sure they are passed
correctly. In one of the top-level scripts, around defining
the compilers, the option string is set.

3) Not all Fortran Compilers run smoothly with C, at least with the
C that is provided (e.g. Fortran Compilers that come with a C
companion).

In case you use gcc: There are (man gcc) options for a variety
of architectures including underscore issues.

Before you consider translating the timing-library to Fortran
try CAM3.0. There messages (regarding C) that appeared in CAM2.0
disappeared (all except one which currently is chased).

ad 2) Timing/ESMF in Fortran

Results on the CAM30 library (speed) cannot yet be reported.
>From above translation-work the fairly large number of calls to
timing routines might accumulate over long runs (deduced from
other programs that call timing routines frequently).

A quantitative measurement of that with CAM/CSM has not yet been made.

If anybody is aware of the timing-library and/or the parts of ESMF
that are used by CSM/CAM translated to Fortran he/she is cordially
invited to post this as well.

Regarding possible sorrows on numerical glitches in C (hopefully they do
not propagate into the model):

Relevant the sections (2nd half of the article from the URL):

"Is an Operator Allowed to Alter its Operands?"

and

"Something to do with Mathematics"

The article was presented as talk on the IBM Share users conference.

As one, quite important, part (timing, ESMF) is written in C
it might be considered whether the mentioned phenomena may or may not
affect the results from CSM/CAM.

http://www.uni-muenster.de/ZIV/Mitarbeiter/EberhardSturm/PL1andC.html

Only thoughts regarding C are relevant, e.g. whether the phenomena
apply to ESMF/Timing y/n.

Summary regarding point (2):

ESMF/Timing also available in Fortran (e.g. both)?

Phenomena apply to ESMF/Timing y/n?

Or: Disappeared with CSM/CAM 30 y/n:


3) netCDF 4 byte / 8 byte integer (3.5.1)

Related: On the web-page regarding netCDF (new version 3.5.1) it is
stated under improved issues: Link between INTEGER*8 and netCDF
variables.

As four-byte / eight-byte issues _can_ cause problems:

Is it only a speed issue, e.g. the data have been passed correctly
but suboptimal in the past?

Or:

Is a recompile of netCDF needed, e.g. a migration to the new version?

Best regards, Peter

>
> ---------------------------- Original Message ----------------------------
> Subject: compilation error
> From:    maisa at dgf.uchile.cl
> Date:    Thu, July 15, 2004 10:02 am
> To:      cam-users at ucar.edu
> --------------------------------------------------------------------------
>
> Hello,
> I am trying to compile CAM on our linux cluster with portland group
> fortran. and I get the following error when trying to link all the **.o
> files:
>
> atm_lndMod.o(.text+0x4de): undefined reference to `t_startf_'
> ....
>
>
> ..
>
> wrap_mpi.o(.text+0x19bb): undefined reference to `t_startf_'
> wrap_mpi.o(.text+0x1aa6): undefined reference to `t_stopf_'
>
>
>
> is t_start and t_stop a function/subroutine from CAM or should it be in
> one of the libraries on the system???
>
> thanks,
> Maisa
>
>
>
> --
> Maisa Rojas Corradi
> Departamento de Geofisica
> Universidad de Chile
> Blanco Encalada 2002
> Tel: 678 43 11
> _______________________________________________
> cam-users mailing list
> cam-users at ucar.edu
> http://mailman.ucar.edu/mailman/listinfo/cam-users
>

**********************************************************************
Dr. Peter P. Smolka
University Muenster
Geological Institute
Corrensstr. 24
D-48149 Muenster

Tel.: +49/251/833-3989   +49/2533/4401
Fax:  +49/251/833-3989   +49/2533/4401
E-Mail: smolka at uni-muenster.de
E-Mail: PSmolka at T-Online.de
**********************************************************************