Unable to get past problem in code

[Max_K_]

All,

I have been trying to compile a code handed over to me. I am using Visual Studio with the Intel Fortran 10.1.011 compiler. I created the project and included all the necessary files and everything else that was required and was able to get the program to build with no errors. When I go to compile it, the program pops up a console window and seems to be waiting for some input for ever. I have tried many things and nothing seems to be working. I am providing the part of the code where it seems to be having this issue below.

c    If CODE is being used "Standalone", read from unit 5 redirected input.
c    If CODE is being called from AutoTune, the description file name is 
c    passed in.

    if (IsMain) then
        lun_description = 5
        OPEN(   UNIT=lun_description,
     1            STATUS='OLD',
     1            READONLY,
     1            CARRIAGECONTROL='LIST')
    else
        OPEN(   UNIT=lun_description,
     1            FILE=DescFileName,
     1            STATUS='OLD',
     1            READONLY,
     1            CARRIAGECONTROL='LIST')
    endif

      READ(UNIT=lun_description, ERR=915, NML=OPER_INFO)
    rewind(lun_description)
 

Note that I have checked that in the project properties, I have provided the path to the location where the project file exists. Also, the input file that this program is supposed to read is provided in that folder. I have also provided the name of this file under "command line arguments". It almost seems like this "unit=5" is open somewhere and I am not able to find it nor understand what exactly FORTRAN is looking for. Can any of you gurus out there point me in the right direction?

Thanks

Max

[Simon_Geard]

When I go to compile it,

Run?

Yes, unit 5 is open for standard input when your program starts but that isn't a new feature, as far as I know it's always been like that (well since f77 at least). If the program is hanging at the read statement then you'll need to enter data for the namelist (OPER_INFO) at the console. If you post the namelist we might be able to help further. I've got no idea what applying an open statement to unit 5 will do, I'll leave that so someone else. Opening a file on unit 5 is probable a bad idea as well, better to let the program provide you with a unit number:

[fortran]

 OPEN( NEWUNIT=lun_description, FILE=DescFileName, STATUS='OLD', READONLY, CARRIAGECONTROL='LIST')

[/fortran]

Simon

[Steven_L_Intel1]

From the comments, it looks as if the intention is that it should read from "redirected input". If you were running the program from the command line, you'd do something like this:

progname.exe < input.txt

From Visual Studio, open the project properties and select Debugging. Enter into "Command arguments":

< inputfilename.txt

where "inputfilename.txt" is the path to the data file. By default it will look in the project folder (not the folder with the EXE.)

[Max_K_]

sgeard and Steve,

Thank you for your responses, which were both very helpful. I feel very silly but the solution was merely the missing pipe in indication (<). I am almost positive that I had directly entered the file name in the past and therefore did not think about it. No matter. Now the program gets past this point and is stuck at another place but I will try and figure that one out. Should I hit a wall again that I am unable to get over, I will be sure to update the post. But many thanks for the help.

Max

[Max_K_]

Alright,

The code still works very well barring this one little issue, which I am sure is a compiler related one. Hopefully one of you can help.

There are many sections of code which use the format 

IF (<Condition 1> .AND. <Condition2>) THEN
......
ENDIF

Well, when I go to run the program, the compiler creates a breakpoint at the first such occurrence. I realized that what is happening is that Condition 2 does not satisfy the limits set in another part of the code when Condition 1 is FALSE and the compiler has a problem with that. In some other compilers, I know that when Condition 1 is not met, the following condition is not even checked. I have confirmed this by splitting the IF...AND into a nested loop. However, there are many instances of this in the code and it would just be easier if there was a "quick fix" for that. I was wondering if there was an option somewhere to make such a usage compatible?

I am using Visual Studio with the Intel Fortran 10.1.011 compiler.

Any thoughts?

Thanks

Max

[andrew_4619]

That is a feature of standard fortran and is a common coding error. Imagine that condition2 was a function call it might change other things in the code so it would be wrong of the compiler not to evaluate the function. The compiler can process the conditions in any order it chooses also.

There is no quick fix if it is a problem you need to nest the if blocks for example in the order that you want.

The behaviour of "older compilers" is a bug!

[IanH]

app4619 wrote:

That is a feature of standard fortran and is a common coding error. Imagine that condition2 was a function call it might change other things in the code so it would be wrong of the compiler not to evaluate the function. The compiler can process the conditions in any order it chooses also.

There is no quick fix if it is a problem you need to nest the if blocks for example in the order that you want.

The behaviour of "older compilers" is a bug!

The bug is that code relies on the behaviour of the older compilers, not with the older compilers themselves.  If the result of an expression can be determined without evaluating all parts of the expression and there are function references in the parts of the expression that don't need to be evaluated and those function references define variables, then those variables become undefined when the overall expression is evaluated.

(Bar only two exceptions I can think of, all function references occur in expressions, and programmers don't know how smart compilers might get at determining the value of an expression without having to evaluate all parts of it, hence programmers don't know (in the extreme limit) whether any function in an expression will be evaluated, hence some programming styles prohibit ANY side effects in functions because programmers can't rely on them being executed and can't rely on the value of any variable defined by the function).

[dboggs]

Ian, interesting comment about functions having side effects. I learned--many many years ago and in a FORTRAN environment--that side effects were a BIG no-no and so I always avoided it. But in today's world it becomes increasingly difficult to exist by that mantra. When Windows came along the norm in some languages is that they don't even have "subroutines," EVERYTHING is done using "functions"; the only thing a "function" returns is often just an error code (which some programmers often don't even check), and the whole point of calling the function is to produce the side effects. To me this is wrong, but what do I know.

[DavidWhite]

Max

If (<Condition1> .AND. <Conditon2>)

is evaluated differently in Fortran than in C.  This is part of the Fortran Standard.

If C, I believe you can assume left to right evaluation, so that if Condition 1 fails, you know that Condition2 is not evaluated.  If Fortran, the compiler can evaluate the expression in any order as determined by the compiler and the current optimisation.  You cannot assume left to right evaluation in Fortran.

A classic case where Fortran will cause your program to fail is expressions like

IF (I.NE.0 .AND X(I).EQ.0) where X is an array defined from element 1.  X(I) will fail when I is zero.

If you absolutely need left to right evaluation, then you need to do this as nested IF statements.  As Tom Lahey said on another forum recently - "Programming is a game. Tell me the rules, then we can play."  This is one of the rules of Fortran, you need to abide by it or not play.

David

[mecej4]

David White wrote:
IF (I.NE.0 .AND X(I).EQ.0) where X is an array defined from element 1.  X(I) will fail when I is zero.

A slightly more troublesome example, with REAL types X and Y: 

     IF (X.GT.0.0 .AND. Y/X .GT. 0.5) THEN ...

What happens when this is executed with X = 0 depends on what type of floating point exception handling is in effect. Under the rules of Fortran, the compiler is free to issue code that tries to evaluate Y/X even when X is exactly zero.

[TimP]

David White wrote:

If (<Condition1> .AND. <Conditon2>)

is evaluated differently in Fortran than in C.  This is part of the Fortran Standard.

If C, I believe you can assume left to right evaluation, so that if Condition 1 fails, you know that Condition2 is not evaluated.  If Fortran, the compiler can evaluate the expression in any order as determined by the compiler and the current optimisation.  You cannot assume left to right evaluation in Fortran.

This depends on how you choose to translate to C.  There's an amazingly long thread about && and & going now on comp.lang.c.

One of the earliest f77 translators, f2c, did actually translate Fortran .AND. to C && which supports left to right evaluation with short-cutting.  That, and the behavior of certain Fortran compilers on specific cases over 15 years ago, led to many people expecting such behavior.

[Max_K_]

All,

Absolutely right on your comments (not that you needed my affirmation for that!). Thank you all for those pointers (no pun intended). It greatly helped me cross my bridge. I did end up converting all of the compound IFs to nested IFs. And yes, sometimes it is a bane working with too many languages as you end up assuming the underlying logic is the same. Or as David White pointed out - the rules aren't necessarily all the same. <David White>, the example you gave with X(I), where I becomes 0 at some point when the preceeding condition is False and therefore, I wouldn't ideally bother was exactly my problem. With the nested IF of course, that is taken care of.

Thanks again.

Max