Fortran Visual Studio soln will not rebuild

[Stuart_M_]

Hi folks

I have inherited a Fortran program that I am trying to step through, but I am unable to get the VS (2005 Standard) Debugger to play nice. I received the code as well as a VS solution and there exists a Debug folder with a .pdb file so I can only assume this has worked in the past. Now I simply get a message to the effect of "Debugging information cannot be found. No symbols loaded."

In an effort to try and regenerate a Debug build I have been trying to rebuild the solution but for some reason VS will not rebuild. I simply get an instant output of "Rebuild All: 1 succeeded, 0 failed, 0 skipped" with nothing actually happening.

I am not certain what version of VS the code was originally worked on in but I do recall some conversion message when I opened the solution in my version. I believe the original coders were using Intel Fortran but I also know they were using Compaq at some point in the past.

It seems the best best is to simply try and rebuild a new debug release. I've now tried creating a new project containing all of the source code and project settings as best as I can make out... I get the following output:

------ Build started: Project: ftloaddsnew_stu, Configuration: Debug Win32 ------

Compiling with Intel Fortran Compiler 10.0.025 [IA-32]...

scrfil.f

C:\Documents and Settings\Administrator\My Documents\Visual Studio 2005\Projects\ftloaddsnew_stu\ftloaddsnew_stu\Swift\scrfil.f(45) : Warning: The STATUS= specifier has the value SCRATCH, the FILE= specifier will be ignored in the OPEN statement. [OTNAME]

getyno.f

getchr.f

digsgks.f

Chd1.for

sinval.f

rdover.f

otfile.f

getopt.f

fmuser.f

daychk.f

adjsrc.f

sepu.f

prpart.f

intwpu.f

dtcode.f

Bcf2.for

tranwl.f

swift2d.f

C:\Documents and Settings\Administrator\My Documents\Visual Studio 2005\Projects\ftloaddsnew_stu\ftloaddsnew_stu\Updates\swift2d.f(751) : Error: The shape matching rules of actual arguments and dummy arguments have been violated. [IRCH]

C:\Documents and Settings\Administrator\My Documents\Visual Studio 2005\Projects\ftloaddsnew_stu\ftloaddsnew_stu\Updates\swift2d.f(792) : Error: The shape matching rules of actual arguments and dummy arguments have been violated. [IRCH]

compilation aborted for C:\Documents and Settings\Administrator\My Documents\Visual Studio 2005\Projects\ftloaddsnew_stu\ftloaddsnew_stu\Updates\swift2d.f (code 1)

Build log written to "file://C:\Documents and Settings\Administrator\My Documents\Visual Studio 2005\Projects\ftloaddsnew_stu\ftloaddsnew_stu\Debug\BuildLog.htm"

ftloaddsnew_stu - 3 error(s), 1 warning(s)

========== Build: 0 succeeded, 1 failed, 0 up-to-date, 0 skipped ==========

I have been trying to resolve this for two weeks now - any assistance would be GREATLY appreciated :-)

[Steven_L_Intel1]

The two "shape matching" errors are important. This means you have violated Fortran's rules for passing arguments. For example, passing a scalar variable other than an array element to an array, or passing an array to a scalar, or passing a rank-1 array to a rank-2 array. Find the two calls that pass IRCH and compare how IRCH is declared against the corresponding dummy argument in the called routine.

You also have a warning from OPEN that says you are using STATUS='SCRATCH' and FILE= - in this case, FILE= is ignored and the run-time system creates its own filename.

I don't know why your original solution won't rebuild - may have something to do with what is set as the build target.

[Stuart_M_]

Hi Steve

Is it possible this is an error caused by some discrepancy between Compaq VF and IVF? The original code I received works, but I'm beginning to suspect it was compiled using CVF. I'm trying to ascertain whether they were using VS+CVF and what versions etc. It seems unlikely that this would be an error in the code unless it is a type of error that only comes to the fore when switching to IVF.

Is there any good documentation on migrating CVF to IVF?

[Steven_L_Intel1]

It's a type of error that CVF would not detect if the caller and callee were in separate source files, but IVF does. Yes, there's a document - you can find it here. It's also linked in the sidebar on the main forum page.

[Stuart_M_]

Quoting - stubaan

Hi Steve

Is it possible this is an error caused by some discrepancy between Compaq VF and IVF? The original code I received works, but I'm beginning to suspect it was compiled using CVF. I'm trying to ascertain whether they were using VS+CVF and what versions etc. It seems unlikely that this would be an error in the code unless it is a type of error that only comes to the fore when switching to IVF.

Is there any good documentation on migrating CVF to IVF?

Hi again Steve - I hope it's okay if I continue the conversation here even though the topic is evolving. Please let me know if it's preferred that I start a new and appropriately titled thread.

Thanks for that excellent conversion guide. Turns out it was a CVF vs IVF issue. I have since extracted the CVF files, returned the default calling convention to "Default" and rebuilt... voila! Just in time to save a few remaining hairs ;-)

However, I'm now encountering new errors when stepping through. In particular, or rather, thus far, I'm snagged by run-time error 24 "End-of-file during read". While I have found an excellent description of the meaning of this error here (http://www.ncsa.uiuc.edu/UserInfo/Resources/Software/Intel/Compilers/8.1/f_ug1/ug1l_rt_errors.htm), I am unsure what it all actually means since this error was not present in the CVF version. Or indeed which of the explanations for the error is the correct one.

From the abovementioned link:

"severe (24): End-of-file during read

FOR$IOS_ENDDURREA. One of the following conditions occurred:

• A Intel Fortran RTL I/O system end-of-file condition was encountered during execution of a READ statement that did not contain an END, ERR, or IOSTAT specification.
• An end-of-file record written by the ENDFILE statement was encountered during execution of a READ statement that did not contain an END, ERR, or IOSTAT specification.
• An attempt was made to read past the end of an internal file character string or array during execution of a READ statement that did not contain an END, ERR, or IOSTAT specification.

This error is returned by END and ERRSNS."

The full error reads:

forrtl: severe (24): end-of-file during read, unit 115, file c:"path"inputwind.dat

The offending line of code reads:

READ(115,*)DAY2,XSTRESS2,YSTRESS2

And the input file inputwind.dat itself is simply:

0,0,0

1,0,0

2,0,0

3,0,0

4,0,0

5,0,0

6,0,0

7,0,0

8,0,0

9,0,0

Any suggestions?

[Stuart_M_]

I just wanted to add that I have been experimenting with "END", which as best as I can tell seems to be the most appropriate thing to tinker with, as follows:

IF(DAY .GT. DAY2)THEN

DAY1=DAY2

XSTRESS1=XSTRESS2

YSTRESS1=YSTRESS2

C SJM 03/20/09: receiving forrtl error 24; added "end=13"

READ(115,*,END=13)DAY2,XSTRESS2,YSTRESS2

13 WINDAY=WINDAY+SQRT(SQRT(XSTRESS1**2+YSTRESS1**2)/Wmulf)

Where I received the forrtl error 24 before the program now simply freezes at the same juncture (based on the output printed to screen), or perhaps winds up in an inveterate loop.

This doesn't feel right, which probably explains why it isn't.

[Les_Neilson]

Quoting - stubaan

I just wanted to add that I have been experimenting with "END", which as best as I can tell seems to be the most appropriate thing to tinker with, as follows:

IF(DAY .GT. DAY2)THEN

DAY1=DAY2

XSTRESS1=XSTRESS2

YSTRESS1=YSTRESS2

C SJM 03/20/09: receiving forrtl error 24; added "end=13"

READ(115,*,END=13)DAY2,XSTRESS2,YSTRESS2

13 WINDAY=WINDAY+SQRT(SQRT(XSTRESS1**2+YSTRESS1**2)/Wmulf)

Where I received the forrtl error 24 before the program now simply freezes at the same juncture (based on the output printed to screen), or perhaps winds up in an inveterate loop.

This doesn't feel right, which probably explains why it isn't.

Can you show more code ?

Itseems likelythat your read is done within some kind of loop. eg DO J=1,N or possibly within a GO TO

eg :
100 ! top of loop
! do some processing
! Now read the file
Read (115 ...
! More processing

GO TO 100
199 CONTINUE

If so then adding END=199 is requiredin order to catch the situation when you run out of data in the file, although there may be some other code which is supposed to recognise that you have reached the end of the data.

If you can attach the full subroutine to a post then that would be a big help in finding out what is going wrong.

Les

[Stuart_M_]

Hi Les

Here is the entire file - not too long. Sorry I should have included it all to begin with but it was late and I was rushing and a little brain-fried. Thanks for the help.

SUBROUTINE GETWIND

INCLUDE '..COMMONStvinp.cmn'

INCLUDE '..COMMONSB.CMN'

INCLUDE '..COMMONSPT1MIN.CMN'

INCLUDE '..COMMONSTIMECNTRL.CMN'

INCLUDE '..COMMONSWINDPM.CMN'

DATA IFIRST/1/

DATA WINDWT/0.53/

IF(IFIRST .EQ. 1)THEN

OPEN(115,FILE='..inputWINDSinputwind.dat',STATUS='OLD') !JD

C * COMPUTE AVERAGE WIND *

IC=0

WINDAVE=0.

5 CONTINUE

READ(115,*,END=7)DAY1,XSTRESS1,YSTRESS1 !JD

IC=IC+1

WINDAVE=WINDAVE+SQRT(SQRT(XSTRESS1**2+YSTRESS1**2)/Wmulf)

GO TO 5

7 CONTINUE

WINDAVE=WINDAVE/FLOAT(IC)

REWIND(115)

C * FIND WIND

READ(115,*)DAY1,XSTRESS1,YSTRESS1 !JD

READ(115,*)DAY2,XSTRESS2,YSTRESS2 !JD

WINDAY=0.

IFIRST=0

ENDIF

DAY=(KBND+1)*HALFDT/1440.+1.+DAYOFFSTSWIFT

10 IF(DAY .GT. DAY2)THEN

DAY1=DAY2

XSTRESS1=XSTRESS2

YSTRESS1=YSTRESS2

C SJM 03/20/09: receiving forrtl error 24; added "end=13"

READ(115,*,END=13)DAY2,XSTRESS2,YSTRESS2

13 WINDAY=WINDAY+SQRT(SQRT(XSTRESS1**2+YSTRESS1**2)/Wmulf)

IF(FLOOR(DAY2).NE.FLOOR(DAY1)) THEN

CONVECT=(1.-WINDWT)*WINDAVE+WINDWT*WINDAY*(DAY2-DAY1)

WINDAY=0.

ENDIF

GOTO 10

ENDIF

WINDU=XSTRESS1

WINDV=YSTRESS1

C WINDVEL=SQRT(SQRT(WINDU**2+WINDV**2)/Wmulf)

C CONVECT=(1.-WINDWT)*WINDAVE+WINDWT*CONVECT

RETURN

END

[Les_Neilson]

Quoting - stubaan

10 IF(DAY .GT. DAY2)THEN

DAY1=DAY2

XSTRESS1=XSTRESS2

YSTRESS1=YSTRESS2

C SJM 03/20/09: receiving forrtl error 24; added "end=13"

READ(115,*,END=13)DAY2,XSTRESS2,YSTRESS2

13 WINDAY=WINDAY+SQRT(SQRT(XSTRESS1**2+YSTRESS1**2)/Wmulf)

IF(FLOOR(DAY2).NE.FLOOR(DAY1)) THEN

CONVECT=(1.-WINDWT)*WINDAVE+WINDWT*WINDAY*(DAY2-DAY1)

WINDAY=0.

ENDIF

GOTO 10

There is your problem.
When you get to the end of the file you go to 13, then you go back to 10 and try to read some more.
Presumably at end of file you will have to jumpbeyond the "go to 10"

Les

[Stuart_M_]

Quoting - Les Neilson

There is your problem.
When you get to the end of the file you go to 13, then you go back to 10 and try to read some more.
Presumably at end of file you will have to jumpbeyond the "go to 10"

Les

Thanks Les - that worked perfectly. Kinda obvious in hindsight huh? :-)

Now I'm getting a "(37): inconsistent record length, unit 1, file C:...fort.1" supposedly for not specifying a record length when trying to open a direct-access file. The offending code is in bold below. Clearly a record length is specified (REC=KREC) so what else might this error message be implying? I can find no record of a fort.1 file.

IF(NST/NPRSEP*NPRSEP .EQ. NST)THEN

KREC=KREC+1

WRITE(NUBINARY,REC=KREC)SEPS,NST,

c 1 (((SEP(N,M)-SEMIN(N,M)), M=1,MMAX),N=1,NMAX)

1 ((SEP(N,M), M=1,MMAX),N=1,NMAX)

WRITE(302,*)NST

DO J=1,NMAX

WRITE(302,100)(SEP(J,M),M=1,MMAX)

ENDDO

WRITE(301,*)NST

DO J=1,NMAX

WRITE(301,100)((SEP(J,M)-SEMIN(J,M)),M=1,MMAX)

ENDDO

ENDIF

Many(!) thanks

[Les_Neilson]

Quoting - stubaan

Thanks Les - that worked perfectly. Kinda obvious in hindsight huh? :-)

Now I'm getting a "(37): inconsistent record length, unit 1, file C:...fort.1" supposedly for not specifying a record length when trying to open a direct-access file. The offending code is in bold below. Clearly a record length is specified (REC=KREC) so what else might this error message be implying? I can find no record of a fort.1 file.

IF(NST/NPRSEP*NPRSEP .EQ. NST)THEN

KREC=KREC+1

WRITE(NUBINARY,REC=KREC)SEPS,NST,

c 1 (((SEP(N,M)-SEMIN(N,M)), M=1,MMAX),N=1,NMAX)

1 ((SEP(N,M), M=1,MMAX),N=1,NMAX)

WRITE(302,*)NST

DO J=1,NMAX

WRITE(302,100)(SEP(J,M),M=1,MMAX)

ENDDO

WRITE(301,*)NST

DO J=1,NMAX

WRITE(301,100)((SEP(J,M)-SEMIN(J,M)),M=1,MMAX)

ENDDO

ENDIF

Many(!) thanks

No. The REC=KREC is a record number not a record length i.e. it is writing the KREC'th record in the file.
You need to look for OPEN on file unit NUBINARY, look for a RECL=

From the help :
"Formatted Direct Files
In a formatted direct file, all of the records are the same length and can be written or read in any order. The record size is specified with the RECL option in an OPEN statement and should be equal to or greater than the number of bytes in the longest record. "

Note that last sentence. So you need to compare the RECL on the OPEn with the size of the data you are writing/reading and whether you are using bytes or words.

Again from the help :
"If the file is connected for formatted data transfer, the value must be expressed in bytes (characters). Otherwise, the value is expressed in 4-byte units (longwords). If the file is connected for unformatted data transfer, the value can be expressed in bytes if compiler option assume byterecl is specified." (emphasis mine)

Les

[jparsly1]

I filename of FORT.1 shows up when you attempt to write to unit 1, and you don't have an open file assigned to unit 1. This could happen if you never opened a file on unit 1, or if you closed the connection to unit 1 and then attempted to write to that unit again. The run time library is trying to be helpful, so instead of just having the
program crash, it automatically creates this file for you.

[Stuart_M_]

Hi again. I am still unable to resolve this :-( Below is the full source file. I have emboldened where RECL is defined in the OPEN statement and preceding definition of its value. Where the program actually crashes is emboldened and underlined a little below it. I have tried experimenting with the compilation settings mentioned by Len and have read all I can find on this with no further progress. I do not think NRECLENGTH=NMAX*MMAX+2 is incorrect because this worked perfectly in the CVF version of this program, and a different Intel version that does work has the same setting.

CHARACTER*4 SEPS,UPS,VPS,SALS,TEMS

DATA SEPS,UPS,VPS,SALS,TEMS/'SEP ','UP ','VP ','SAL ','TEMP'/

DATA IFIRST,KREC,KFACEREC/1,0,0/

C CALL SWDATE

IF(IFIRST .EQ. 1)THEN

NUBINARY=102

NRECLENGTH=NMAX*MMAX+2

OPEN(NUBINARY,FILE='FTLBIN.DAT',ACCESS='DIRECT',

1 FORM='UNFORMATTED',RECL=NRECLENGTH)

OPEN(141,FILE='WCRH.DAT',STATUS='UNKNOWN',

1 FORM='FORMATTED')

OPEN(116,FILE='FACEFLOW.BIN',ACCESS='DIRECT',

1 FORM='UNFORMATTED',RECL=NRECLENGTH)

OPEN(301,FILE='../output/DEPTH_OUT.DAT')

OPEN(302,FILE='../output/STAGE_OUT.DAT')

OPEN(303,FILE='../output/UVEL_OUT.DAT')

OPEN(304,FILE='../output/VVEL_OUT.DAT')

WRITE(301,*)'DEPTH'

WRITE(302,*)'STAGE'

WRITE(303,*)'UVEL'

WRITE(304,*)'VVEL'

IFIRST=0

ENDIF

C

C IF ( Nprse.NE.0 ) THEN

IF(NST/NPRSEP*NPRSEP .EQ. NST)THEN

KREC=KREC+1

WRITE(NUBINARY,REC=KREC)SEPS,NST,

c 1 (((SEP(N,M)-SEMIN(N,M)), M=1,MMAX),N=1,NMAX)

1 ((SEP(N,M), M=1,MMAX),N=1,NMAX)

WRITE(302,*)NST

DO J=1,NMAX

WRITE(302,100)(SEP(J,M),M=1,MMAX)

ENDDO

WRITE(301,*)NST

DO J=1,NMAX

WRITE(301,100)((SEP(J,M)-SEMIN(J,M)),M=1,MMAX)

ENDDO

ENDIF

IF(NST/NPRVCU*NPRVCU .EQ. NST)THEN

KREC=KREC+1

WRITE(NUBINARY,REC=KREC)UPS,NST,((UP(N,M), M=1,MMAX),

1 N=1,NMAX)

KFACEREC=KFACEREC+1

WRITE(116,REC=KFACEREC)'FLX ',NST,((CUMU(N,M), M=1,MMAX),

1 N=1,NMAX)

WRITE(303,*)NST

DO J=1,NMAX

WRITE(303,100)(UP(J,M),M=1,MMAX)

ENDDO

CUMU=0.

ENDIF

IF(NST/NPRVCV*NPRVCV .EQ. NST)THEN

KREC=KREC+1

WRITE(NUBINARY,REC=KREC)VPS,NST,((VP(N,M), M=1,MMAX),

1 N=1,NMAX)

WRITE(304,*)NST

DO J=1,NMAX

WRITE(304,100)(VP(J,M),M=1,MMAX)

ENDDO

C *check* Write salinity and temperature at same times as V

IF(LSAL.NE.0) THEN

KREC=KREC+1

WRITE(NUBINARY,REC=KREC)SALS,NST,((R(N,M,LSAL), M=1,MMAX),

1 N=1,NMAX)

ENDIF

IF(LTEMP.NE.0) THEN

KREC=KREC+1

WRITE(NUBINARY,REC=KREC)TEMS,NST,((R(N,M,LTEMP), M=1,MMAX),

1 N=1,NMAX)

ENDIF

KFACEREC=KFACEREC+1

WRITE(116,REC=KFACEREC)'FLY ',NST,((CUMV(N,M), M=1,MMAX),

1 N=1,NMAX)

CUMV=0.

ENDIF

C IF(NST/NPRVCV*NPRVCV .EQ. NST)THENC

C KREC=KREC+1

C WRITE(NUBINARY,REC=KREC)CHZS,TIMMIN,((C(N,M), M=1,MMAX),

C 1 N=1,NMAX)

C KREC=KREC+1

C WRITE(NUBINARY,REC=KREC)ICLS,TIMMIN,((ICLSTAT(N,M), M=1,MMAX),

C 1 N=1,NMAX)

C ENDIF

100 FORMAT(500F8.4)

RETURN

END

[Les_Neilson]

NRECLENGTH = NMAX * MMAX + 2 assumes the record length is in words, is that correct? (if it should be bytes then multiply nreclength by 4)

Are you sure the open worked? Perhaps you should add a IOSTAT= and ERR = to your open numbinary statement.
Did you try stepping through the code in the debugger?

The code you provided looks ok at first glance (apart from being f77 but that is a style issue) but is not sufficient to do a test
SEPS, UPS etcwe see are character 4
you don't show the declarations for NST (presumed integer scalar)
and the SEP ,UP , VP, and Rarrays (presumably 4 byte real)


Les

[Stuart_M_]

Hi Les (and others)

Sorry for the tardy response - I was out of the office for a week. I have been hammering away at this for a full day since getting back and am now devoid of anything resembling patience or hope.

Could there be some problem specifically related to migrating this project from VCF to IVF? Because this bug does not exist when I execute the code as it originally came to (via CVF).

Here is what I have since tried with no difference:

1) Multiplying NRECLENGTH by 4, just in case. Since I know the code works as is I find it hard to imagine this is the problem.

2) I added IOSTAT and ERR to OPEN as you suggested (see code below) but the crash comes at the exact same point and none of my error messages are printed to screen.

OPEN(NUBINARY,FILE='FTLBIN.DAT', ERR=11, IOSTAT=IERRR,

& ACCESS='DIRECT', FORM='UNFORMATTED',RECL=NRECLENGTH )

11 IF (IERRR.GT.0) THEN

Write(*,*) 'FBOMB'

ELSE IF (IERRR.LT.0) THEN

Write (*,*) 'ENDFILE'

END IF

3) I also stepped through with the debugger and the OPEN statement causes no problems. I can't tell whether NUBINARY is opened every time the model cycles through a time-step or remains open throughout, but the it seems the crash comes at the WRITE statement.

4) Not sure whether this is pure coincidence, but the model crashes at day "1.050000" out of a total of 8, which considering each time step is printed to screen and every preceding such print is something like 1.046181, the value 1.050000 seems suspicious. I don't know why, but it does ;-)

S.O.S.

[anthonyrichards]

You say you have posted the complete code, which is clearly not the case. For a start, there
are no specification statements dimensioning your arrays. Adding implicit none to your posted code yields loads of messages about variables not having been given an explicit type.

Also, if you have not tracked down why you are writing to stream 1 (shown by the compiler creating a FORT.1 output file) when you say stream 1 doesn't figure anywhere in your code, then there is not much point in continuing, IMHO.

[Stuart_M_]

Quoting - anthonyrichards

You say you have posted the complete code, which is clearly not the case. For a start, there
are no specification statements dimensioning your arrays. Adding implicit none to your posted code yields loads of messages about variables not having been given an explicit type.

Also, if you have not tracked down why you are writing to stream 1 (shown by the compiler creating a FORT.1 output file) when you say stream 1 doesn't figure anywhere in your code, then there is not much point in continuing, IMHO.

Hi

Just some clarification; I said the full source file, meant to imply all the code from that particular fortran file. The entire program is enormous, with probably ~100 files of fortran code (excluding all the includes) so to post the complete code would obviously not be feasible.

As for the issue of why I am writing to stream 1... well honestly I have absolutely no idea how to determine this. But since your opinion is that it appears to be critical to any effort tocontinue(a decision out of my control - this must be resolved) I will spend some time trying to figure out how to figure this out. Anything/resources you can suggest to assist me in this would be awesome.

And so the thank yous continue... :-)