Community
cancel
Showing results for 
Search instead for 
Did you mean: 
Highlighted
Beginner

Derived TYPEs in procedure calls.

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

 

 

 

0 Kudos
7 Replies
Highlighted
Black Belt

Please name the version of

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

0 Kudos
Highlighted
Beginner

I am using 18.0.3 also, with

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.]  

0 Kudos
Highlighted
Valued Contributor II

you just add the rc file to

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. 

0 Kudos
Highlighted
Beginner

I still have no answer for

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!

 

0 Kudos
Highlighted
Valued Contributor II

The error might not be show

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

Still no explanation of why

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? 

 

0 Kudos
Highlighted
Black Belt

Using VS2017 and IFort 18.0.3

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.

0 Kudos