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

FORTRAN 90/95 program reading .dat file (\\ force line continuation)

52 views
Skip to first unread message

James

unread,
Jun 29, 2009, 3:33:11 PM6/29/09
to
Hi, I have a problem with a Fortran 90/95 program reading a data file.
I compiled the code with gfortran with -03 optimization. The program
is supposed to read a .dat file with variables and values specified in
it. The program stops and gives the following report:


! WET/DRY PARAMETERS
! # WET/DRY TREATMENT : ACTIVE
==================ERROR==================================
DATA LINE 237 MUST CONTAIN "="
=========================================================


So I looked in the data file at line 237. Here are a few lines from
the data file that surround Line 237:


!=====VARIABLES for SPECIFY DYE RELEASE
DYE_ON = F
IINT_SPE_DYE_B = 390962 !391051
IINT_SPE_DYE_E = 390970 !391140
KSPE_DYE = 30
K_SPECIFY = 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 \\
16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 <-------
THIS IS LINE 237
MSPE_DYE = 29


The program seems to have trouble recognizing the \\ which should
indicate to continue reading values for K_SPECIFY on the next line.
Any suggestions into this problem is greatly appreciated!

Thanks so much.

Regards,

James

Alois Steindl

unread,
Jun 29, 2009, 3:49:28 PM6/29/09
to
James schrieb:
Hello,
without knowing the details of this program, it seems to be impossible
to give any help. Since this issue has nothing to do with Fortran syntax
(the program assumes a certain structure of the input data, but that is
not related in any way to Fortran), you will have to look at the code
very closely, to see, how line breaks are handled.
You could also derive some hints from other circumstances (did the
program run successfully on different systems/compilers with these
data?), but these cannot be guessed from the vague description in your
posting.
(I could imagine, that line ending might be one possible reason, if you
ported code and data between different systems.)
In this special case I would bet that the optimization option has no
influence at all, but you could try of course, whether it matters.
Good luck
Alois

dpb

unread,
Jun 29, 2009, 3:52:00 PM6/29/09
to
James wrote:
> Hi, I have a problem with a Fortran 90/95 program reading a data file.
> I compiled the code with gfortran with -03 optimization. The program
> is supposed to read a .dat file with variables and values specified in
> it. The program stops and gives the following report:
>
...

> So I looked in the data file at line 237. Here are a few lines from
> the data file that surround Line 237:
...

> KSPE_DYE = 30
> K_SPECIFY = 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 \\
> 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 <-------
> THIS IS LINE 237
> MSPE_DYE = 29
>
>
> The program seems to have trouble recognizing the \\ which should
> indicate to continue reading values for K_SPECIFY on the next line.
> Any suggestions into this problem is greatly appreciated!
...

No telling--would have to see the actual code reading/parsing the file
to have any clue as to whether it's a coding problem or that, in fact,
the data file isn't following the prescribed rules.

If this is an existing code, I'd lay odds on the latter...

Simplest workaround might be to eliminate the supposed continuation and
see if it will handle the longer records.

If that also fails, you'll either need to read the input description w/
the code more carefully or, if it really is "\\" that is expected for a
continuation of a record input.

"\" isn't in the F95 character set, but it should be allowed in
input/output records, character variables, etc., so it doesn't seem that
should be the problem.

It looks kinda' like a NAMELIST-type processing, but isn't Standard
NAMELIST formatting so unless the input file was written for a
nonStandard form of namelist it still seems more likely to me its driver
error rather than code. But, then again, there's nothing to prove that;
just hunch (won't even go quite so far as to say I looked in the crystal
ball)...

--

steve

unread,
Jun 29, 2009, 4:01:34 PM6/29/09
to

With the info given, I'm guessing that you are reading a namelist.
Remove the \\ and concatenate the 2 lines into one long line
might work (without any code it's hard to guess).

PS: A search of the Fortran 95 standard found neither 'backslash' nor
'\\', which suggest that your usage is a vendor extension for a
compiler
other than gfortran.

--
steve

James

unread,
Jun 29, 2009, 4:41:08 PM6/29/09
to
Thanks to everyone for the answers so far.

Yes, the code was already written, which states to use \\ as the line
continuation. I was thinking about finding another compiler to use
too. I will try and remove the \\ completely. The only reason I was
trying to keep the character was because the FVCOM manual specifies it
can only read 80 characters in a line. But I will try anyway and see.

What do you normally use if you have a long string of data for one
variable? What is normally used in Fortran 90/95 to force the line
continuation?

Thanks again.

--James

dpb

unread,
Jun 29, 2009, 4:50:38 PM6/29/09
to
...
For input files there isn't anything like a built-in continuation mark
as there is for source files; it's something the application has to handle.

It seems peculiar there would be problems -- oh, wild thought w/o
looking at first posting again...

Any chance the "\\" is supposed to be in columns 79-80, say, or some
other such rules? Also don't guess it would hurt to check for any stray
non-printing characters in the file on the offending line just to make
sure...

I think you'll really need to look at the code that's doing the input
processing; it appears it's reading the input file line-by-line into a
character variable (or, perhaps somewhere in there is the problem that
the code's so old it's using some vendor-specific processing that
doesn't have same behavior...but all of that is just guessing w/o the
code to look at.

--

David Duffy

unread,
Jun 29, 2009, 5:49:13 PM6/29/09
to
dpb <no...@non.net> wrote:
> James wrote:
>> Thanks to everyone for the answers so far.
>>
>> Yes, the code was already written, which states to use \\ as the line
>> continuation.

> Any chance the "\\" is supposed to be in columns 79-80, say, or some
> other such rules?

Is the "\\" perhaps escaping the backslash? Have you tried a single
backslash?

David Duffy.

Richard Maine

unread,
Jun 29, 2009, 8:27:40 PM6/29/09
to
James <bryan...@gmail.com> wrote:

> Hi, I have a problem with a Fortran 90/95 program reading a data file.
> I compiled the code with gfortran with -03 optimization. The program
> is supposed to read a .dat file with variables and values specified in
> it. The program stops and gives the following report:
>
>
> ! WET/DRY PARAMETERS
> ! # WET/DRY TREATMENT : ACTIVE
> ==================ERROR==================================
> DATA LINE 237 MUST CONTAIN "="
> =========================================================

...


> K_SPECIFY = 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 \\
> 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 <-------

...


> The program seems to have trouble recognizing the \\ which should
> indicate to continue reading values for K_SPECIFY on the next line.
> Any suggestions into this problem is greatly appreciated!

It simply isn't worth trying to guess from the lack of data given. This
isn't a Fortran question. Fortran doesn't have any such feature as input
data line continuation like that. This is presumably something done by
the code of the program you have. Without seeing that code, there isn't
enough data here to even make an educated guess. On occasion, my crystal
ball has been able to magically come up with a guess without having any
data, but the ball seems to be cloudy today.

--
Richard Maine | Good judgment comes from experience;
email: last name at domain . net | experience comes from bad judgment.
domain: summertriangle | -- Mark Twain

OldSchool

unread,
Jun 30, 2009, 11:51:17 AM6/30/09
to
> The program seems to have trouble recognizing the \\ which should indicate to continue reading values for K_SPECIFY on the next line.

> trying to keep the character was because the FVCOM manual specifies it can only read 80 characters in a line.

From the information above, your issue appears to be with FVCOM
(finite volume coastal ocean model), and how it works. I would not
expect a change in compilers to fix this, althought I'd suppose that
it (fvcom) could be relying on extensions or undocumented behaviour of
a specific compiler. That, hopefully, would not be the case.

0 new messages