Quantcast
Channel: Fortran
Viewing all 3108 articles
Browse latest View live

Q re output arrays from functions ?

$
0
0

This could easily be done with a subroutine, with no problems - -

I have three variable length arrays here,

I want to add the contents of arrays A and B to get array C.

The zeroth element tells the number of items in the array.

The problem is - I cant get the compiler to work re the calling routine.

I tried to keep this as simple as possible - there must be a special trick to make it compile properly ?

Maybe the compiler is not meant to do this? However, in the CALLED routine it compiles with no problem.

any clues ? See attached source file.

Fichier attachéTaille
Téléchargertest53_main.f90251 octets

Building a static library from object files

$
0
0

Hello,

We are using IntelVisual Fortran Composer XE 2011 (Update 7 Integration for Microsoft Visual Studio* 2010, 12.1.3518.2010) to create static libraries from object files previously generated. On some of our computers, when we build the static library project, no library is generated even though no error message is generated. We get the following information:

1>------ Rebuild All started: Project: Lib, Configuration: Release Win32 ------

1>Deleting intermediate files and output files for project 'Lib',configuration 'Release|Win32'.

1>
1>Build log written to"file://F:\Disk_CD\Disk_D\IF\Intel_Fortran\Lib\Lib\Release\BuildLog.htm"
1>Lib - 0 error(s), 0 warning(s)
========== Rebuild All: 1 succeeded, 0 failed, 0 skipped ==========

The step "Creating library..." is missing. This appears to happen on some computers; however, if the static library is generated from Fortran files, the library is created properly. We can always create the library from Fortran files, but it would be great if someone could let us know the reasons for this issue.

Regards,

Antonio

Numeric exception when calling pow-function

$
0
0

Hi,

on some computers (not all) I get a numeric exception when calling the pow function (by using the ** operator) with a negative base(~ - 1.7) and an exponent of 0.75. I get this exception even though the numeric exception flags are set to not trigger any exceptions (and I see it working correctly on other computers). I added a zip-file which contains a crash-dump and an xml-file containing information about the computer/processor where the crash happened and the modules loaded in the process. Hopefully someone at Intel can find out, what's the problem.

Tobias

Fichier attachéTaille
Téléchargercrash.zip25.65 Ko

error PRJ0019

$
0
0

Hello.

After compiling with the Qprof-gen and runing, I tried to compile with Qprof-use and got this error:

error PRJ0019: A tool returned an error code.

Do you know what this error is?

 

I'm using Visual Fortran Compiler XE 14.0.3.202 on windows server 2008 64bit.

 

Thanks,

Roy

With compiler 15 (Update 1), linker fails to recognize UNC path name in LIBPATH whereas it works with Compiler 13

$
0
0

Has anything changed with respect to working with UNC path names (\\server\share\file_path) in LIBPATH input to linker toward building Fortran EXE projects between Intel Fortran Compiler 13 (version 13.1.3.198) and Compiler 15 (Update 1 i.e., 15.0.1.148)?

I've a project that works fine with Visual Studio 2012 and Intel Fortran 13.1.3.198.  This project fails with Visual Studio 2012 and Intel Fortran 15.0.1.148; "LINK : fatal error LNK1181: cannot open input file 'xyz.lib'"

The issue seems to be a failure with Intel Fortran 15.0.1.148 to recognize the UNC path name used in the "Additional Library Dependencies" setting in Visual Studio under Project Configuration Properties -> Linker -> General which translates to /LIBPATH:"\\server\share\file_path" option for the linker.

Now if I add an extra backslash to the UNC path name at the beginning i.e., \\\server\share\file_path, then linker works fine with Intel Fortran 15.0.1.148.

Is this an intended and known change between the compiler versions?  I couldn't find any documentation about this.

Thanks,

Compiler Upgrade : Need to verify exe results ?

$
0
0

Hi experts,

I'm planning to upgrade our fortran compiler from Intel Fortran Version 11.1.060 to the latest available. 

I will keep the same compilation flags. 

Is there a risk that the results of my software are different ? In other word, do I need to validate my software ? 

I've more than 100 small programs and this might take me a lot of time. 

I also have the same question if I move from 32bit to 64bits.

Thank you,

Vincent

how can force idb to core dump ?

$
0
0

Is there any  way to force idb to generate a new core dump file for the programmed being debugged? The new core dump should reflect the state of the file at the cursor location as I step though a file.

 

array temporary

$
0
0

when I'm calling ZGEMV using the interface ZGEMV_f95, the following warning appears:

forrtl: warning (406): fort: (1): In call to ZGEMV, an array temporary was created for argument #5

forrtl: warning (406): fort: (1): In call to ZGEMV, an array temporary was created for argument #7

 

How to avoid this warning?


EXECUTE_COMMAND_LINE

$
0
0

 

The fortran 2008 standard and ifort 15 have the EXECUTE_COMMAND_LINE intrinsic subroutine to run a system command.  Also it has an option to run the system command asynchronously.   There is no mention in the documentation about any way to determine from your application which called EXECUTE_COMMAND_LINE  to know when the asynchronous command has completed, or to be able to terminate it when you no longer want to have it continue running.    I just wondered if there was some undocumented method for doing either of these actions.   It would be something we'd find helpful.

 

thanks,

Scott

 

C# WPF Calling DLL - Unhandled exception of type 'System.EntryPointNotFoundException'

$
0
0

I have created a solution MYAPP.  Within the solution I have a C# WPF (MYAPP) and a Fortran DLL (MYDLL).  A wrapper class (MYWRAPPERCL) calls the Fortran DLL.

 

When I attempt to call the DLL I receive the following message:

 

An unhandled exception of type ‘System.EntryPointNotFoundException’ occurred in MYAPP.exe

 

Additional information: Unable to find an entry point name ‘MYENTRYPT’ in DLL ‘c:\Users\me\My Documents\Visual Studio 2013\Projects\MYAPP\MYDLL\Debug\MYDLL.dll’

 

Here is what I have checked so far; nothing changes the error message:

 

1 - I have altered the call to the DLL as:

   [DllImport(“c:\\Users\\me\\My Documents\\Visual Studio 2013\\Projects\\MYAPP\\MYDLL\ \Debug\\MYDLL.dll",   EntryPoint = "MYENTRYPT", SetLastError = true,

        CharSet = CharSet.Unicode, ExactSpelling = true,

        CallingConvention = CallingConvention.StdCall)]

        public static extern int MYENTRYPT();

 

2 - I have altered the call to the DLL as:

   [DllImport("c:\\Users\\me\\Documents\\Visual Studio 2013\\Projects\\MYAPP\\MYDLL\\Debug\\MYDLL.dll",   EntryPoint = "MYENTRYPT", SetLastError = true,

        CharSet = CharSet.Unicode, ExactSpelling = true,

        CallingConvention = CallingConvention.StdCall)]

        public static extern int MYENTRYPT();

 

3 - I have altered the call to the DLL as:

   [DllImport("MYDLL.dll",   EntryPoint = "MYENTRYPT", SetLastError = true,

        CharSet = CharSet.Unicode, ExactSpelling = true,

        CallingConvention = CallingConvention.StdCall)]

        public static extern int MYENTRYPT();

 

4 - In Solution Explorer/Properties the Project Folder for the MYDLL is set to:

      c:\Users\me\Documents\Visual Studio 2013\Projects\MYAPP\MYDLL\

 

5 - I verified that the DLL is located in: 

     c:\Users\me\My Documents\Visual Studio 2013\Projects\MYAPP\MYDLL\Debug

 

6 - Linker command line for MYDLL:

/OUT:"Debug\PMC.dll" /VERBOSE /INCREMENTAL:NO /NOLOGO /MANIFEST /MANIFESTFILE:"Debug\MYDLL.dll.intermediate.manifest" /MANIFESTUAC:"level='asInvoker' uiAccess='false'" /DEBUG /PDB:"C:\Users\me\Documents\Visual Studio 2013\Projects\MYAPP\MYDLL\Debug\MYDLL.pdb" /SUBSYSTEM:WINDOWS /IMPLIB:"C:\Users\me\Documents\Visual Studio 2013\Projects\MYAPP\MYDLL\Debug\MYDLL.lib" /DLL

 

History

- Other projects (other than dll) compiled and run from the Projects subdirectory compile and execute without exception.

- At one point in time I renamed the DLL folder to MYDLL; was able to compile and link successfully after the change.  

 

 

Porblem/Bug for GET_ENVIRONMENT_VARIABLE with MPI

$
0
0

Dear Fortran !!

In the following (a hello world kind) program, I try to read the processor's name where images are running.

Each process can read the processor's name with a EXECUTE_COMMAND_LINE("echo $HOSTNAME")

but with GET_ENVIRONMENT_VARIABLE(...), nothing is read (ios /=0)

Note that a single image works well  (mpiexec.hydra -genvuser ./Hello_world_mpi.exe  is Ok)

Executable is made with :

ifort -I/softs/intel/impi/5.0.1.035/intel64/include/ Hello_world_mpi.f90 -o Hello_world_mpi.exe -L/softs/intel/impi/5.0.1.035/intel64/l
ib/ -lmpifort -lmpi

We have ifort 15.0.0 and mpi 5.0 (as shown above)

We use mpiexec.hydra with OAR

Bernard

==========================   source code ==============================

Program WHERE_I_AM
   USE mpi
   USE ISO_FORTRAN_ENV, Only: Output => Output_unit
   Implicit None
   Integer :: nb_procs, rank, code, ios = 1
   Character(Len=20) :: env_name, env_value
   !
   Call MPI_INIT(code)
   Call MPI_COMM_SIZE ( MPI_COMM_WORLD , nb_procs , code )
   Call MPI_COMM_RANK ( MPI_COMM_WORLD , rank , code )
   !
   env_name = "HOSTNAME"
   !
   Call EXECUTE_COMMAND_LINE("echo $"//TRIM(env_name))
   !
   Call GET_ENVIRONMENT_VARIABLE(TRIM(env_name),env_value,status=ios)
   If ( ios /= 0 ) Then
      Write(Output,*) "I am the processor WITHOUT NAME number ", rank, " among ", nb_procs
   Else
      Write(Output,"(A,A,A,I2,A,I2)") "I am the processor with name ", TRIM(env_value), "   with rank ", rank, "  among ", nb_procs
   End If
   !
   call MPI_FINALIZE (code)
   STOP " Done !! "
   !
End Program WHERE_I_AM

=========================== an example of bad output ==================================

Note : Images are running on nodes n024, n024, n044 and n048 (4 nodes=

n044
n024
n044
 I am the processor WITHOUT NAME number           29  among           49
 I am the processor WITHOUT NAME number           37  among           49
 I am the processor WITHOUT NAME number           38  among           49
n048
n048
n048
n048
n048
n048
 I am the processor WITHOUT NAME number           26  among           49
 I am the processor WITHOUT NAME number           30  among           49
 I am the processor WITHOUT NAME number           44  among           49
 I am the processor WITHOUT NAME number           25  among           49
n024
 I am the processor WITHOUT NAME number           48  among           49
 I am the processor WITHOUT NAME number           46  among           49
 I am the processor WITHOUT NAME number           47  among           49
 I am the processor WITHOUT NAME number           45  among           49
n010
 I am the processor WITHOUT NAME number           43  among           49
n024
n024
 I am the processor WITHOUT NAME number           17  among           49
 I am the processor WITHOUT NAME number           18  among           49
 I am the processor WITHOUT NAME number           16  among           49
n024
 I am the processor WITHOUT NAME number           28  among           49
n024
 I am the processor WITHOUT NAME number           35  among           49
n024
 

 

OOP fortran: can not make a subroutine execute different objects

$
0
0

I need some help please.
In this code I create two objects (MM and FF) that extend an abstract
object (MF). Then I have a subroutine (execute_MM_or_FF) that is
supposed to handle both objects (MM and FF).
I tried several ways of doing it but none worked; this is an example
for which I get the error message
error #8169: The specified interface is not declared.   [OUTPUT]
What is the problem with this code? thanks

!===================================
module Abstract_class_m

    implicit none
    private

    type , abstract , public :: MF
    contains
        procedure (output_info) , deferred :: output
    end type

    abstract interface

        subroutine output_info( me , iter)
            import :: MF
            class(MF) , intent(in) :: me
            Integer   , intent(in) :: iter
        end subroutine

    end interface

end module Abstract_class_m
!===================================
module MM_class_m

    use Abstract_class_m

    implicit none

    private

    public :: MM

    type,extends(MF):: MM
        integer                  :: ITMAX = 200
        character (len=2)       :: driver
    contains
        procedure :: output => output_MM
    end type MM

    interface MM
        module procedure  constructor
    end interface

contains

function constructor( ) result( me )
implicit none

type(MM) :: me

!local variable ...

me % driver = "MM"

end function constructor
!
!
subroutine output_MM( me , iter)
implicit none
class(MM)   , intent(in) :: me
integer     , intent(in) :: iter

print*, me%driver , iter

end subroutine output_MM

end module MM_class_m
!===================================

!===================================
module FF_class_m

    use Abstract_class_m

    implicit none

    private

    public :: FF

    type,extends(MF):: FF
        integer                  :: ITMAX = 20
        character (len=2)       :: driver
    contains
        procedure :: output => output_FF
    end type FF

    interface FF
        module procedure  constructor
    end interface

contains

function constructor( ) result( me )
implicit none

type(FF) :: me

!local variable ...

me % driver = "FF"

end function constructor
!
!
subroutine output_FF( me , iter)
implicit none
class(FF)   , intent(in) :: me
integer     , intent(in) :: iter

print*, me%driver , iter

end subroutine output_FF

end module FF_class_m
!===================================
module execute_MM_or_FF

        use MM_class_m          , only: MM
        use FF_class_m          , only: FF
        use Abstract_class_m    , only: MF

        implicit none

        public :: execute

        private

        type, extends(MF) :: OBJ
            integer          :: ITMAX
            character(len=2) :: driver
        contains
            procedure :: output
        end type

contains

subroutine execute( me , n )
class(OBJ) , intent(inout) :: me
integer    , intent(in)    :: n

    print*, me%itmax
    call me%output(n)

end subroutine execute

end module execute_MM_or_FF
!===================================

program test

use FF_class_m , only: FF
use MM_class_m , only: MM

character(2) :: driver = "MM"
integer      :: iter = 3

type(MM) :: a
type(FF) :: b

if(driver == "MM") then
    a = MM()
    call execute_MM_or_FF(a,iter)
else
    b = FF()
    call execute_MM_or_FF(b,iter)
end if

end program test

Compiler 15, update 1 allows NAME= specifier in an ABSTRACT INTERFACE; is it right?

$
0
0

As per the current Fortran standard (C1254), my reading is NAME= specifier should not be allowed in an ABSTRACT INTERFACE

but the compiler raises no errors or warnings with the following code:

   MODULE m

      USE, INTRINSIC :: ISO_C_BINDING, ONLY : C_INT
      !..
      IMPLICIT NONE

      !..
      ABSTRACT INTERFACE

         FUNCTION foo() RESULT(RetVal) BIND(C, NAME="foo")

            IMPORT :: C_INT

            !.. Function result
            INTEGER(C_INT) :: RetVal

         END FUNCTION foo

         SUBROUTINE bar() BIND(C, NAME="bar")

         END SUBROUTINE bar

      END INTERFACE

   END MODULE m

Comments?

Any way to FORCE integer overflow checking ?

$
0
0

I have a program that gives mysterious results when the sizes of the integers get to be above a certain threshold.

Finding where the overflow occurs is proving to be very elusive, since no trap is generated.

Is this something that's a integral part of the INTEL processor?

For example, could that be checked at the machine code level?

Example: check if A*B is correct - -  (Fortran source)

c=a*b

if(a>0 .and. b<0 .and. c <0) .or. &

(a<0 .and. b<0 .and. c <0) .or. &

(a>0 .and. b<0 .and. c >0) .or. &

(a<0 .and. b>0 .and. c >0) then

   etc. etc. 

But this is extremely awkward putting that everywhere in the code.

And it does not always catch a bad result. You can have a wrong answer with the correct sign.

another approach is do write a special routine to do basic add, multiply, sub, etc.

Notice that using higher precision integers does NOT guarantee you will get accurate results -

 

If A and B are both int8, then most of the time the result will be wrong.

If A and B are both int4, then you have to FORCE it to use INT8 arithmetic, or

the result will almost always be wrong.

Example: C=int8(a)*b

The problem is far worse with the ** operator, for example if A and B are just one byte integers,

and you say c=int8(a)**b then the result will almost always be wrong.

 

So, other than going to machine code, is there a way around this?

What about the C++ approach? Well, it doesn;t have as many choices for integer size -

 

 

Calling a dll from a dll

$
0
0

 I need to break a library of functions into a number of separate dlls.

How do I call a dll from within a dll?

Can I do it within the same solution?

Do I need to specify a library for the linker?

Current attempt:

!DEC$ ATTRIBUTES DLLEXPORT::G_Trend
!DEC$ ATTRIBUTES ALIAS:'G_Trend' :: G_Trend
!DEC$ ATTRIBUTES DLLIMPORT, ALIAS: 'G_Filter' ::G_Filter

( blah, blah, blah)

 Call G_Filter(pdlen, lg, psh, lnc, tmp1)

gives the error

>G_Trend.obj : error LNK2019: unresolved external symbol __imp_G_Filter referenced in function G_Trend
2>Debug\G_Trend.dll : fatal error LNK1120: 1 unresolved externals

The G_Filter function compiles and works great.( Tested by calling with netlink in mathematica)

G_Filter and G_Trend are in different projects under the same solution.

Thanks

Frank

 

 

 


change COMMON to MODULE

$
0
0

We are using an old FORTRAN program which I am trying to set up to date.

One of the main change is converting COMMONs to MODULEs.

But most of the COMMONs include STRUCTUREs which are in an INCLUDE file :

File DECLAR.f90

    structure /drap/

      integer*4 art

      integer*4 col

     end structure

 

Subroutine B

    subroutine b   

    include "declar.f90"   

    type (drap) d1,d2   

    common /ddarp/ d1   

    d1=d2

    return

    end

Program A

   program a   

    include "declar.f90"   

    type (drap) d1,d3   

    common /ddarp/ d1   

    call b

    d3=d1

    end

 

I did change it to :

   module structure_drap   

     structure /drap/

      integer*4 art

      integer*4 col

     end structure

    end module structure_drap

   

    module ddrap

     use structure_drap     

     type (drap) d1    

    end module ddrap   

    subroutine b

   

    use structure_drap

    use ddrap   

    type (drap) d2   

    d1=d2   

    return

    end

   

    program a   

    use structure_drap

    use ddrap   

    type (drap) d3   

    d3=d1   

    return

    end

 

The compiler output the following error :

  This type/structure name has been defined more than once. (DRAP)

 

Note that every module, every subroutine and the main programs are different files and I build all the subroutines a static library.

 

I tried to have 2 different STRUCTUREs DRAP1 and DRAP2, but then the compiler refuses d1=d2 and d3=d1.

 

How can I do ?

 

 

 

And other problem using INTERFACE : the compiler outputs and error when compiling a subroutine together with its INTERFACE. It is very complicated to turn around that + it would be a double check if the compiler could verify the compatibility of the subroutine and its INTERFACE.

 

 

 

 

File extension for free form, included code files?

$
0
0

My code uses extensively #INCLUDE statements for bits and pieces of code. Right now these bits and pieces are files with the extension *.f90. This allows Visual Studio (2013) to correctly perform the syntactic highlighting of these included files. I would like however to assign to these included files a different extension (to distinguish them from the 'parents' files, which are properly formed source files), while retaining the syntactic highlighting capability.

Is there a way to do this in Visual Studio 2013?
 

Intel Fortran Compiler Diagnostics 5000-5499

$
0
0

Back to All Intel Fortran Diagnostics

  • Apple OS X*
  • Linux*
  • Microsoft Windows* (XP, Vista, 7)
  • Fortran
  • Compilateur Intel® Fortran
  • Intel® Fortran Composer XE
  • Intel® Visual Fortran Composer XE
  • URL
  • Zone des thèmes: 

    IDZone

    Intel Fortran Compiler Diagnostics 5500-5999

    $
    0
    0

    Back to All Intel Fortran Compiler Diagnostics

  • Développeurs
  • Apple OS X*
  • Linux*
  • Microsoft Windows* (XP, Vista, 7)
  • Fortran
  • Compilateur Intel® Fortran
  • Intel® Fortran Composer XE
  • Intel® Visual Fortran Composer XE
  • URL
  • Zone des thèmes: 

    IDZone

    Intel Fortran Compiler Diagnostics 6000-6499

    $
    0
    0

    Back to All Intel Fortran Compiler Diagnostics

  • Développeurs
  • Apple OS X*
  • Linux*
  • Microsoft Windows* (XP, Vista, 7)
  • Fortran
  • Compilateur Intel® Fortran
  • Intel® Fortran Composer XE
  • Intel® Visual Fortran Composer XE
  • URL
  • Zone des thèmes: 

    IDZone
    Viewing all 3108 articles
    Browse latest View live


    <script src="https://jsc.adskeeper.com/r/s/rssing.com.1596347.js" async> </script>