Home > Archive > Fortran > April 2007 > F77,F90 Namelist input of logical variables
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
F77,F90 Namelist input of logical variables
|
|
| Brendan 2007-04-18, 8:04 am |
| I have legacy F77(with extensions) code that uses NAMELIST to read in
logical variables(option flags). It will compile under Sun Fortran 95
8.3 Linux_i386 Build27_2 2006/08/02 unless I use the -f77=%all
option. However, at run-time I get the error message: Error
processing NAMELIST. The code compiles perfectly on my PC using
Intel Visual Fortran, but I have to get it to compile on our SunV40z.
The Sun docs do not mention illegal logical variable usage in namelist
input. Does the F90 standard prohibit namelist input of logicals?
Here is my namelist file:
&mdio
MDbase_BaseName = 2007022612
&end
&mdtime
MDsyr_StartYear = 2007
MDsmon_StartMonth = 2
MDsday_StartDay = 26
MDshr_StartHour = 12
MDsmin_StartMinute = 0
MDssec_StartSec = 0
MDmstp_ModelTimeStep = 450
MDistp_IceTimeStep = 450
MDostp_OceanTimeStep = 450
MDastp_AtmosTimeStep = 10800
MDxstp_OutputTimeStep = 3600
MDorst_OceanRestartStep = 86400
MDorbc_OceanReadBCStep = 864000
MDmnum_ModelNumSteps = 384
&end
&MDpcon
MDstar_CompStrength = 25000
MDmode_POMmode = 3
MDspli_POMsplit = 30
&end
&MDflags
ocean_only = .false.
thermodynamics = .true.
dew = .true.
assim_ice = .true.
&end
| |
| Brendan 2007-04-18, 8:04 am |
| Edit:
> It will compile under Sun Fortran 95 8.3 Linux_i386 Build27_2 2006/08/02 unless I use the -f77=%all option.
Should read:
It will compile under Sun Fortran 95 8.3 Linux_i386 Build27_2
2006/08/02 if I use the f90 -f77=%all option.
| |
| Steve Lionel 2007-04-18, 7:05 pm |
| On Apr 18, 8:43 am, Brendan <brendandetra...@yahoo.com> wrote:
> The Sun docs do not mention illegal logical variable usage in namelist
> input. Does the F90 standard prohibit namelist input of logicals?
No, but the standard does require that if the variable you're defining
is of type LOGICAL that the corresponding value be LOGICAL. Your code
tries to assign integer values to LOGICAL variables and thus relies on
an extension in Intel (and DEC and Compaq) Fortran which provides free
conversion between LOGICAL and numeric types. Some other compilers do
not have this extension, and it would seem Sun's is among them.
Let me suggest that the use of LOGICAL for these variables is
inappropriate for your application, Make them INTEGER instead. To be
standard-conforming, all you can do with a LOGICAL value is ask if it
is true or false. Anything else is an extension. I discuss this in a
newsletter article I wrote many years ago -
http://softwarecommunity.intel.com/...ead.aspx#116164
Steve Lionel
Developer Products Division
Intel Corporation
Nashua, NH
User communities for Intel Software Development Products
http://softwareforums.intel.com/
Intel Fortran Support
http://developer.intel.com/software/products/support/
My Fortran blog
http://www.intel.com/software/drfortran
| |
| Dan Nagle 2007-04-18, 7:05 pm |
| Hello,
In addition to Steve's good answer, let me add that
your &end is non-standard. The standard way of ending
a namelist input group is by / the same as list-directed input.
Steve Lionel wrote:
> On Apr 18, 8:43 am, Brendan <brendandetra...@yahoo.com> wrote:
>
>
> No, but the standard does require that if the variable you're defining
> is of type LOGICAL that the corresponding value be LOGICAL. Your code
> tries to assign integer values to LOGICAL variables and thus relies on
> an extension in Intel (and DEC and Compaq) Fortran which provides free
> conversion between LOGICAL and numeric types. Some other compilers do
> not have this extension, and it would seem Sun's is among them.
>
> Let me suggest that the use of LOGICAL for these variables is
> inappropriate for your application, Make them INTEGER instead. To be
> standard-conforming, all you can do with a LOGICAL value is ask if it
> is true or false. Anything else is an extension. I discuss this in a
> newsletter article I wrote many years ago -
> http://softwarecommunity.intel.com/...ead.aspx#116164
>
>
> Steve Lionel
> Developer Products Division
> Intel Corporation
> Nashua, NH
>
> User communities for Intel Software Development Products
> http://softwareforums.intel.com/
> Intel Fortran Support
> http://developer.intel.com/software/products/support/
> My Fortran blog
> http://www.intel.com/software/drfortran
>
--
Dan Nagle
Purple Sage Computing Solutions, Inc.
| |
| Brendan 2007-04-18, 7:05 pm |
| Goodness Steve, you are everwhere! Well the subroutine that reads the
NAMELIST has an INCLUDE that defines the namelist, followed by an
INCLUDE that defines the four logical variables. Perhaps the statement
defining the logicals should precede? The only thing these logicals
are used for are boolean flags and I only operate on them with
X .eqv. .true. and X .eqv. .false. so it makes sense to leave
them as they are.
Thanks for both your replies.
> No, but the standard does require that if the variable you're defining
> is of type LOGICAL that the corresponding value be LOGICAL. Your code
> tries to assign integer values to LOGICAL variables and thus relies on
> an extension in Intel (and DEC and Compaq) Fortran which provides free
> conversion between LOGICAL and numeric types. Some other compilers do
> not have this extension, and it would seem Sun's is among them.
| |
| Brendan 2007-04-18, 7:05 pm |
| The variables are defined as logical in an INCLUDE statement that
precedes the INCLUDE that defines the NAMELIST. I am also only using
the .eqv. operator on the logical variables i.e. using the logicals
as booleans flags. The code compiles and runs under sun f90, but only
without logicals in the NAMELIST. Smells like a bug?
| |
| Steve Lionel 2007-04-18, 7:05 pm |
| On Apr 18, 10:33 am, Brendan <brendandetra...@yahoo.com> wrote:
> Goodness Steve, you are everwhere! Well the subroutine that reads the
> NAMELIST has an INCLUDE that defines the namelist, followed by an
> INCLUDE that defines the four logical variables. Perhaps the statement
> defining the logicals should precede?
No - the order does not matter.
> The only thing these logicals are used for are boolean flags and I only operate on them with
> X .eqv. .true. and X .eqv. .false. so it makes sense to leave them as they are.
EEK! This statement does not jibe with the values I see in the
namelist input, which are various integer values. How integer values
are considered equivalent to true or false is implementation-
dependent. For example, in Intel Fortran, 2 is false but in some
other Fortrans, 2 is true. I suggest you read the article I pointed
to and look more closely to see how these values are used. The values
you showed suggest that the programmer wants to use multiple bits in a
logical value for various purposes, and this is very dangerous.
Steve
| |
| Brendan 2007-04-18, 7:05 pm |
| (Sorry for my double-ish post above. Thought Google groups had botched
the first)
But if you look at the last group in the namelist input you will see:
&MDflags
ocean_only = .false.
thermodynamics = .true.
dew = .true.
assim_ice = .true.
&end
These are logical inputs. My problem(with the Sun compiler) was indeed
the fact that the namelist definition came before the declaration of
the four logical variables. When the code would not compile I tried
setting the compiler option for full f77 compatibility. The code would
compile, but the executable would fail. I have now moved the namelist
definitions below the line that declares the four logical variables.
This compiled without having to set f77 compatibility, and the
executable is running as I type this.
Believe me, I would never, and I mean _never_, use integers for
booleans.
| |
| glen herrmannsfeldt 2007-04-18, 7:05 pm |
| Steve Lionel wrote:
(snip on NAMELIST input)
> EEK! This statement does not jibe with the values I see in the
> namelist input, which are various integer values. How integer values
> are considered equivalent to true or false is implementation-
> dependent. For example, in Intel Fortran, 2 is false but in some
> other Fortrans, 2 is true. I suggest you read the article I pointed
> to and look more closely to see how these values are used. The values
> you showed suggest that the programmer wants to use multiple bits in a
> logical value for various purposes, and this is very dangerous.
It is only the last NAMELIST set that has logical values. I don't
see how you know which are INTEGER and which LOGICAL from the posted
data. It seems, though, that the problem was reading LOGICAL data
and INTEGER variables, due to declaration ordering. I don't know
what the standard says about that ordering, though.
The &END format is the form used by IBM at least as of OS/360, if
not earlier. It may be supported for back compatibility by
other compilers. When did NAMELIST first appear?
-- glen
| |
| Steve Lionel 2007-04-18, 7:05 pm |
| On Apr 18, 1:55 pm, glen herrmannsfeldt <g...@ugcs.caltech.edu> wrote:
> It is only the last NAMELIST set that has logical values. I don't
> see how you know which are INTEGER and which LOGICAL from the posted
> data. It seems, though, that the problem was reading LOGICAL data
> and INTEGER variables, due to declaration ordering. I don't know
> what the standard says about that ordering, though.
Sorry, I didn't spot that. There isn't anything obvious to me wrong
with that part of things. Are the namelists in the same order as
they're read in the program?
> The &END format is the form used by IBM at least as of OS/360, if
> not earlier. It may be supported for back compatibility by
> other compilers. When did NAMELIST first appear?
Actually, IBM used $END, at least back when I was looking at their
implementation for reference when I implemented NAMELIST for VAX
Fortran.
Steve
| |
| jamesgiles@att.net 2007-04-18, 7:05 pm |
| On Apr 18, 11:55 am, glen herrmannsfeldt <g...@ugcs.caltech.edu>
wrote:
....
> It is only the last NAMELIST set that has logical values. I don't
> see how you know which are INTEGER and which LOGICAL from the posted
> data. It seems, though, that the problem was reading LOGICAL data
> and INTEGER variables, due to declaration ordering. I don't know
> what the standard says about that ordering, though.
The standard is fairly restrictive about the order in which things
are declared. Essentially you can't declare something (in this
case, a NAMELIST) that mentions other symbols that haven't
yet been declared. There is one exception: the type name on
a FUNCTION statement may be a derived type that's imported
within the function from a MODULE or even locally declared
in the function.
In this case, I suspect the program did not have IMPLICIT NONE,
and when the NAMELIST was declared it used the implicit types
for those symbols and then didn't back-fill the types when they
were subsequently declared differently.
I'm a little ambivalent about declaration order. I certainly believe
that all declarations should precede executable code. But should
they be allowed more leeway in their relative order. I change my
mind on that frequently.
--
J. Giles
"I conclude that there are two ways of constructing a software
design: One way is to make it so simple that there are obviously
no deficiencies and the other way is to make it so complicated
that there are no obvious deficiencies." -- C. A. R. Hoare
| |
| glen herrmannsfeldt 2007-04-18, 7:05 pm |
| jamesgiles@att.net wrote:
> On Apr 18, 11:55 am, glen herrmannsfeldt <g...@ugcs.caltech.edu>
> wrote:
[color=darkred]
> The standard is fairly restrictive about the order in which things
> are declared. Essentially you can't declare something (in this
> case, a NAMELIST) that mentions other symbols that haven't
> yet been declared. There is one exception: the type name on
> a FUNCTION statement may be a derived type that's imported
> within the function from a MODULE or even locally declared
> in the function.
I probably agree, but I don't think a compiler should completely
ignore the later declaration. Even worse, it might have considered
the variables INTEGER for the NAMELIST statement, and then changed
them to LOGICAL for the rest of the program.
> In this case, I suspect the program did not have IMPLICIT NONE,
> and when the NAMELIST was declared it used the implicit types
> for those symbols and then didn't back-fill the types when they
> were subsequently declared differently.
In some cases you have to be able to do that, or at least
in older versions. Consider DIMENSION and TYPE declarations,
or COMMON and EQUIVALENCE. You can't process such variables
until you have the information from all the statements that are
declaring them.
> I'm a little ambivalent about declaration order. I certainly believe
> that all declarations should precede executable code. But should
> they be allowed more leeway in their relative order. I change my
> mind on that frequently.
From Fortran 2003:
"A namelist group object shall either be accessed by use or host
association or shall have its type, type parameters, and shape
specified by previous specification statements or the procedure
heading in the same scoping unit or by the implicit typing rules
in effect for the scoping unit. If a namelist group object is
typed by the implicit typing rules, its appearance in any subsequent
type declaration statement shall confirm the implied type and type
parameters."
It seems like it failed the last sentence. I don't know if that
requires a diagnostic, either warning or error message.
-- glen
| |
| Richard Maine 2007-04-18, 7:05 pm |
| jamesgiles@att.net <jamesgiles@att.net> wrote:
> The standard is fairly restrictive about the order in which things
> are declared. Essentially you can't declare something (in this
> case, a NAMELIST) that mentions other symbols that haven't
> yet been declared. There is one exception: the type name on
> a FUNCTION statement may be a derived type that's imported
> within the function from a MODULE or even locally declared
> in the function.
I tend to think of it the other way - that the standard is pretty
nonrestrictive, except in several special cases. On the other hand,
those special cases are some of the "important" cases that come up a
lot, so I suppose both viewpoints "work". Do note that the standard does
state it by giving the cases where there are ordering requirements
rather than by stating a general rule.
In fact, I hadn't recalled the one for Namelist. I was going to post
saying that there was no such restriction. Fortunately, I checked before
making a fool of myself (again?). Yes, Namelist is specifically
mentioned as one of the "special cases" where there is an ordering
requirement. Not too hard to find as long as I actually look; last para
of 5.4 in F2003.
So the code in question is nonstandard, with the fairly common result
that it is nonportable. I think it a little "unfriendly" of the compiler
to compile this "incorrectly" without complaint; I'd be tempted to
report it as a "bug". It isn't a bug in the sense that the compiler
violates the standard - just that its handling of the problem isn't very
nice. I'd think that it either ought to compile the code as intended
(and the intent is obvious here), or generate an error message. Doing
both (compiling, but warning about the nonstandard nature) would be ok.
--
Richard Maine | Good judgement comes from experience;
email: last name at domain . net | experience comes from bad judgement.
domain: summertriangle | -- Mark Twain
| |
| Richard Maine 2007-04-18, 7:05 pm |
| glen herrmannsfeldt <gah@ugcs.caltech.edu> wrote:
> From Fortran 2003:
>
> "A namelist group object shall either be accessed by use or host
> association or shall have its type, type parameters, and shape
> specified by previous specification statements or the procedure
> heading in the same scoping unit or by the implicit typing rules
> in effect for the scoping unit. If a namelist group object is
> typed by the implicit typing rules, its appearance in any subsequent
> type declaration statement shall confirm the implied type and type
> parameters."
>
> It seems like it failed the last sentence. I don't know if that
> requires a diagnostic, either warning or error message.
No, the standard doesn't require anything of the compiler there. But I'd
say that quality of implementation does. See my other post.
--
Richard Maine | Good judgement comes from experience;
email: last name at domain . net | experience comes from bad judgement.
domain: summertriangle | -- Mark Twain
| |
| Brendan 2007-04-18, 7:05 pm |
| The sun compiler did give an error message that the namelist have been
previously typed as real. My error was then using the f77 compliance
compiler option which compiled, but the executable failed to read the
namelist input. The namelist input error was trapped, so I did not see
the system's real error message. So at worst there is am error using
namelist with the -f77=%all compiler option with Sun Fortran 95 8.3
Linux_i386 Build27_2 2006/08/02. I recompiled the code with -f77=%all,
but with the aforementioned error trap removed, and ran it again:
****** FORTRAN RUN-TIME SYSTEM ******
Error 1009: no * after repeat count
Location: the READ statement at line 289 of "ciom.f"
I guess the compiler should have generated an error on the namelist
definitions, which is preferable to an obtuse runtime error.
| |
| jamesgiles@att.net 2007-04-18, 7:05 pm |
| On Apr 18, 12:00 pm, nos...@see.signature (Richard Maine) wrote:
> jamesgi...@att.net <jamesgi...@att.net> wrote:
>
> I tend to think of it the other way - that the standard is pretty
> nonrestrictive, except in several special cases. On the other hand,
> those special cases are some of the "important" cases that come up a
> lot, so I suppose both viewpoints "work". Do note that the standard does
> state it by giving the cases where there are ordering requirements
> rather than by stating a general rule.
There is, at least, a general theme to the restrictions. You can't
use an entity in a declaration or attribute specification before the
relevant properties of that entity are themselves specified. You
can't
declare an array X(I,J) before the PARAMETERs I and J are declared
and defined (assuming the possibility that those two steps might be
done in separate statements). You can't use SIZE(X) in the
declaration
of something else until X's shape has been specified (again
recognizing
this can be separately from the declaration of X's type). And so on.
It is this kind of restriction that I think might be usefully
relaxed. Well,
sometimes anyway.
--
J. Giles
"I conclude that there are two ways of constructing a software
design: One way is to make it so simple that there are obviously
no deficiencies and the other way is to make it so complicated
that there are no obvious deficiencies." -- C. A. R. Hoare
| |
| Steve Lionel 2007-04-18, 7:05 pm |
| On Apr 18, 2:00 pm, nos...@see.signature (Richard Maine) wrote:
> In fact, I hadn't recalled the one for Namelist. I was going to post
> saying that there was no such restriction. Fortunately, I checked before
> making a fool of myself (again?).
Ah, if only I had done the same...
I also then realized that the Intel compiler does not complain if you
violate that rule. I have reported that to the development team.
Steve
| |
| robert.corbett@sun.com 2007-04-19, 4:08 am |
| On Apr 18, 11:02 am, nos...@see.signature (Richard Maine) wrote:
> No, the standard doesn't require anything of the compiler there. But I'd
> say that quality of implementation does. See my other post.
Sun f95 gives an error message for this kind of code. The program
NAMELIST /ABC/ X, Y, Z
INTEGER X, Y, Z
END
gets the error messages
INTEGER X, Y, Z
^
"nl.f", Line = 2, Column = 15: ERROR: "X" is specified in a namelist
group, therefore the type is assumed to be REAL.
^
"nl.f", Line = 2, Column = 18: ERROR: "Y" is specified in a namelist
group, therefore the type is assumed to be REAL.
^
"nl.f", Line = 2, Column = 21: ERROR: "Z" is specified in a namelist
group, therefore the type is assumed to be REAL.
Bob Corbett
| |
| robert.corbett@sun.com 2007-04-19, 4:08 am |
| On Apr 18, 6:22 am, Steve Lionel <steve.lio...@intel.com> wrote:
> On Apr 18, 8:43 am, Brendan <brendandetra...@yahoo.com> wrote:
>
>
> No, but the standard does require that if the variable you're defining
> is of type LOGICAL that the corresponding value be LOGICAL. Your code
> tries to assign integer values to LOGICAL variables and thus relies on
> an extension in Intel (and DEC and Compaq) Fortran which provides free
> conversion between LOGICAL and numeric types. Some other compilers do
> not have this extension, and it would seem Sun's is among them.
Sun f95 supports that extension if the option -f77 is specified on the
compiler command line. When the program is compiled without the
option -f77 stricter compliance to the Fortran 95 standard is
enforced.
For example, the program
LOGICAL I, J, K
NAMELIST /ABC/ I, J, K
READ (*, NML=ABC)
PRINT *, I, J, K
END
when run with integer input values for I, J, and K does not produce a
run-time error message. A sample run is
275: ./a.out
&ABC I = 0 J = 1 K = 2
&END
F T T
Note: IEEE floating-point exception traps enabled:
overflow; division by zero; invalid operation;
See the Numerical Computation Guide, ieee_handler(3M)
When I compile the same program without the option -f77 and run it
with the same data, I get
277: ./a.out
&ABC I = 0 J = 1 K = 2
&END
****** FORTRAN RUN-TIME SYSTEM ******
Error 1086: unexpected character in logical value
Location: the READ statement at line 3 of "nl.f"
Unit: *
File: standard input
Input: 0
^
Abort (core dumped)
Note that the caret lines up with the 0 when constant width fonts are
used.
Bob Corbett
| |
| robert.corbett@sun.com 2007-04-19, 4:08 am |
| On Apr 18, 11:28 am, Brendan <brendandetra...@yahoo.com> wrote:
> I guess the compiler should have generated an error on the namelist
> definitions, which is preferable to an obtuse runtime error.
What is the error you think the compiler should diagnose?
Bob Corbett
| |
| glen herrmannsfeldt 2007-04-19, 7:05 pm |
| Richard Maine wrote:
> <robert.corbett@sun.com> wrote:
[color=darkred]
[color=darkred]
[color=darkred]
> I think it should diagnose the error that it apparently, based on other
> posts, does. If I read correctly, the OP ignored that message and just
> tried to change compiler switches to avoid it. That puts it beyond a
> compiler problem in my view.
Yes, the OP should have discovered the problem and fixed it after
the first message. Most compilers don't generate an object program
with errors, but if the compiler does and someone uses it anyway,
yes, that is not the compilers fault.
But there should be no compiler option that results in a variable
having two different types in one program unit. It isn't so obvious
what happened here, but if they compiled as INTEGER for the NAMELIST
and LOGICAL for the rest of the program, I would consider that a
bug, even in F77 mode. (If I remember, that was the option that
was used to avoid the message.) It may be that the standard allows
it, and that it is a quality of implementation question, but
I would say that it is still a bug.
-- glen
| |
| robert.corbett@sun.com 2007-04-19, 10:03 pm |
| On Apr 19, 1:12 pm, glen herrmannsfeldt <g...@ugcs.caltech.edu> wrote:
> Richard Maine wrote:
>
> Yes, the OP should have discovered the problem and fixed it after
> the first message. Most compilers don't generate an object program
> with errors, but if the compiler does and someone uses it anyway,
> yes, that is not the compilers fault.
>
> But there should be no compiler option that results in a variable
> having two different types in one program unit. It isn't so obvious
> what happened here, but if they compiled as INTEGER for the NAMELIST
> and LOGICAL for the rest of the program, I would consider that a
> bug, even in F77 mode. (If I remember, that was the option that
> was used to avoid the message.) It may be that the standard allows
> it, and that it is a quality of implementation question, but
> I would say that it is still a bug.
That is not what happens with Sun f95, even if the option -f77 is
used.
If the -f77 option is used, the variables are given their declared
types,
even if the type declarations appear after the NAMELIST statement.
Semantic processing of the NAMELIST statement does not take place
until after the explicit type declarations have been processed.
Checking
for the standard violation is nothing but extra work for the compiler.
For example, the program
NAMELIST /ABC/ I, J, K
LOGICAL I, J, K
READ (*, NML=ABC)
WRITE (*, NML=ABC)
END
when compiled with the option -f77 and run with the indicated input
data produces
106: ./a.out
&ABC I = 1 J = 0 K = 3
&END
&abc i= T, j= F, k= T
&end
Note: IEEE floating-point exception traps enabled:
overflow; division by zero; invalid operation;
See the Numerical Computation Guide, ieee_handler(3M)
If the compiler thought the variables in the NAMELIST statement were
of type INTEGER, the WRITE statement would write them as integers.
I do not doubt that the OP has run into a problem he would like
solved,
but I still don't know what it is.
Bob Corbett
| |
| Brendan 2007-04-20, 7:04 pm |
| My question would be, does use of the -f77=%all in the Sun95 compiler
allow NAMELIST usage? If it does not, then it should generate a
warning. If it does allow NAMELIST then there is a bug, because the
NAMELIST caused my code to crash. Without the -f77=%all option, it ran
fine.
Either -f77=%all causes a bugged NAMELIST, or the -f77=%all
documentaion should note the effect.
Of course, I could be wrong, but as far as I am concerned -f77=%all
NAMELIST input crashed my code.
| |
| robert.corbett@sun.com 2007-04-20, 10:04 pm |
| On Apr 20, 7:36 am, Brendan <brendandetra...@yahoo.com> wrote:
> My question would be, does use of the -f77=%all in the Sun95 compiler
> allow NAMELIST usage? If it does not, then it should generate a
> warning. If it does allow NAMELIST then there is a bug, because the
> NAMELIST caused my code to crash. Without the -f77=%all option, it ran
> fine.
The output you showed indicated that the program signaled an
I/O error condition because of bad input data. I don't have enough
information about your program to be able to tell if the problem is
with your code and/or data or with our run-time library.
If you e-mail me a copy of a program and input data that shows the
problem, I shall have someone look at it next w .
Bob Corbett
| |
| Brendan 2007-04-24, 7:05 pm |
| On Apr 20, 10:21 pm, robert.corb...@sun.com wrote:
> If you e-mail me a copy of a program and input data that shows the
> problem, I shall have someone look at it next w.
All the data files needed to drive the program are _huge_. I will make
a demo of the problem using the same namelist code, verify whether it
can reproduce the problem, and email it to you sometime in the next
w.
|
|
|
|
|