topic @mecej4 I think so too. in Intel® Fortran Compiler

Trying to implement code example for derived type IO with no success

awa5114 — Mon, 26 Jun 2017 15:11:46 GMT

I'm trying to learn more about derived type IO. To start off with I am using examples from this page: https://software.intel.com/en-us/node/678729

I have created a Visual Studio solution and copied the contents of example1 into a source file. When I run the solution I get errors:

Error	9	Compilation Aborted (code 1)	D:\TEMP\FortranTest\Console1\Console1\Source1.f90	1	
Error	7	 error #7002: Error in opening the compiled module file.  Check INCLUDE paths.   [TYPES]	D:\TEMP\FortranTest\Console1\Console1\Source1.f90	51	
Error	4	 error #6546: A required END statement for the interface-body is missing.	D:\TEMP\FortranTest\Console1\Console1\Source1.f90	14	
Error	8	 error #6457: This derived type name has not been declared.   	D:\TEMP\FortranTest\Console1\Console1\Source1.f90	52	
Error	5	 error #6268: The keyword ASSIGNMENT or OPERATOR was expected in this context   [WRITE]	D:\TEMP\FortranTest\Console1\Console1\Source1.f90	12	
Error	6	 error #6268: The keyword ASSIGNMENT or OPERATOR was expected in this context   [READ]	D:\TEMP\FortranTest\Console1\Console1\Source1.f90	8	
Error	3	 error #5082: Syntax error, found IDENTIFIER 'UDIO_WRITE_ARRAY' when expecting one of: <END-OF-STATEMENT> ;	D:\TEMP\FortranTest\Console1\Console1\Source1.f90	13	
Error	1	 error #5082: Syntax error, found IDENTIFIER 'FORMATTED' when expecting one of: * .NOT. . + - /) ** / // .LT. < .LE. <= .EQ. == .NE. /= .GT. > ...	D:\TEMP\FortranTest\Console1\Console1\Source1.f90	8	
Error	2	 error #5082: Syntax error, found IDENTIFIER 'FORMATTED' when expecting one of: * .NOT. . + - /) ** / // .LT. < .LE. <= .EQ. == .NE. /= .GT. > ...	D:\TEMP\FortranTest\Console1\Console1\Source1.f90	12

I know I'm allowed to have modules in the same file as the main executing program because the below code:

module mymod
    contains
        subroutine hello
            print *, "hello"
        end subroutine hello
    end module mymod
    
program test
    use mymod    
    call hello
    
    end program test

compiles, runs and outputs correct output.

Why are none of the examples from the provided link working? I feel like they should since they come from the main intel website and I am using intel products.

Just now, I tried all three

mecej4 — Mon, 26 Jun 2017 16:12:00 GMT

Just now, I tried all three examples using Ifort 17.0.4, and all worked fine. Example-1 does not use module UDIO; therefore, you have mixed up the examples in some way. What does your Source1.f90 contain, and which version of the compiler did you use?

Yes, sorry. I just edited the

awa5114 — Tue, 27 Jun 2017 05:38:00 GMT

Yes, sorry. I just edited the original question with the errors from example 1. Note the include module problem still occurs Error 7 (error code #7002).

Also you might recall from my previous question (https://software.intel.com/en-us/forums/intel-visual-fortran-compiler-for-windows/topic/737278) that I cannot use ifort. I have several problems with compiling using the VS/Intel Fortran command line which I strongly believe are linked to my lack of administrative privileges (company policy) on my windows machine. The main culprit is ifort: error #10037: could not find 'link'. I would like to refer you to some previous discussions I started about this ...

https://software.intel.com/en-us/forums/intel-visual-fortran-compiler-for-windows/topic/720567#comment-1907724

https://software.intel.com/en-us/forums/intel-visual-fortran-compiler-for-windows/topic/720831

https://stackoverflow.com/questions/33065962/ifort-error-10037-could-not-find-link/36248786#36248786

I have not found as yet a resolution to this problem, since any proposed solution should assume I have NO administrative rights in my system, and I don't see that changing in the near future.

Now, back to my original question, I am compiling Example 1 using a full Visual Studio solution (not the command line). This is where I am copying the errors from.... Do you suspect that might be a cause?

it looks like simple source

andrew_4619 — Tue, 27 Jun 2017 07:51:59 GMT

it looks like simple source errors in your post, Attach the source file, that would be much better than guessing what the problem is.

I'm not sure how the source

awa5114 — Tue, 27 Jun 2017 07:59:21 GMT

I'm not sure how the source file would help. All I am doing is creating a one-file console application project and pasting the code from the webpage then pressing Run. But here it is for reference...

I think that you should

mecej4 — Tue, 27 Jun 2017 08:15:14 GMT

I think that you should concentrate on repairing your Ifort+VS installation to the point that you can compile, link and run simple Fortran programs. After that is done you can explore advanced features of the language.

@mecej4 I think so too.

awa5114 — Tue, 27 Jun 2017 08:18:00 GMT

@mecej4 I think so too. One hundred percent. Except I can't. In order to get ifort to work I would have to get administrative privileges which is against company policy. Of course, it is entirely their fault that their installation of VS 2012 contains this (rather major) glitch with respect to ifort not working. However theres really nothing I can do except use the current resources I have available...

I don't think the install is

Steve_Lionel — Tue, 27 Jun 2017 08:43:05 GMT

I don't think the install is the problem.

One issue I have seen is that if you just copy and paste from the Intel documentation, it sometimes loses line wraps.

As for the source1.f90 you attached, it compiles fine for me. The error messages you showed in the original post suggest that you compiled something different. Please do the following from a Fortran command prompt:

type source1.f90
ifort -c source1.f90

and show the output.

Usually, when an employer

mecej4 — Tue, 27 Jun 2017 08:44:02 GMT

Usually, when an employer restricts access to end users on company PCs, they have to provide one or more system administrators who are responsible for installing and servicing software (such as Parallel Studio) that their end users are required to use in order to perform their job.

I suspect that there is some inconsistency as to version numbers, because the VC startup batch file reported (in your thread https://software.intel.com/en-us/forums/intel-visual-fortran-compiler-for-windows/topic/720567#comment-1900033 ) that it could not find VS110COMNTOOLS. The "110" in the name is the version number of Visual Studio. If the installed version is a different version, the combination may or may not work. Fixing these issues is, again, the administrators' responsibility.

110 is correct for VS2012.

Steve_Lionel — Tue, 27 Jun 2017 08:48:11 GMT

110 is correct for VS2012.

@Steve--> here is the output

awa5114 — Tue, 27 Jun 2017 08:55:09 GMT

@Steve--> here is the output for the commands you requested:

Intel(R) Parallel Studio XE 2013
Copyright (C) 1985-2012 Intel Corporation. All rights reserved.
Intel(R) Composer XE 2013 Update 1 (package 119)
ERROR: Cannot determine the location of the VS Common Tools folder.


C:\Program Files (x86)\Intel\Composer XE 2013>D:

D:\>cd D:\TEMP\FortranTest\Console1\Console1

D:\TEMP\FortranTest\Console1\Console1>type source1.f90
MODULE TYPES
  TYPE T
     INTEGER :: K(10)
   CONTAINS

! a generic type-bound procedure
     PROCEDURE :: UDIO_READ_ARRAY
     GENERIC :: READ (FORMATTED) => UDIO_READ_ARRAY
  END TYPE T

! an explicit interface
  INTERFACE WRITE(FORMATTED)
     MODULE PROCEDURE UDIO_WRITE_ARRAY
  END INTERFACE
 CONTAINS
  SUBROUTINE UDIO_READ_ARRAY (DTV, UNIT, IOTYPE, V_LIST, IOSTAT, IOMSG)
    CLASS(T), INTENT(INOUT)     :: DTV
    INTEGER, INTENT(IN)         :: UNIT
    CHARACTER(*), INTENT(IN)    :: IOTYPE
    INTEGER, INTENT(IN)         :: V_LIST (:)
    INTEGER, INTENT(OUT)        :: IOSTAT
    CHARACTER(*), INTENT(INOUT) :: IOMSG

! This is the child I/O that gets performed when the procedure
! is called from a parent I/O û it uses list-directed input to read
! the array K

    READ (UNIT, FMT=*, IOSTAT=IOSTAT, IOMSG=IOMSG) DTV%K

    END SUBROUTINE UDIO_READ_ARRAY

  SUBROUTINE UDIO_WRITE_ARRAY (DTV, UNIT, IOTYPE, V_LIST, IOSTAT, IOMSG)
  CLASS(T), INTENT(IN)        :: DTV
  INTEGER, INTENT(IN)         :: UNIT
  CHARACTER(*), INTENT(IN)    :: IOTYPE
  INTEGER, INTENT(IN)         :: V_LIST (:)
  INTEGER, INTENT(OUT)        :: IOSTAT
  CHARACTER(*), INTENT(INOUT) :: IOMSG

! This is the child I/O that gets performed when the procedure
! is called from a parent I/O û it uses list-directed output to write
! the array K

        WRITE (UNIT, FMT=*, IOSTAT=IOSTAT, IOMSG=IOMSG) DTV%K

  END SUBROUTINE UDIO_WRITE_ARRAY

 END MODULE TYPES

 PROGRAM TEST1
  USE TYPES
  TYPE (T) :: V
  INTEGER  :: COUNTCHAR

   OPEN (1, FILE='TEST.INPUT', FORM='FORMATTED')
    READ (1, FMT='(DT)', ADVANCE='NO', SIZE=COUNTCHAR) V
  CLOSE(UNIT=1)
  WRITE(6, '(DT)') V

 END PROGRAM TEST1
D:\TEMP\FortranTest\Console1\Console1>ifort -c source1.f90
Intel(R) Visual Fortran Intel(R) 64 Compiler XE for applications running on Inte
l(R) 64, Version 13.0.1.119 Build 20121008
Copyright (C) 1985-2012 Intel Corporation.  All rights reserved.

source1.f90(8): error #5082: Syntax error, found IDENTIFIER 'FORMATTED' when exp
ecting one of: * .NOT. . + - /) ** / // .LT. < .LE. <= .EQ. == .NE. /= .GT. > ..
.
     GENERIC :: READ (FORMATTED) => UDIO_READ_ARRAY
----------------------^
source1.f90(12): error #5082: Syntax error, found IDENTIFIER 'FORMATTED' when ex
pecting one of: * .NOT. . + - /) ** / // .LT. < .LE. <= .EQ. == .NE. /= .GT. > .
..
  INTERFACE WRITE(FORMATTED)
------------------^
source1.f90(13): error #5082: Syntax error, found IDENTIFIER 'UDIO_WRITE_ARRAY'
when expecting one of: <END-OF-STATEMENT> ;
     MODULE PROCEDURE UDIO_WRITE_ARRAY
----------------------^
source1.f90(14): error #6546: A required END statement for the interface-body is
 missing.
  END INTERFACE
--^
source1.f90(12): error #6268: The keyword ASSIGNMENT or OPERATOR was expected in
 this context   [WRITE]
  INTERFACE WRITE(FORMATTED)
------------^
source1.f90(8): error #6268: The keyword ASSIGNMENT or OPERATOR was expected in
this context   [READ]
     GENERIC :: READ (FORMATTED) => UDIO_READ_ARRAY
----------------^
source1.f90(51): error #7002: Error in opening the compiled module file.  Check
INCLUDE paths.   [TYPES]
  USE TYPES
------^
source1.f90(52): error #6457: This derived type name has not been declared.   [T
]
  TYPE (T) :: V
--------^
compilation aborted for source1.f90 (code 1)

D:\TEMP\FortranTest\Console1\Console1>

Please note I am the same user from https://software.intel.com/en-us/forums/intel-visual-fortran-compiler-for-windows/topic/720567#comment-1907753

Oh - you're using a five-year

Steve_Lionel — Tue, 27 Jun 2017 08:59:57 GMT

Oh - you're using a five-year-old compiler! UDIO was not supported until the 14.0 compiler.

So User Defined Derived Type

awa5114 — Tue, 27 Jun 2017 09:34:13 GMT

So User Defined Derived Type IO is not supported in the version I have at all? If so how come the error log is explicitly referring it when I try to do a namelist? I have tried this in my code for a large derived type named CalParams

 subroutine GetNameList
        
        open(682, file = "namelist.txt")
        namelist /mynamelist/ CalParams
        write(682, nml = mynamelist)
    end subroutine GetNameList

When I call this routine from my main program I get this error

Error 2 Compilation Aborted (code 1) D:\geo-install\dynamic\trunk_modified\VS\MyMod.f90 1
Error 1 error #5415: Feature not yet implemented: Allocatable or pointer fields require user-defined derived-type I/O procedure. D:\geo-install\dynamic\trunk_modified\VS\MyMod.f90 87

No, it is not supported at

Steve_Lionel — Tue, 27 Jun 2017 09:48:50 GMT

No, it is not supported at all in the version you have. Yes, a "not yet implemented" message was added - the previous behavior was an internal compiler error.

Hi all.

awa5114 — Sun, 27 Aug 2017 12:01:01 GMT

Hi all.

I am back at this again. Thanks to some excellent advice I received back in this thread https://software.intel.com/en-us/forums/intel-visual-fortran-compiler-for-windows/topic/720567 I am proud to say I can now compile simple programs from the command line.

So my understanding is that version 13 does not support derived type IO. Just for reference, this is why I sought to use this functionality in the first place https://software.intel.com/en-us/forums/intel-visual-fortran-compiler-for-windows/topic/737278

I need to make different runs of the software I am using and compare how the derived types in my program change for different configurations and inputs. I am particularly interested in listing exactly those variable names from these derived types for which the value has changed. What viable alternative can I use? some unsuccessful attempts so far have involved:

list directed IO
derived type IO
compiling with debug symbols requested

I am also currently looking into Profile Guided Optimization (PGO). Looks promising but might be an overkill... Any ideas? Thanks very much.

You could use Namelist I/O,

Steve_Lionel — Wed, 06 Sep 2017 10:31:23 GMT

You could use Namelist I/O, writing the before and after into character arrays, and then comparing the elements to see what has changed, including names.