Porting DVF 5.0 to IVF 10.1

[addavid]

Hi,
I'm new to FORTRAN and have source code compiled with Digital Visual Fortran 5.0 and I want to port to Intel Visual Fortran 10.1 but get an error message something like this version of Visual Fortran is not supported by the automated conversion process. Are there other alternatives to make this conversion?

I tried opening the files in a new project as a QuickWin application and changed the module names for example DFLIB to IFQWIN, DFNLS to IFNLS .......etc. but this did not work.

[Steven_L_Intel1]

Creating a new project and adding the files is the way to go. You do not need to change the module names - DFLIB is not exactly equivalent to IFQWIN, and all the DVF/CVF modules are provided under their original names.

If this doesn't help, please provide details on the exact error messages.

[addavid]

I left the module names intact but I still get errors like:

This is not a derived type name.   [XYCOORD] for TYPE (xycoord) xy
The structure-name is invalid or missing 
The leftmost part-ref in a data-ref can not be a function reference

command is this module:

      MODULE command      
! ASSIGN MENU VARAIBLES
            INTEGER(4) black,blue,green,red
            REAL(8)  rad,lane,shoulder
          
            TYPE vehicle
      
            CHARACTER(25) name
            REAL(8) x1,y1,x2,y2
            CHARACTER(1) steer 
   
            END TYPE vehicle
      
      END MODULE command 

[Les_Neilson]

Some comments :
(a) The code alignment is really bad and makes it almost unreadable (for humans).
However
(b) subroutine read_veh won't compile. The read statement expects a continuation but the next line is a comment.
and veh is undefined.
(c) why do you have a COMMON inside a module ? Modules are one of the best ways to get rid of common blocks.
Just leave the variables declared inside the module, they are accessible when you USE the module.
(d) Learn to add "implicit none" to your code from the start, it will save a lot of headache and heartache in the future.
(e) Subroutine OFF wont compile - missing closing")" onIF statement.
veh is undefined and even if defined as type(vehicle_dim) veh(somesize) isused before being assigned any values.

Les

[Steven_L_Intel1]

As Les says, there are some fundamental syntax errors in this source that would not have compiled with PowerStation. I don't see, when I compile it, any complaint about a $ character.

[addavid]

I corrected some errors and I added IMPLICIT NONE and it has eliminated a few errors.

But in subroutine read_veh(), how do I correctly define veh(i)? I tried doing this with AUTOMATIC but it didn't work.

In subroutine off(), do I have to define veh(1), veh(2)....each seperately?

Can you give a short example of how to correctly align the code?

[jimdempseyatthecove]

My guess is veh used to be an array in COMMON and I would alsoguess that it should now be located in commod.f90. This is because veh(i) is read in read_veh and referenced elsewhere.

Since in read_veh the extent of veh is obtained then either:

a) veh is dimensioned larger than it would ever need to be (but you would then be missing an exceeding limit test between the read of nveh and the loop the fills the array),

or

b) make veh an allocatable array in commod then insert code following the READ(8,10 nveh, noption and the DO i loop, code to allocate the veh to the extent specified "allocate(veh(nveh))". You still should have a sanity check to verify nveh is good prior to allocation and that the allocation succeededand take an error exit if not. You may also want a test to assure veh is not allocated prior to allocation in case you make multiple calls to read_veh (you do not want a memory leak later as you enhance you code).

Jim Dempsey

[addavid]

I corrected the erros but I still get warnings about the same blocks of code:
dummy2=SETPIXEL(x,y)
dummy2=SETPIXEL(x+1,y)
dummy2=SETPIXEL(x-1,y)
dummy2=SETPIXEL(x,y+1)
dummy2=SETPIXEL(x,y-1)

I have set dummy2,x,y as INTEGER(2) an get warning:
Warning: The data type of the actual argument does not match the definition.

It doesn't complain about the 1st line but for every other line it doesn't seem to like that I used x+1, x-1, y+1, y-1. This however does prevent me from building an executable

[Steven_L_Intel1]

Either use INT2(x+1), etc., or use x+1_2 to keep the type INTEGER(2). DVF had a bug where it allowed a mismatch here.

[jimdempseyatthecove]

>> use x+1_2 to keep the type INTEGER(2)

If x is real(4) won't 1_2 be promoted to real(4) then added to x to return real(4)?

Jim

[Steven_L_Intel1]

He said x was declared INTEGER(2).

[addavid]

This works, thanks.
I used INTEGER(2) since that is the required data type for SETPIXEL