! 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
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)...
--
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
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
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.
--
> 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.
> 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
> 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.