Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

elementary parsing in fortran

100 views
Skip to first unread message

Rudra Banerjee

unread,
May 13, 2013, 1:24:07 PM5/13/13
to
Hi, for my calculations, I need to pick up the values of alat, blat,
clat from a line like:

3D unit cell alat=8.069131481 blat=8.069131481 clat=11.432844370

For this I have written a small code as:

read(finp,'(a80)',iostat=ios) flat
if(flat(14:18)=="alat=")then
read(flat(19:29),'(f10.7)')vlat(1)
endif
if(flat(31:35)=="blat=")then
read(flat(36:46),'(f10.7)')vlat(2)
endif
if(flat(48:52)=="clat=")then
read(flat(53:63),'(f10.7)')vlat(3)
endif

which can deal it for a given case.
The problem is, position of "blat=" and "clat=" changes 1 or 2 place
with the value of alat (position of "alat=") is fixed. what i mean is,
for some file, the line is like:
3D unit cell alat=8.069131481 blat=8.069131481 clat=11.432844370
and for some it may be
3D unit cell alat=18.069131481 blat=8.069131481 clat=11.432844370
i.e. shifted by one place.

How can I pick those values?

Arjan

unread,
May 13, 2013, 1:46:30 PM5/13/13
to
> How can I pick those values?

Can you modify the format of the output of the program that generates your input?
If not: use INDEX to get the location of "alat", etc:

locAlat = INDEX(flat,'alat')
locBlat = INDEX(flat,'blat')
locClat = INDEX(flat,'clat')

Then you can read like this:

READ(flat((locAlat+4):(locBlat-1)),*) vlat(1)

Arjan

unread,
May 13, 2013, 1:47:37 PM5/13/13
to
sorry: pressed "send" too early...

dpb

unread,
May 13, 2013, 1:54:18 PM5/13/13
to
On 5/13/2013 12:24 PM, Rudra Banerjee wrote:
> Hi, for my calculations, I need to pick up the values of alat, blat,
> clat from a line like:
>
> 3D unit cell alat=8.069131481 blat=8.069131481 clat=11.432844370
>
> For this I have written a small code as:
>
> read(finp,'(a80)',iostat=ios) flat
> if(flat(14:18)=="alat=")then
> read(flat(19:29),'(f10.7)')vlat(1)
> endif
...

>
> which can deal it for a given case.
> The problem is, position of "blat=" and "clat=" changes 1 or 2 place
...

>
> How can I pick those values?

Use the INDEX() intrinsic to find the location of the strings of
interest in the line instead of fixed positions. You can also switch to
list-directed format ('*') for the internal READ now in case the number
of decimals in the the values is also variable so it's length also changes.

read(finp,'(A)',iostat=ios) flat
i1 = index(flat,'alat=')
read(findp(i1+5:,'(*)') v

Hopefully I didn't make too many typos...seems like I've gotten very bad
at that w/ my advancing years. :(

--

Arjan

unread,
May 13, 2013, 1:55:37 PM5/13/13
to
> How can I pick those values?

Can you modify the format of the output of the program that generates your input?
If not: use INDEX to get the location of "alat", etc:

locAlat = INDEX(flat,'alat')
locBlat = INDEX(flat,'blat')
locClat = INDEX(flat,'clat')

Then you can read like this:

READ(flat((locAlat+5):(locBlat-1)),*) vlat(1)
READ(flat((locBlat+5):(locClat-1)),*) vlat(2)
READ(flat((locClat+5):LEN_TRIM(flat),*) vlat(3)

Your sample code uses a check on the existence of strings alat, blat and clat.
Are these strings always there?
If all lines look like you showed and only the length differs, you might do:

WRITE(flat(1:18),'(A)') ' '
WRITE(flat(INDEX(flat,'blat'):(INDEX(flat,'blat')+4),'(A)') ' '
WRITE(flat(INDEX(flat,'clat'):(INDEX(flat,'clat')+4),'(A)') ' '

to replace all garbage by spaces and then do a regular read:

READ(flat,*) vlat

Regards,


Arjan

Terence

unread,
May 13, 2013, 7:31:24 PM5/13/13
to
>Hi, for my calculations, I need to pick up the values of alat, blat, clat
from a line like:
>3D unit cell alat=8.069131481 blat=8.069131481 clat=11.432844370

Read the data line into a character string using a simple format statement
like (A80).
Use INDEX to find '=' and note the the positions found na,nb,nc..
Write one compound, or three simple, remote format statement(s) to locate
the three real values to be read; e.g. three character strings (naX,F12.9)
with na,nb or nc;
or one compound statement
(naX,F12.9,nb1X,F12.9,nc1X,F12.9)
where nb1 and nc1 are calculated by algebra from na,nb,nc.

Once written, it forms a general case.




Robin Vowels

unread,
May 14, 2013, 6:43:41 AM5/14/13
to
Are you able to make 2 lines for each set of three values,
like this:?

&group
alat=8.069131481 blat=8.069131481 clat=11.432844370 /

If so, you can read these values with the simple statement:

read (10, NML=group)

and the three values are assigned to the variables, alat, blat, clat.
(the names and their values can be in any order.)

where group is defined thus:

NAMELIST / group/ alat, blat, clat

JWM

unread,
May 14, 2013, 7:19:05 PM5/14/13
to

On Tue, 2013-05-14 at 03:43 -0700, Robin Vowels wrote:
> Are you able to make 2 lines for each set of three values,
> like this:?

Why two lines? Simply prefixing with '&namelist-group-name ' and
appending ' /' seems to serve the purpose, e.g.:

implicit none

real :: alat = 0, blat = 0, clat = 0
character(:), allocatable :: flat

namelist /somenml/alat, blat, clat

flat='alat=8.069131481 blat=8.069131481 clat=11.432844370'
flat = '&somenml '//flat//' /'

read (flat, somenml)
write (*, somenml)

end

--
John

Robin Vowels

unread,
May 14, 2013, 10:35:06 PM5/14/13
to
On May 15, 9:19 am, JWM <jwmwal...@gmail.com> wrote:
> On Tue, 2013-05-14 at 03:43 -0700, Robin Vowels wrote:
> > Are you able to make 2 lines for each set of three values,
> > like this:?
>
> Why two lines? Simply prefixing with '&namelist-group-name ' and
> appending ' /' seems to serve the purpose, e.g.:

Simply that examples in Ellis Phillips & Lahey insist that the
& line is separate, and in any case, output is in that form.

Internal I/O with namelist is unacceptable to F95,
so your example below wouldn't compile.

Richard Maine

unread,
May 14, 2013, 11:27:02 PM5/14/13
to
Robin Vowels <robin....@gmail.com> wrote:

> Internal I/O with namelist is unacceptable to F95,
> so your example below wouldn't compile.

"Wouldn't compile" usually needs more qualification to be accurate.

That feature is not in f95, but it is in f2003. F2003 compilers are
admitedly in very short supply. I'm willing to grant that the NAG
compiler counts as an f2003 compiler with some omitted features, because
that's basically how it documents itself. I don't have access to any
other compilers that I'd accord such a description.

Out of curiosity, I decided to give the code a try. (Slightly awkwardly,
as my computers have just been shuffled around, and the one I have the
Fortran compilers on is now my wife's; but I ssh'ed into it for the
purpose.)

NAG compiles and runs it as is with no obvious problems. If I use the
-f95 flag to ask for diagnostics about extensions to f95, I correctly
get 3 warning messages for the 3 non-f95 features in the code. Those
being only warnings, the code still does compile and run correctly.

The other two compilers I tried (g95 and gfortran) bitched about the
allocatable character, which is another feature new to f2003. My copy of
gfortran isn't particularly recent, so that might not reflect current
status. When I changed the allocatable character to a fixed-length
character (and added an invocation of trim to avoid what would otherwise
be a problem with that), both g95 and gfortran compiled and correctly
ran the program.

So, although internal I/O with namelist is not valid f95, it compiled
and even ran correctly on all 3 compilers I tried. The allocatabe
character bit didn't fare so well, working only with NAG.

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

Rudra Banerjee

unread,
May 15, 2013, 4:46:01 AM5/15/13
to
That line is a part of a larger input file, so just transfer it to namelist is not intended.
Arjen and dpb's first two reply did the job for me.

simon

unread,
May 15, 2013, 8:00:32 AM5/15/13
to
On 15/05/2013 04:27, Richard Maine wrote:
> Robin Vowels <robin....@gmail.com> wrote:
>
>> Internal I/O with namelist is unacceptable to F95,
>> so your example below wouldn't compile.
>
> "Wouldn't compile" usually needs more qualification to be accurate.
>
> That feature is not in f95, but it is in f2003. F2003 compilers are
> admittedly in very short supply. I'm willing to grant that the NAG
> compiler counts as an f2003 compiler with some omitted features, because
> that's basically how it documents itself. I don't have access to any
> other compilers that I'd accord such a description.
>


The code compiles and runs with an old Intel compiler (Version
12.1.0.233) as well as the current one (Version 13.1.1.171); the result
(which may or may not be correct) is


&SOMENML
ALAT = 8.069132 ,
BLAT = 8.069132 ,
CLAT = 11.43284
/


Simon

Message has been deleted

Robin Vowels

unread,
May 15, 2013, 8:37:05 AM5/15/13
to
On May 15, 1:27 pm, nos...@see.signature (Richard Maine) wrote:
> Robin Vowels <robin.vow...@gmail.com> wrote:
> > Internal I/O with namelist is unacceptable to F95,
> > so your example below wouldn't compile.
>
> "Wouldn't compile" usually needs more qualification to be accurate.

Here it doesn't. I just gave the reason in the first line above.

> That feature is not in f95, but it is in f2003. F2003 compilers are
> admitedly in very short supply. I'm willing to grant that the NAG
> compiler counts as an f2003 compiler with some omitted features, because
> that's basically how it documents itself. I don't have access to any
> other compilers that I'd accord such a description.
>
> Out of curiosity, I decided to give the code a try. (Slightly awkwardly,
> as my computers have just been shuffled around, and the one I have the
> Fortran compilers on is now my wife's; but I ssh'ed into it for the
> purpose.)
>
> NAG compiles and runs it as is with no obvious problems. If I use the
> -f95 flag to ask for diagnostics about extensions to f95, I correctly
> get 3 warning messages for the 3 non-f95 features in the code. Those
> being only warnings, the code still does compile and run correctly.
>
> The other two compilers I tried (g95 and gfortran) bitched about the
> allocatable character, which is another feature new to f2003. My copy of
> gfortran isn't particularly recent, so that might not reflect current
> status. When I changed the allocatable character to a fixed-length
> character (and added an invocation of trim to avoid what would otherwise
> be a problem with that), both g95 and gfortran compiled and correctly
> ran the program.
>
> So, although internal I/O with namelist is not valid f95, it compiled
> and even ran correctly on all 3 compilers I tried. The allocatabe
> character bit didn't fare so well, working only with NAG.

[FTN95/Win32 Ver. 5.30.0 Copyright (c) Silverfrost Ltd 1993-2009]

0011) read (flat, somenml)
*** The NML option is not permitted with an internal file read

0 new messages