Does Intel XE 2011 support Common Blocks (FORTRAN77)?

[martinez_paneda__emi]

Good morning

I have linked a Finite Element code (Abaqus 6.13) with the Intel XE 2011 Fortran compiler and the verification procedure of the FE code shows that the connection has been done successfully.  I run several Abaqus job's with different Fortran subroutines and everything seems to be OK. Results agree with those obtained with previous versions (Abaqus 6.12 + Intel Fortran 11.0) although the .log file contains a new text line that didn't appear on previous versions:
remark: umat has been targeted for automatic cpu dispatch.

But results seem ok so I didn't care much about this advice. However, when I use a subroutine that has COMMON BLOCKS in it, the FE code is not able to get any result (the solution does not converge) while on previous versions does. 

Is it possible that Intel XE 2011 does not support COMMON BLOCKS anymore?

Thank you very much for your help, it is highly appreciate it.

PS: Due to the characteristics of the FE code it is not possible to pass information between subroutines with nothing but Common Blocks. 

[martinez_paneda__emi]

I need to make a correction here. 

I've just tried a subroutine that does not have Common Blocks and the solution did not converge (while it did on previous versions). So, the problem is not only restricted to the Common Blocks feature. 

Most of the subroutine is coded based on FORTRAN 77 features. 

I appreciate any help. Thanks in advance.

[Steven_L_Intel1]

Yes, Intel Visual Fortran Composer XE supports COMMON blocks. If it didn't, we couldn't call it Fortran. You'll need to debug the program and figure out where things are going wrong. This is not the sort of problem that can be solved by generalizations and descriptions.

[martinez_paneda__emi]

Thank you Steve for your quick answer

The problem is that, due to the characteristics of the FE code, it is not possible to debug the subroutine (although I found people on the internet that, after many headaches, was able to do it, so I might give it a try). 

However, I think I manage to identify the problem. In order to avoid a 0/0 operation (which results in a NaN) I use an IF construct that does more or less the following:

IF (A .EQ. 0.0 AND B .EQ. 0.0) THEN

C=0

ELSE

C=A/B

END IF

However, in one of the versions, although A and B are equal to 0 (I have include a WRITE statement in order to check it just before the IF construct), C is different to 0 (in fact, C is equal to 76923.07692308). I am completely sure that the subroutine is the same for both versions (I use the same file). 

Have you seen anything similar before? Any tip is highly appreciate it.

Thanks a lot

[Steven_L_Intel1 · Accepted solution]

Most likely, both A and B are not exactly zero but are so close to it that when you write them out it rounds to zero. You could write it using Z format to see if the hex value is actually zero, or compare instead something like (ABS(A) < .0001) (or whatever minimum value you want).

[martinez_paneda__emi]

You are right Steve, thank you. I wrote the variables A and B with Engineering format and saw that, while in one version the are equal to 0 in the other not (they are equal to a very small number, but not precisely 0).

Checking thoroughly the subroutine I found the origin of the problem: I introduced a numeric variable but I did not specify its value. In one version (Abaqus 6.12 + Intel Fortran 11.0) a very small value is given to the variable while in the other version (Abaqus 6.13 + Intel XE 2011) a uninitialized variable is given 0 by default. I've read that this last procedure is common to Basic Fortran. Which way is preferred in the Fortran community? And, where do I change this configuration? 

Once again, thanks a lot for your help Steve. It seems that this problem is coming to an end and this would not have been possible without your help.

PS: Although I am not a programmer I know that not initializing variables is not the best way to proceed. However, don't blame me, this FE code is very particular in its subroutines (does not allow to include the implicit none statement for example).

[Steven_L_Intel1]

There is no default initialization of variables in Fortran. You are required to initialize them before use, either with an initial value specified on the declaration or by an assignment. What you observed is just random chance.

[TimP]

A common symptom of un-defined value (un-initialized is often taken as a non-Fortran equivalent) is taking on a value < TINY(x) as would normally happen when you EQUIVALENCE integer and floating point.  There's no way such accidental behavior can be counted on for repeatability.

[dboggs]

An incidental add-on to this conversation: I was recently struggling with a very old F77 routine, one that had been run on CVF by others, and I am now trying it in IVF. One (of several) big stumbling blocks was that the original compiler, as well as CVF, did default initialization of scalar variables to 0, whereas IVF does not. Fortunately I stumbled on the compiler switch /Qzero that took care of the problem for me. I only wish I had found this option sooner--it appears to be poorly documented!

Another good one when resurrecting old code is /Qsave, which sets the default status for saving the value of variables when exiting then re-entering a subroutine.

[Steven_L_Intel1]

CVF did not default initialize to zero. But what it did do was default to static allocation, which in many cases had the effect of zero-initialization. Intel Fortran defaults to automatic allocation for local scalars.

[John_Campbell]

I would not recommend the use of /Qsave or /Qzero to solve this problem, as the preferred solution is to initialize all variables and to manage the dynamic vs save status of all variables. All variables have a scope so when you return outside the scope of a variable, all variables without a save status can be undefined. Also, depending on the interpretation of the standard, COMMON also has a scope, although most compilers apply a global scope. Some didn't, especially in the days of overlays.
The better approach is to understand the scope of variables and code accordingly. The problem occurs when using old code that did not allow for the scope of dynamically allocated variables. F77 included the SAVE attribute but many compilers defaulted to static allocation of variables. Certainly pre F77 was static allocation, although I've forgotten when dynamic allocation became the norm. Assuming dynamic and managing SAVE is a much better approach.

John

[TimP]

None of the f66 compilers I used had static allocation.

[dboggs]

John Campbell, I agree. However, there is a huge, huge difference between writing new code and resurrecting old 3rd party code. I would never use any kind of global switch to take care of initialization. But in this case, I inherited code consisting of more than 200 library subroutines that incredibly interacted in almost unbelievable ways. I spent a couple of weeks investigating faulty argument passing, that sometimes produced run time errors and other times garbage. I hunted down a few "dummy" arguments (or so the original coder called them) that were intended to be zero, but in fact were sometimes zero, other times a random huge number, and other times a very reasonable number that didn't look like an error at first. It was almost hopeless and very time consuming. When I discovered the /Qzero switch, many problems were instantly solved.

For the record, I completely support Intel's practice of not performing default initialization. Since the standard does not require this, relying on it if offered encourages inherent non-portable coding.

[John_Campbell]

Tim,

I can't recall with certainty, but I would suspect that most Fortran compilers I used in 70's on Prime, HP and Cyber systems defaulted to static allocation.
Certainly if CDC Cyber machines didn't default to SAVE then most of the old code that has this problem would not have existed. I understand there were a number of compilers available so I can't recall which one I used, but when conforming compilers started to default to dynamic, there were a lot of complaints. Most were at conferences, as we didn't have the internet to publicize them.
Also in the 80's the early pre F90 compilers on PC's were usually a mix of the F77 subset and F77 so were not fully conforming. Then there was the fun of retaining the values in variables with overlays.
It was a real problem and I remember the change (somewhat) !

John