Strings in Cray namelists? 
Author Message
 Strings in Cray namelists?

Hi,

I'm too tired to shave yet another Yak^1 tonight.
So I thought I'd toss this out and see if you helpful
folk can set me straight...

Intel, PGI, Absoft, g95, gfortran, Lahey, Sun, PathScale, and NAG
are happy with the following, but the Cray compiler (both V6 and V7)
don't seem to like strings in namelists?

% cat > nml.f90 << EOF

program test_nml

    implicit none

    real :: a, b
    character(10) :: string
    integer :: i

    namelist /roger/ a, b, string,  i

    a = 1.0
    b = 2.0e-15
    string = "frank"
    i = 21

    write(*,*) a, b, string, i

    open(8,file='roger.nml')
      write(8,nml=roger)
    close(8)

    write(*,nml=roger)

    open(8,file='roger.nml')
      read(8,nml=roger)
    write(*,nml=roger)

end program

EOF

% ftn nml.f90 && ./a.out

1.,  2.000000007E-15 frank      21
   &ROGER  A = 1., B = 2.000000007E-15, STRING = frank     , I = 21 /

lib-4307 : UNRECOVERABLE library error
    Incorrect namelist input variable "STRING" or
    mismatched input value.

Encountered during a namelist READ from unit 8
Fortran unit 8 is connected to a sequential formatted text file:
    "roger.nml"

Also note the odd manner in which it wrote string during
`write(*,*) a, b, string, i` -- it dropped the commas?

Confused,
--
Bil Kleb
http://www.*-*-*.com/

[1] http://www.*-*-*.com/



Sun, 11 Sep 2011 09:47:47 GMT  
 Strings in Cray namelists?
Hi,

I hate to ask if it's plugged in, but Cray
had namelist before Fortran had namelist, so ...

Is there a new-namelist / old-namelist switch,
and it's set to the old-namelist setting (for
convenience) by default ?

OTOH, you've got the / delimiter, I would expect
the &end delimiter when old-namelist is used.

xlf has a similar capability, and I don't see it
on your list of things-tried.

HTH


Quote:
> Hi,

> I'm too tired to shave yet another Yak^1 tonight.
> So I thought I'd toss this out and see if you helpful
> folk can set me straight...

> Intel, PGI, Absoft, g95, gfortran, Lahey, Sun, PathScale, and NAG
> are happy with the following, but the Cray compiler (both V6 and V7)
> don't seem to like strings in namelists?

> % cat > nml.f90 << EOF

> program test_nml

>     implicit none

>     real :: a, b
>     character(10) :: string
>     integer :: i

>     namelist /roger/ a, b, string,  i

>     a = 1.0
>     b = 2.0e-15
>     string = "frank"
>     i = 21

>     write(*,*) a, b, string, i

>     open(8,file='roger.nml')
>       write(8,nml=roger)
>     close(8)

>     write(*,nml=roger)

>     open(8,file='roger.nml')
>       read(8,nml=roger)
>     write(*,nml=roger)

> end program

> EOF

> % ftn nml.f90 && ./a.out

> 1.,  2.000000007E-15 frank      21
>    &ROGER  A = 1., B = 2.000000007E-15, STRING = frank     , I = 21 /

> lib-4307 : UNRECOVERABLE library error
>     Incorrect namelist input variable "STRING" or
>     mismatched input value.

> Encountered during a namelist READ from unit 8
> Fortran unit 8 is connected to a sequential formatted text file:
>     "roger.nml"

> Also note the odd manner in which it wrote string during
> `write(*,*) a, b, string, i` -- it dropped the commas?

> Confused,

--
Cheers!

Dan Nagle



Sun, 11 Sep 2011 10:15:16 GMT  
 Strings in Cray namelists?

Quote:

> Intel, PGI, Absoft, g95, gfortran, Lahey, Sun, PathScale, and NAG
> are happy with the following, but the Cray compiler (both V6 and V7)
> don't seem to like strings in namelists?

Well, it likes them, but per the standard, they must be delimitted.
Perhaps the other compilers allow undelimitted strings in some cases as
an extension.

Quote:
>    &ROGER  A = 1., B = 2.000000007E-15, STRING = frank     , I = 21 /

> lib-4307 : UNRECOVERABLE library error
>     Incorrect namelist input variable "STRING" or
>     mismatched input value.
...
> Also note the odd manner in which it wrote string during
> `write(*,*) a, b, string, i` -- it dropped the commas?

I assume that by "commas" you mean "quote marks". Yes, the standard
requires that. See the DELIM= specifier in the OPEN statement (or you
can also specify it in the WRITE statement). The default is
delim='NONE'. That default is often handy for list-directed output. For
namelist, it probably isn't as handy, but both list-directed and
namelist share the same setting.

The default setting makes string namelist output invalid as namelist
input. So if you want to use namelist output as subsequent input, and if
you have any strings in the namelist, you need to specify a delim value
other than 'none', at least per the standard. I can't speak to possible
extensions.

--
Richard Maine
email: last name at domain . net
domain: summer-triangle



Sun, 11 Sep 2011 10:41:09 GMT  
 Strings in Cray namelists?

Quote:

> Well, [they] like them, but per the standard, they must be delimitted.

And when Intel, PGI, Absoft, g95, gfortran, Lahey, Sun, PathScale,
and NAG write them, they are delimited.

Quote:
> Perhaps the other compilers allow undelimitted strings in some cases as
> an extension.

I was letting the compiler write and read the namelist, but as
you explain below, the trick seems to be the DELIM= specifier
on the open statement.  It seems odd that Cray would choose
a default where it can't read a namelist it wrote.

Quote:
>> Also note the odd manner in which it wrote string during
>> `write(*,*) a, b, string, i` -- it dropped the commas?

> I assume that by "commas" you mean "quote marks".

No, I meant commas for the output of 'write(*,*) a, b, string, i'.

The Cray gives,

  1.,  2.000000007E-15 frank      21

where say, g95, gives,

   1. 2.E-15 frank      21

which consistently has no commas between values unlike the Cray
which apparently emits them unless surrounding a string?  (Seems
inconsistent.)

  >Yes, the standard

Quote:
> requires that. See the DELIM= specifier in the OPEN statement (or you
> can also specify it in the WRITE statement). The default is
> delim='NONE'. That default is often handy for list-directed output. For
> namelist, it probably isn't as handy, but both list-directed and
> namelist share the same setting.

Ah, ha.  Learn something every day.  Thanks.

Quote:
> The default setting makes string namelist output invalid as namelist
> input.

Bizarre.

Quote:
> So if you want to use namelist output as subsequent input, and if
> you have any strings in the namelist, you need to specify a delim value
> other than 'none', at least per the standard. I can't speak to possible
> extensions.

Wilco.

Thanks,
--
Bil Kleb
http://fun3d.larc.nasa.gov



Sun, 11 Sep 2011 11:06:38 GMT  
 Strings in Cray namelists?

Quote:

> > Well, [they] like them, but per the standard, they must be delimitted.

> And when Intel, PGI, Absoft, g95, gfortran, Lahey, Sun, PathScale,
> and NAG write them, they are delimited.

> > Perhaps the other compilers allow undelimitted strings in some cases as
> > an extension.

> I was letting the compiler write and read the namelist, but as
> you explain below, the trick seems to be the DELIM= specifier
> on the open statement. ?It seems odd that Cray would choose
> a default where it can't read a namelist it wrote.

> >> Also note the odd manner in which it wrote string during
> >> `write(*,*) a, b, string, i` -- it dropped the commas?

> > I assume that by "commas" you mean "quote marks".

> No, I meant commas for the output of 'write(*,*) a, b, string, i'.

> The Cray gives,

> ? 1., ?2.000000007E-15 frank ? ? ?21

> where say, g95, gives,

> ? ?1. 2.E-15 frank ? ? ?21

> which consistently has no commas between values unlike the Cray
> which apparently emits them unless surrounding a string? ?(Seems
> inconsistent.)

> ? >Yes, the standard

> > requires that. See the DELIM= specifier in the OPEN statement (or you
> > can also specify it in the WRITE statement). The default is
> > delim='NONE'. That default is often handy for list-directed output. For
> > namelist, it probably isn't as handy, but both list-directed and
> > namelist share the same setting.

> Ah, ha. ?Learn something every day. ?Thanks.

> > The default setting makes string namelist output invalid as namelist
> > input.

> Bizarre.

> > So if you want to use namelist output as subsequent input, and if
> > you have any strings in the namelist, you need to specify a delim value
> > other than 'none', at least per the standard. I can't speak to possible
> > extensions.

> Wilco.

> Thanks,
> --
> Bil Klebhttp://fun3d.larc.nasa.gov

How about this:
open(unit=lunnml,file=trim
(nmlfile),delim='apostrophe',status='old',iostat=ierr)
Then in the namelist, you put single quotes around all strings.


Sun, 11 Sep 2011 12:13:05 GMT  
 Strings in Cray namelists?

Quote:


> > Well, [they] like them, but per the standard, they must be delimitted.

> And when Intel, PGI, Absoft, g95, gfortran, Lahey, Sun, PathScale,
> and NAG write them, they are delimited.

> > Perhaps the other compilers allow undelimitted strings in some cases as
> > an extension.

> I was letting the compiler write and read the namelist, but as
> you explain below, the trick seems to be the DELIM= specifier
> on the open statement.  It seems odd that Cray would choose
> a default where it can't read a namelist it wrote.

That's not a Cray choice. That's what the standard requires. If the
other compilers write delimitters by default, then they are violating
the standard - at least the f2003 one. I'd have to do some studying to
check earlier ones (and the fine points of whether it applied to all
cases in the earlier standards; there used to be some "wiggle room" for
files not opened with an OPEN statement.)

See 9.4.5.6 of f2003, which makes it pretty explicit that the default is
"NONE". And the second para of 9.4.1 closes all the loopholes for files
that aren't explicitly opened.

Quote:
> >> Also note the odd manner in which it wrote string during
> >> `write(*,*) a, b, string, i` -- it dropped the commas?

> > I assume that by "commas" you mean "quote marks".

> No, I meant commas for the output of 'write(*,*) a, b, string, i'.

> The Cray gives,

>   1.,  2.000000007E-15 frank      21

> where say, g95, gives,

>    1. 2.E-15 frank      21

> which consistently has no commas between values unlike the Cray
> which apparently emits them unless surrounding a string?  (Seems
> inconsistent.)

Oh, that. There are some funny rules relating to commas and undelimitted
strings. I'd have to check to be sure, but it wouldn't surprise me if
the standard requires them to be omitted around undelimitted strings,
but it is a compiler choice elsewhere. Not feeling like studying enough
to be sure right now, but a recall something at least vaguely like that.

--
Richard Maine
email: last name at domain . net
domain: summer-triangle



Sun, 11 Sep 2011 12:14:00 GMT  
 Strings in Cray namelists?

Quote:

> open(unit=lunnml,file=trim
> (nmlfile),delim='apostrophe',status='old',iostat=ierr)

Unrelated to the namelist issue, I notice an oddity in the above open
statement. Well, it perhaps isn't that odd in that lots of people seem
to fall into it, but...

The trim is superfluous. The standard specifies that file names are
trimmed anyway.

--
Richard Maine
email: last name at domain . net
domain: summer-triangle



Sun, 11 Sep 2011 12:17:13 GMT  
 Strings in Cray namelists?

Quote:


>> Well, [they] like them, but per the standard, they must be delimitted.

> And when Intel, PGI, Absoft, g95, gfortran, Lahey, Sun, PathScale,
> and NAG write them, they are delimited.

Not true for Intel by default.  I'd guess it's also not true for most if
not all of the others.  As Richard has said, that would be a standards
violation.

--
Steve Lionel
Developer Products Division
Intel Corporation
Nashua, NH

For email address, replace "invalid" with "com"

User communities for Intel Software Development Products
   http://software.intel.com/en-us/forums/
Intel Fortran Support
   http://support.intel.com/support/performancetools/fortran
My Fortran blog
   http://www.intel.com/software/drfortran



Sun, 11 Sep 2011 23:26:00 GMT  
 Strings in Cray namelists?

Quote:



>>> Well, [they] like them, but per the standard, they must be delimitted.

>> And when Intel, PGI, Absoft, g95, gfortran, Lahey, Sun, PathScale,
>> and NAG write them, they are delimited.

> Not true for Intel by default.

Apparently you're testing another version than me?  (See below.)

Quote:
> I'd guess it's also not true for most if not all of the others.
> As Richard has said, that would be a standards violation.

Being fatigued when I wrote the above, I made a bad assumption per
the Principle of Least Surprise:^1 I had assumed that since our code
was reading quote-delimited namelists successfully with all those
compilers (which is in itself an incorrect assertion because our
gantlet only compiles), that those compilers could write and
read a namelist without the magic delim='quote' specifier, i.e.,
self-consistent behavior w.r.t. writing and reading namelists
containing character strings.

As you and Richard have pointed out, this self-consistent behavior,
as logical as it might seem, would be a standards violation.

The results from testing,

% cat > nml_self_consistency.f90 << EOF
program nml_self_consistency
   character(15) :: string
   namelist /io_nml/ string
   string = "characters"
   open(8,file='nml_io.nml')
     write(8,nml=io_nml)
   rewind(8)
     read(8,nml=io_nml)
   close(8)
end program
EOF

reveal that only Portland, PathScale, and NAG are standards compliant:

% g95 --version | head -1
G95 (GCC 4.0.3 (g95 0.92!) Dec 11 2008)
% g95 nml_self_consistency.f90 && ./a.out && echo $?
0

% ifort -V |& head -1
Intel(R) Fortran Compiler for applications running on Intel(R) 64, Version 10.1    Build 20080801 Package ID: l_fc_p_10.1.018
% ifort nml_self_consistency.f90 && ./a.out && echo $?
0

% ifort -V |& head -1
Intel(R) Fortran Compiler Professional for applications running on IA-32, Version 11.0    Build 20090131 Package ID: l_cprof_p_11.0.081
% ifort nml_self_consistency.f90 && ./a.out && echo $?
0

% nagfor nml_self_consistency.f90 && ./a.out && echo $?
NAG Fortran Compiler Release 5.2(649)
[NAG Fortran Compiler normal termination]
Runtime Error: Unknown group object "CHARACTERS" in input for NAMELIST/IO_NML/
Program terminated by I/O error on unit 8 (File="nml_io.nml",Formatted,Sequential)
Abort

% lf95 --version | head -1
Lahey/Fujitsu Fortran 95 Express Release L6.20d
% lf95 nml_self_consistency.f90 && ./a.out && echo $?
Encountered 0 errors, 0 warnings in file nml_self_consistency.f90.
0

% lf95 --version | head -1
Lahey/Fujitsu Linux64 Fortran Express Release L8.10a
% lf95 nml_self_consistency.f90 && ./a.out && echo $?
Encountered 0 errors, 0 warnings in file nml_self_consistency.f90.
0

% pathf95 -v |& head -1
PathScale(TM) Compiler Suite: Version 3.2
% pathf95 nml_self_consistency.f90 && ./a.out && echo $?

lib-4307 : UNRECOVERABLE library error
   Incorrect namelist input variable "STRING" or
   mismatched input value.

Encountered during a namelist READ from unit 8
Fortran unit 8 is connected to a sequential formatted text file:
   "nml_io.nml"
Abort

% af95 |& tail -1
Absoft 64-bit Fortran 95 10.2.1
% af95 nml_self_consistency.f90 && ./a.out && echo $?
0

% pgf95 -V | head -2 | tail -1
pgf95 8.0-4 64-bit target on x86-64 Linux -tp k8-64
% pgf95 nml_self_consistency.f90 && ./a.out && echo $?
PGFIO-F-239/namelist read/unit=8/entity name is not member of group.
  File name = nml_io.nml    formatted, sequential access   record = 2
  In source file nml_self_consistency.f90, at line number 8

% gfortran --version | head -1
GNU Fortran (GCC) 4.4.0 20080917 (experimental) [trunk revision 140409]
% gfortran nml_self_consistency.f90 && ./a.out && echo $?
0

% sunstudioceres/bin/f95 -V |& head -1
f95: Sun Ceres Fortran 95 8.3 Linux_i386 2008/10/22
% sunstudioceres/bin/f95 nml_self_consistency.f90 && ./a.out && echo $?
0

OMHO, I feel the standard is on the wrong side of history: One should be
able to write and read a namelist containing character strings without
changing the defaults.

Regards,
--
Bil Kleb
http://fun3d.larc.nasa.gov
http://twitter.com/bil_kleb

[1] http://c2.com/cgi/wiki?PrincipleOfLeastSurprise



Mon, 12 Sep 2011 17:51:40 GMT  
 Strings in Cray namelists?

Quote:

> reveal that only Portland, PathScale, and NAG are standards compliant:

Oh, and of course Cray is also compliant:

% crayftn -V
Cray Fortran : Version 7.0.0  Thu Mar 26, 2009  19:33:42
% crayftn nml_self_consistency.f90
% qsub -I
 > aprun -n 1 a.out

lib-4307 : UNRECOVERABLE library error
   Incorrect namelist input variable "STRING" or
   mismatched input value.

Encountered during a namelist READ from unit 8
Fortran unit 8 is connected to a sequential formatted text file:
   "nml_io.nml"
Aborted

Regards,
--
Bil Kleb
http://fun3d.larc.nasa.gov
http://twitter.com/bil_kleb



Tue, 13 Sep 2011 08:40:22 GMT  
 Strings in Cray namelists?

Quote:

> As you and Richard have pointed out, this self-consistent behavior,
> as logical as it might seem, would be a standards violation.

> The results from testing,

> % cat > nml_self_consistency.f90 << EOF
> program nml_self_consistency
>   character(15) :: string
>   namelist /io_nml/ string
>   string = "characters"
>   open(8,file='nml_io.nml')
>     write(8,nml=io_nml)
>   rewind(8)
>     read(8,nml=io_nml)
>   close(8)
> end program
> EOF

> reveal that only Portland, PathScale, and NAG are standards compliant:

No, your test simply reveals that the compilers you use do not support
the Fortran 2003 feature of reading undelimited character strings from
NAMELIST input, as long as they do not contain embedded delimiters.
That PGI and Pathscale have this issue does not astonish me, but that
you see it with NAG does.

To better illustrate the issue, I modified your program as follows:

program nml_self_consistency
   character(15) :: string
   namelist /io_nml/ string
   string = "chara cters"
   open(8,file='nml_io.nml')
     write(8,nml=io_nml)
     write(*,nml=io_nml)
   rewind(8)
     read(8,nml=io_nml)
   close(8)
end program

Here is a build and run with Intel Fortran:

C:\Projects>ifort self_consistency.f90
Intel(R) Visual Fortran Compiler Professional for applications running
on IA-32,
  Version 11.0    Build 20090131 Package ID: w_cprof_p_11.0.072
C:\Projects>self_consistency.exe
  &IO_NML
  STRING  = chara cters
  /
forrtl: severe (18): too many values for NAMELIST variable, unit 8, file
C:\Projects\nml_io.nml, line 2, position 26

Note that the NAMELIST output writes STRING without delimiters, as is
required by the standard, and that without delimiters, the space in the
string is taken for a delimiter and an error occurs.

The standard even has a note on this as follows:

10 Character sequences produced when the delimiter mode has a value of NONE
11 (1) Are not delimited by apostrophes or quotation marks,
12 (2) Are not separated from each other by value separators,
13 (3) Have each internal apostrophe or quotation mark represented
externally by one apostrophe
14 or quotation mark, and
15 (4) Have a blank character inserted by the processor at the beginning
of any record that begins
16 with the continuation of a character sequence from the preceding record.

NOTE 10.39
Namelist output records produced with a DELIM= specifier with a value of
NONE and which contain a character sequence might not be acceptable as
namelist input records.

While we can wish it were otherwise, the standard specifies default
behavior, in the absence of DELIM='QUOTE' or 'APOSTROPHE' in the OPEN,
that character values are written undelimited and that this output may
not be acceptable for input.

--
Steve Lionel
Developer Products Division
Intel Corporation
Nashua, NH

For email address, replace "invalid" with "com"

User communities for Intel Software Development Products
   http://software.intel.com/en-us/forums/
Intel Fortran Support
   http://support.intel.com/support/performancetools/fortran
My Fortran blog
   http://www.intel.com/software/drfortran



Tue, 13 Sep 2011 22:31:42 GMT  
 Strings in Cray namelists?


Quote:
> While we can wish it were otherwise, the standard specifies default
> behavior, in the absence of DELIM='QUOTE' or 'APOSTROPHE' in the OPEN,
> that character values are written undelimited and that this output may
> not be acceptable for input.

Why was this option put into the open statement?  Why wasn't it put
in the write statement (where it seems it might belong)?

$.02 -Ron Shepard



Tue, 13 Sep 2011 23:31:28 GMT  
 Strings in Cray namelists?

Quote:



>> While we can wish it were otherwise, the standard specifies
>> default behavior, in the absence of DELIM='QUOTE' or
>> 'APOSTROPHE' in the OPEN, that character values are written
>> undelimited and that this output may not be acceptable for
>> input.

> Why was this option put into the open statement?  Why wasn't it
> put in the write statement (where it seems it might belong)?

> $.02 -Ron Shepard

My guess is that this was done so that the attribute DELIM=<whatever> should apply to the whole file. Otherwise, one could end up with a file containing a mix of records with different delimiters in each.

-- mecej4



Tue, 13 Sep 2011 23:44:34 GMT  
 Strings in Cray namelists?

Quote:



> > While we can wish it were otherwise, the standard specifies default
> > behavior, in the absence of DELIM='QUOTE' or 'APOSTROPHE' in the OPEN,
> > that character values are written undelimited and that this output may
> > not be acceptable for input.

> Why was this option put into the open statement?  Why wasn't it put
> in the write statement (where it seems it might belong)?

It is there also. That's the case of all (I think it is all - didn't go
check for exceptions) of the changeable modes. The OPEN statement sets a
default for the file, but you can change the value for a particular
read/write statement or even, where applicable (which it isn't for this
one), by a format edit descriptor for finer control within a single
READ/WRITE.

--
Richard Maine
email: last name at domain . net
domain: summer-triangle



Tue, 13 Sep 2011 23:54:43 GMT  
 Strings in Cray namelists?

Quote:


> > reveal that only Portland, PathScale, and NAG are standards compliant:

Adopting an extension is not a violation of the standard. I don't think
you can accuse a compiler of being non-compliant because it actually
works on a program. There are cases where at least a diagnostic
capability is required, but this isn't one of them.

Quote:
> No, your test simply reveals that the compilers you use do not support
> the Fortran 2003 feature of reading undelimited character strings from
> NAMELIST input, as long as they do not contain embedded delimiters.
> That PGI and Pathscale have this issue does not astonish me, but that
> you see it with NAG does.

Are you sure that this f2003 feature applies to namelist? I know about
it for list-directed I/O. At a (very) quick glance, I didn't see it for
namelist. I might well have missed it, but I also wouldn't take for
granted that just because it applies to lisy-directed, that
automatically also means namelist. The two have many similarities, but
namelist does have a few extra issues that one might see as complicating
it.

I don't use namelist any more myself, so I tend to have to read this
stuff pretty carefully. Oddly, I stopped using namelist just a little
before it became standardized. That was because around then I started
using a library of routines that allowed simillarly human-readable
input, but with much more flexibility of form.

--
Richard Maine
email: last name at domain . net
domain: summer-triangle



Wed, 14 Sep 2011 00:09:07 GMT  
 
 [ 19 post ]  Go to page: [1] [2]

 Relevant Pages 

1. help with cray ftn namelist

2. Help on I/O on Cray T3D and Cray C90

3. read string from namelist

4. Strings in namelists? (f90/f77)

5. Fortran/C Interface on Cray (Fortran strings)

6. Ada String Issue: String within Strings

7. string = string(i:j) // string(k:n)

8. Need Help awk namelist programming

9. Namelist omits names

10. Fortran Namelist Package

11. array in namelist

12. array namelist

 

 
Powered by phpBB® Forum Software