6 Replies Latest reply on Feb 3, 2009 2:03 PM by chipf

    direct-access I/O to unit open for keyed access

    domel

      When I link my program with ACML I get the following error reading from a file:

      direct-access I/O to unit open for keyed access

      If I link to Intel MKL the error does not occur. Hints how to resolve it are most appreciated.

      Facts: compiling with ifort 10.1 on a 64bit linux, 2xDual-Core AMD Opteron(tm) Processor 2220. No errors compiling / linking.
      The code lines causing trouble:

      OPEN(IN, FILE=INPNAME, ACTION='READ', IOSTAT=IO)
      IF(IO/=0) CALL ERROR('ERROR OPENING '//INPNAME)
      DO
          READ(IN, *, IOSTAT=IO) KEY

      ...

      The READ fails when the program is linked with ACML but not Intel's MKL.

        • direct-access I/O to unit open for keyed access
          domel

          update: a separated problem:

          PROGRAM TEST
          CHARACTER(100) :: KEY, INPNAME='cylinder2D_steady.inp'
          PRINT *, INPNAME
          OPEN(2, FILE=INPNAME, ACTION='READ', IOSTAT=IO)
          IF(IO/=0) PRINT *, 'ERROR OPENING '//INPNAME
          READ(2, *, IOSTAT=IO) KEY
          CLOSE(2)
          END PROGRAM

          the above program compiles OK with no additional libraries. Compiled with ACML generates the aforementioned error. exact compilation line:

           

          ifort -O3 -xO TEST.F90 -L /home/dominik/pack/acml-4.1.0/ifort64_mp/lib -lacml_mp

          Also, using a threaded version or not makes no difference.

            • direct-access I/O to unit open for keyed access
              chipf
              I also see an error when I try the test program.
              The error is "forrtl: severe (258): direct-access I/O to unit open for keyed acess, unit 2, ..."

              The problem goes away if I don't link in the acml library.

              We're looking into this problem now.

              I see that this has also been reported on the intel forums at:
              http://softwarecommunity.intel...62590/ShowThread.aspx

              The resolution might show up there first.
                • direct-access I/O to unit open for keyed access
                  frieds4

                  I am seeing this error with ACML 4.2.0 and ifort 9.1 .  Is there any resolution ?

                    • direct-access I/O to unit open for keyed access
                      buymexicohomes

                      I am also getting the same error with frieds4.

                      I hope someone can help us fix this issue.

                      Thanks!

                      Edit:Removed Advertising from the post

                        • direct-access I/O to unit open for keyed access
                          brockp

                          Do you have access to another fortran compiler? If the problem is with ifort, why not use pgf90 nagware or gfortran?

                            • direct-access I/O to unit open for keyed access
                              chipf
                              We've finally root caused this problem and demonstrated a solution. First some background.

                              The ACML libraries are built so that they can be used with either fortran or C programs. But since the ACML source is mostly fortran, each version of ACML must be built with a fortran compiler (from which each version derives its name) and then linked into static and shared object libraries. Each fortran compiler introduces its own set of run time dependencies that require runtime libraries as part of the final application link.

                              For applications written in fortran, this is not an issue, since the user must have that fortran compiler, and therefore has all of the required runtime libraries.

                              But ACML can also be called from C programs, and most C users don't have the associated fortran compilers. They are also missing the fortran runtime libraries.
                              So AMD tries to build the shared object to include any fortran runtime functions required by the ACML fortran code. This allows C users to link with the shared object libraries and not have to worry about missing fortran runtime functions.

                              For most compilers, the compiler license grants the right to redistribute various runtime files. This is true for the ifort compiler. Including these in the acml distribution would be one way to satisfy the runtime requirements, but this makes command lines more complicated and leads to lots of confusion over how to build applications.

                              AMD chose to include the required runtimes in the ifort version of the ACML shared object library.

                              The problem is that ACML 4.2.0 is built with ifort 10.1, and has the 10.1 runtime files included in a way that they are visible to the application linker.

                              Then when using a different version of ifort to build the application, functions from the runtime libraries included in ACML are used to satisfy external functions with the same name required by the the application compiler.

                              For the problem described in this thread, those runtime functions are not compatible from version to version of the ifort compiler.

                              That's a long winded way to say that ACML may have compatibiliy issues with different version of the same compiler, and the I/O error seen here is one way this problem manifests itself. (Sometimes compiler versions add or drop function names and this will cause it's own set of version dependencies, as has been the case with gfortran and PGI.)


                              We have demonstrated a fix. We can use --exclude-libs on our shared object build to hide the fortran runtime functions from the application link. That way, the ACML code uses the correct runtimes it needs, and then the application build will pull the functions it needs from the runtime libraries that match the compiler version being used. This allowed us to properly build and run the example using ifort 11.0 and ACML 4.2.0.

                              We will include this fix in our next version of ACML, 4.3, which should be available in mid to late spring.

                              In the meantime there are 3 ways to work around the issue, which all assume that ifort is being used to build the application.
                              1. Use the same compiler version used to build ACML. The ACML compiler version can be determined by running the acmlinfo example.
                              2. Use the static ACML library instead of the shared object.
                              3. Build a custom shared object from libacml.a. This can be done using gcc with the -shared option, libacml.a as the input, and your_so_name.so as the output.