Hollerith problem

[mrvcj]

Hi guys,

I'm compiling a old FORTRAN code for my research using Intel Composer XE 2011 command line. I got whole bunch of errors saying: end of statement found while lexing a hollerith constant. I have no idea about this but it comes from the old format?

I'm wondering if you know how to fix this. Or at least how to ignore it when compiling. It works fine when I was using Lahey compiler. Any compiling options I can use? Thanks very much for your time.

Regards,

Jason

BTW, you may find the source code in the attachment if that helps.

[TimP]

You are depending on an extension to Fortran 66, which, if it had been standard, would fall in the deleted features category. However, it seems that ifort will accept those Hollerith constants if you append enough blanks to cover the specified string length.

[mecej4]

Hollerith constants have been "deleted" from Fortran 77 on, but you still have them. They are completely gone from the Fortran standard, so you should convert them to standard quoted strings. As a stop-gap measure, use a text editor that does not trim trailing blanks and make sure that the required numbers of blanks are present before the CR/LF on the offending lines.

Your program would have worked better if it were on punched cards, since the end of the card is always after Col. 80 and there is no removal of trailing blanks from a card!

[Steven_L_Intel1]

/pad_source is the option you want. By default, the Intel compiler honors short records in fixed-form source. Adding /pad_source pads the short lines with blanks out to column 72 (or 80 or 132 depending on other options.) In Visual Studio, this is Language > Pad fixed-form source lines.

The Fortran standard assumes that all fixed-form source lines are 72 characters exactly.

[bmchenry]

took a quick look at the code, ahhhh...memories...
you have already implemented some of the changed required.
get a good text editor (www.textpad.com) and simply go through it and replace all the XXH with '
and then put another one ' by the comma that is the end of the string
simple, boring, time consuming, but once done, you're done.
And of course there are a lot of better format tricks to purdy up your output (like you'll also want to eliminate all the 'Fortran line feed characters' like 0, 1, etc which used to be interpreted as page feed, line feed, etc.
Since i would guess you'll be writing to a file rather than a printer?

A good starting point is do a search for 40H and then 58H, look like lots of them!

have fun!
been there, done it!

:-)

[mrvcj]

Hi bmchenry,

Thanks very much for your reply. I think I'm OK writing my own code but really having hard time to understand the old-fasioned format. So just want to doube check that I understand correctly.

Take the following code for example,

100 FORMAT(/////,1X,40HKTEDIT=.................................,I6,/, &
& 1X,40HNSUB=...................................,I6,/, &
& 1X,40HKSPEC=..................................,I6)

Should I change it to

100 FORMAT(/////,1X,40HKTEDIT=.................................,I6,/, &
& 1X,'',NSUB=...................................,I6,/, &
& 1X,'',KSPEC=..................................,I6)

Sorry to bother you again. I'm a foreign student and just not confident about my english... Thank you very much.

[mrvcj]

Hi Steve,

Thanks very much for you explanation and it works great in the command line. Then I was going to compile it in Visual Studio (as it's easier to debug), I got the following error:

error LNK2019: unresolved external symbol _ERROR referenced in function _MRROR micror.obj

If I understand correctly, the problem is that I was trying to link some undefined function ERROR in subroutine MRROR. It should be OK because this is a defined fuction in the windows system, so maybe I just need to provide the path or something? Can you tell me how do solve this problem in the Visual Studio? I'm still learning... Thanks in advance.

Jason

[TimP]

This ERROR function may have been part of the Fortran run-time system for which this program was written, but it's not a standard Fortran function, so your current compiler sees it as unresolved. The comments indicate that it's intended as a place to request a function call trace on a Fortran implementation which offers that option.

[TimP]

In changing from Hollerith notation to quoted string, you would put the matching quote character before and after the character string:
100 FORMAT(/////,1X,"KTEDIT=.................................",I6,/, &
& 1X,"NSUB=...................................",I6,/, &
& 1X,"KSPEC=..................................",I6)

It looks like someone has retrofitted Fortran 90 style continuation marks, in the style which would allow the source to be read in either fixed or free form. This requires that you keep the leading & in column 6, and the trailing & in column 73-80.
Likewise, the ! comment would not have worked with an extended f66 compiler, so you have a mixture of code from different eras.

[mrvcj]

Thank you very much. That's much more clear.

Yes the code is old and has been modified by different people. It looks like I'm going to have a good time with it.

[mrvcj]

Since I successfully compiled this code with Lahey compiler, I'm wondering if there is a way in Intel Composer to fix the problem, for instance, by including some library. I still think the ERROR function would be some build-in funcion (it's very possible that I'm wrong). I'll double check tomorrow. Thanks very much for your time.

[mecej4]

As Tim said, the ERROR subroutine was called to provide a user-requested traceback. You can simply comment out the two calls to that subroutine since there are STOP statements immediately after.

You will need to change 1.E-50 on line 15288 to 1.E-38 since the former is smaller than MIN_REAL for REAL*4 variables.

With these changes, the program builds with

ifort /Od /traceback /pad-source micror.f

Note, however, that this code predates even Fortran 77, since there are numerous instances where integer and real variables are used to contain and process character strings. The code badly needs rewriting if it will not be retired soon.

[bmchenry]

Only thing i'd add to Tim's is that I normally use the single quote ' around character stings...
'This is a character string'
instead of double
"This also is a character string"
So you format would be

100 FORMAT(/////,1X,'KTEDIT=.................................',I6,/, &

& 1X,'NSUB=...................................',I6,/, &

& 1X,'KSPEC=..................................',I6)

And it appears that iawhat is already in your code(for strings not in old Hollerith form)

[mrvcj]

Thank you, guys. I can now compile and build the executable in Visual Fortran.

Now I'm having trouble with debugging... In the project option I will define the debug settings, such as command and working directory. Suppose the directory containing my executable is E:\Research\2010_EM2\Phase_II\Codes\micror\micror_proj\micror_proj\Debug, and the one with the input files for this code is E:\Research\2010_EM2\Phase_II\Codes\test\MICROR. So I should use the second one as the working directory?

Also assume the input file is called "input", and if I type "micror < input" in the command line to run the calculation. Do I use "micror < input" as the command arguments?

What should I use for "command" in the debugging option?

When I start debugging, there is just one blank prompt window with the title of the code, in the debugging folder. Why didn't the working directory settings work?

I'm sorry if those questions seem too naive, I looked through the help documents but it doesn't give an example on how to define all the settings. Thanks very much for your time.

Best wishes,

Jason

[bmchenry]

working directory can be anywhere but i normally use where the 'input' file is, so in your case
E:\Research\2010_EM2\Phase_II\Codes\test\MICROR
and instead of typing micor < input in debugging tab (where you set working directory) set 'argument' as
input
or
E:\Research\2010_EM2\Phase_II\Codes\test\MICROR\input

command is the build EXE name
set in the LINK step
or
$(TargetPath)

have fun!

[mrvcj]

Thanks so much for your explanation. I did what you suggested, unfortunately, I'm still having the blank prompt window, and there is no response when you type anything except for a number. I'm attaching two screen shots and hopefully they're helpful for you to locate the problem. Thank you.

[mrvcj]

I forgot to mention that in the "command argument", I also tried to give the absolute path of the input, but it doesn't change the results. Thanks.

[bmchenry]

first, i'd sugest you split your source into separate routines (FSPLIT and others are out there)
but if you want to see what's going on...
I foundthe'main program': Program FJOY (i think i recall)
stick a break point there and run it in debug and see what it is doing...
there are two options for input: 'normal?' and FSHORT
which is based on a Z(1) variable
long and short of it is i think it is setup for interaction with the screen input.
You need to OPEN a input unit and then it will interact with the file INPUT (or whatever you name the file)
or be sure that the opening to the screen is correct to get input from you when you run it.
The blanh screen in your screen shot may be the program waiting forinputs?
SO enter 1 (Short) and see what happens!
Otherwise you'll need to do a little investigation to see what the options mean (Short?)
and then what inputs the program is looking for
and then either create an input file and open it in the program
or
open the screen as input/output

but better to split it up and then walk through to see what the various routines are doing so you know what it is expecting, etc

brian

[mrvcj]

Hi Brian,

I set a breakpoint at the main program NJOY and started from there. Apparently the code micror doesn't realize there is an input file for it, it expects me to type in the lines in the input. Anyway, this is wierd and I'll try to solve it because I can't really debug this way. Thank you.

Jason

[Steven_L_Intel1]

Which Visual Studio version are you using? VS2005 (I think) had a bug in the way it handled (or didn't) redirection in the Command Argument field.

[mrvcj]

Steve,

I'm using the Intel Composer XE 2011 via Visual Studio and still could solve the problem. Would you give me some idea? Thank you.

Jason