Derived TYPEs in procedure calls.

[PASeeger]

I am getting compile error #6633 when passing a derived TYPE in the calling sequence of a function or subroutine: 

C:\NISP\MCLIB_\PdotB.f(49): error #6633: The type of the actual argument differs from the type of the dummy argument.   [LOCALPART]

C*********  INCLUDE FILE,  'MC_GEOM.INC'  **********
C
C  To change dimensions of all arrays, change maximum numbers of
C    surfaces (MAXS), regions (MAXR), element parameters (MAXP), and/or
C    magnetic regions (MAXM) in following PARAMETER statement.
      INTEGER*4 MAXS, MAXR, MAXP, MAXM
      PARAMETER (MAXS=400, MAXR=255, MAXP=8000, MAXM=50)
C
C    MC_ELEMENT is a derived type with the variables for what happens
C    to neutrons in a REGION. Each INDEX points to the beginning of a
C    structure within the contiguous block PARAM. The first entry in
C    PARAM for each element identifies the type, followed by a varying
C    number of variables. Element types and parameters are defined in
C    a separate file, MC_ELMNT.INC
C    NAME      = descriptive name of a region or element
C    NEXTINDX  = pointer to next available location in PARAM
C    INDEX     = pointer into parameter block;
C                 0 if region is NOT an "element"
C    PARAM = combined block of parameters for the whole instrument
      TYPE MC_ELEMENT
  SEQUENCE
         CHARACTER*40 NAME(MAXR)
         INTEGER*4    NEXTINDX, INDEX(MAXR)
         REAL*8       PARAM(MAXP)
      END TYPE
C
C    PARTICLE is a derived type giving position, velocity, and polarization
C    of a neutron or other particle.
C    (X,Y,Z) = position of particle (m); define -Y = direction of gravity,
C         +Z = nominal beam direction, +X = right; note left-handed system
C    (VX,VY,VZ) = velocity of particle (m/us)
C    TOF = time of flight of particle (us)
C    M   = atomic number of particle (e.g., 1 for neutron, 0 for photon)
C    Q   = charge number of particle (e.g., 0 for neutron, +1 for proton)
C    WT  = statistical weight of particle
C    (PX,PY,PZ) = average polarization vector, from -1.0 to +1.0
      TYPE PARTICLE
         SEQUENCE
         REAL*4 X, Y, Z, VX, VY, VZ, TOF
         REAL*4 M, Q, WT, PX, PY, PZ
      END TYPE
. . .
      TYPE(PARTICLE) LocalPART  !local copy of PART, after 10 ns
      LocalPART     = PART
      LocalPART%X   = PART%X   + 0.01*PART%VX
      LocalPART%Y   = PART%Y   + 0.01*PART%VY
      LocalPART%Z   = PART%Z   + 0.01*PART%VZ
      LocalPART%TOF = PART%TOF + 0.01
      CALL BREGION(LocalPART, GEOM, ELEMENT, MREG, J, F)
C** Both [LocalPART] and [ELEMENT] fail in this CALL. These are the only two  TYPEs that fail in this manner.

Two files are attached (probably?): the include file and the complete PdotB.f

Thanks, Phil Seeger

[mecej4]

Please name the version of your compiler. Ifort 18.0.3 compiled your code and produced an OBJ file without a hiccup.

[PASeeger]

I am using 18.0.3 also, with Visual Studio 2015 shell (as provided by Intel). I am upgrading from Digital/Compaq 6.  I had not tried command-line, but when I do, it works fine, either for the individual function PdotB.f or the whole library, *.f.  The question becomes, "What is different between Command-Line and VS?"

I checked the configuration for MCLIB_, and I DO have Fortran>General>Additional Include Directories = C:\NISP\INCLUDES.  Any additional suggestions would be appreciated.

Thanks, Phil Seeger

[PS: Is there a good document for Visual Studio?  I haven't found a way to visualize my .rc files and connect them to the project.]  

[andrew_4619]

you just add the rc file to the project and VS will then compile it. The  associated .h file needs converting to fortran but intel provide a tool for that DEFTOFD.exe which you configure as an pre-build step. If you search the form you will find how to set that up as it is asked from time to time. 

[PASeeger]

I still have no answer for why my sample subroutine DOES compile from Command-Line, but FAILS in Studio, with

C:\NISP\MCLIB_\PdotB.f(49): error #6633: The type of the actual argument differs from the type of the dummy argument.   [LOCALPART]

In the meantime I have checked the document "Troubleshooting Fortran Integration issues" and find no problem.  I have the proper four dll's, and File Version is  18.0.40.14

Thanks!

[andrew_4619]

The error might not be show on the command line because interface checking is not asked for.

[PASeeger]

Still no explanation of why the sample function (PdotB)  which I uploaded compiles "without a hiccup" from a command-line, but fails with error #6633 when I try to compile in Visual Studio, with the same version of the compiler (18.0.3).  Could somebody check if it compiles for you? Should I be suspicious of the  INCLUDE 'mc_geom.inc' statement? 

[mecej4]

Using VS2017 and IFort 18.0.3, I created a "New Fortran Project from Existing Code", gave the project a name and entered the name of the directory in which I had placed the two files that you provided. After pressing "Finish", I found that the .inc and .f had been properly placed into the Header Files and Source Files parts of the project.

I then asked for Build; the compilation succeeded, but the link step failed with missing externals, as is to be expected.

Sorry, I cannot reproduce your hiccups! You may have some undesirable leftovers from past builds. Try creating a new directory, placing the two files in that directory, and then creating a new project there.