Quantcast
Channel: Intel® Fortran Compiler
Viewing all 3270 articles
Browse latest View live

module design

$
0
0

I have two questions about "modules":

1. For explicit procedure declaration(that is declaring a subroutine in a module), is it better to put every subroutine in a separate module, or putting more subroutines in a module won't cause any problem? 

2. In the following code, subroutine Z has different functionalities in modules A and B(module A and B might be in different source files). How can I distinguish between them?

module A
...
implicit none
contains
   subroutine Z(x,y)
...
   end subroutine Z
end module A

module B     
...
implicit none
contains
   subroutine Z(x,y)
...
   end subroutine Z
end module B

!!! Main program
program check
use A
use B
....
implicit none
...
call Z(x,y)     !!!! which Z???? ERROR

 

Thanks. 


Interface questions

$
0
0

I am currently modifying a windows/Fortran application to use Unicode text in all the menu's and dialogs and after a few technical issues this seems to be progressing OK.

The SDK has two versions of all routines that take text, for example WriteConsole is the generic but we have   WriteConsoleA (ansi text version) and  WriteConsoleW (Unicode text version). It seems that in all the IFWIN sub-sets the generic routine always interfaces to the A version and the W interface is always absent, As such I am having to provide my own interfaces, is there any plan to add these missing interfaces? It seems strange in this day and age  to have a Windows Fortran that does not support the method of choice for language support of windows!

My second question relates to the code snippet below from USER32.f90. The AppendMenu interface has AppendMenu_G1 and AppendMenu_G2 functions, does the compiler select which function to use based on the types of the arguments in the call?

INTERFACE AppendMenu

	FUNCTION AppendMenu_G1( &

	        hMenu, &

	        uFlags, &

	        uIDNewItem, &

	        lpNewItem)

	use ifwinty

	  integer(BOOL) :: AppendMenu_G1 ! BOOL

	    !DEC$ ATTRIBUTES DEFAULT, STDCALL, DECORATE, ALIAS:'AppendMenuA' :: AppendMenu_G1

	  integer(HANDLE) hMenu ! HMENU hMenu

	  integer(UINT) uFlags ! UINT uFlags

	  integer(UINT_PTR) uIDNewItem ! UINT_PTR uIDNewItem

	!DEC$ ATTRIBUTES REFERENCE, ALLOW_NULL :: lpNewItem

	  character*(*) lpNewItem ! LPCSTR lpNewItem

	 END FUNCTION

	FUNCTION AppendMenu_G2( &

	        hMenu, &

	        uFlags, &

	        uIDNewItem, &

	        lpNewItem)

	use ifwinty

	  integer(BOOL) :: AppendMenu_G2 ! BOOL

	    !DEC$ ATTRIBUTES DEFAULT, STDCALL, DECORATE, ALIAS:'AppendMenuA' :: AppendMenu_G2

	  integer(HANDLE) hMenu ! HMENU hMenu

	  integer(UINT) uFlags ! UINT uFlags

	  integer(UINT_PTR) uIDNewItem ! UINT_PTR uIDNewItem

	  integer(LPVOID) lpNewItem ! LPCSTR lpNewItem

	 END FUNCTION

	END INTERFACE

problem getting IVF compiler running

$
0
0

I purchased the latest version of IVF compiler for Windows 8 last week, having already checked out the trial version a couple of months ago.  I believe I managed to download the code OK and even the installation seemed to go well, except at the very end when it asks me to hit ‘finish’, it says that I would be sent to the ‘start page’, but wasn’t.  I am having problems running the IVF compiler – I’m stuck on the page which is included in the attachment.  I have also attached some correspondence showing proof o f purchase and product serial #.  I find I cannot go any further as I do not know my license code even though a file containing that info was attached.  The start page also mentions about my license having already expired.   I am assuming that the product I have just purchased will allow me to do exactly what I had been doing before when operating on Windows 7 – correct?

I would appreciate if you could let me know what I am missing in getting IVF compiler running – thanks.

 

 

Memory used by extended types

$
0
0
Hello.  

I have found something weird in the memory used when a derived type extends another but I do not know if there is an explanation for this or if it is just a bug.

The simplified program below works as I would expect only when the default initialization of the Parent type (N = 0) is commented. When I uncomment the initialization the memory reported by the Windows Task Manager is twice the expected one and after the deallocation not all the memory seems to be released (at the pause statement before the program end).  
program Test
  type Parent
    integer :: N != 0
  end type
  type, extends(Parent) :: Extended
    real(8) :: M(2000,2000)
  end type
  type(Extended), pointer:: Var
  allocate(Var)
  Var%M = 0d0
  pause
  deallocate(Var)
  pause
end program Test
 

Thanks in advance.

 

Windows 8.1: libifcoremd.dll is missing

$
0
0
I see the following Runtime Error Message when executing a simple program under Windows 8.1. Any suggestions?
I did a clean install of Win 8.1 and all software....still have problem..

Runtime Error Message:

"This program can't start because libifcoremd.dll is missing from your computer.
Try reinstalling the program to fix this problem."

libifcoremd.dll Location on Computer:

C:\Program Files (x86)\Common Files\Intel\Shared Libraries\redist\ia32\compiler
C:\Program Files (x86)\Common Files\Intel\Shared Libraries\redist\intel64\compiler
C:\Program Files (x86)\Intel\Composer XE\redist\ia32\compiler
C:\Program Files (x86)\Intel\Composer XE\redist\intel64\compiler
C:\Program Files (x86)\Intel\Composer XE 2013 SP1\redist\ia32\compiler
C:\Program Files (x86)\Intel\Composer XE 2013 SP1\redist\intel64\compiler

Configuration Summary:

Microsoft Windows 8.1 Pro
Microsoft Visual Studio Professional 2012 Update 4
Intel Parallel Studio XE for Windows (all tools) 2013 SP1 Update 2 VS

Environment Variables:

ADVISOR_XE_2013_DIR=C:\Program Files (x86)\Intel\Advisor XE 2013\
ALLUSERSPROFILE=C:\ProgramData
APPDATA=C:\Users\Jack\AppData\Roaming
CommonProgramFiles=C:\Program Files\Common Files
CommonProgramFiles(x86)=C:\Program Files (x86)\Common Files
CommonProgramW6432=C:\Program Files\Common Files
COMPUTERNAME=SPRO14
ComSpec=C:\windows\system32\cmd.exe
FP_NO_HOST_CHECK=NO
HOMEDRIVE=C:
HOMEPATH=\Users\Jack
ICPP_COMPILER14=C:\Program Files (x86)\Intel\Composer XE 2013 SP1\
IFORT_COMPILER14=C:\Program Files (x86)\Intel\Composer XE 2013 SP1\
INSPECTOR_XE_2013_DIR=C:\Program Files (x86)\Intel\Inspector XE 2013\
INTEL_DEV_REDIST=C:\Program Files (x86)\Common Files\Intel\Shared Libraries\
INTEL_LICENSE_FILE=C:\Program Files (x86)\Common Files\Intel\Licenses
LOCALAPPDATA=C:\Users\Jack\AppData\Local
LOGONSERVER=\\MicrosoftAccount
MIC_LD_LIBRARY_PATH=%INTEL_DEV_REDIST%compiler\lib\mic
NUMBER_OF_PROCESSORS=4
OS=Windows_NT
Path=%INTEL_DEV_REDIST%redist\intel64\mpirt;%INTEL_DEV_REDIST%redist\ia32\mpirt;%INTEL_DEV_REDIST%redist\intel64\compiler;%INTEL_DEV_REDIST%redist\ia32\compiler;C:\Program Files\SlickEditV18.0.1 x64\win\;C:\windows\system32;C:\windows;C:\windows\System32\Wbem;C:\windows\System32\WindowsPowerShell\v1.0\;C:\Program Files\Microsoft\Web Platform Installer\;C:\Program Files (x86)\Microsoft ASP.NET\ASP.NET Web Pages\v1.0\;C:\Program Files (x86)\Windows Kits\8.0\Windows Performance Toolkit\;C:\Program Files\Microsoft SQL Server\110\Tools\Binn\
PATHEXT=.COM;.EXE;.BAT;.CMD;.VBS;.VBE;.JS;.JSE;.WSF;.WSH;.MSC
PROCESSOR_ARCHITECTURE=AMD64
PROCESSOR_IDENTIFIER=Intel64 Family 6 Model 69 Stepping 1, GenuineIntel
PROCESSOR_LEVEL=6
PROCESSOR_REVISION=4501
ProgramData=C:\ProgramData
ProgramFiles=C:\Program Files
ProgramFiles(x86)=C:\Program Files (x86)
ProgramW6432=C:\Program Files
PROMPT=$P$G
PSModulePath=C:\windows\system32\WindowsPowerShell\v1.0\Modules\
PUBLIC=C:\Users\Public
SESSIONNAME=Console
SystemDrive=C:
SystemRoot=C:\windows
TEMP=C:\Users\Jack\AppData\Local\Temp
TMP=C:\Users\Jack\AppData\Local\Temp
USERDOMAIN=SPRO14
USERDOMAIN_ROAMINGPROFILE=SPRO14
USERNAME=Jack
USERPROFILE=C:\Users\Jack
VS110COMNTOOLS=C:\Program Files (x86)\Microsoft Visual Studio 11.0\Common7\Tools\
VTUNE_AMPLIFIER_XE_2013_DIR=C:\Program Files (x86)\Intel\VTune Amplifier XE 2013\
windir=C:\windows

Inquire statement with -openmp option

$
0
0

Dear forum,

I actually use Intel composer_xe_2013_sp1.2.144 with openMP.

I separated the following issue from my software project. The program fails to execute in case of using

INQUIRE (FILE= ... , OPENED= ...) together with the -openmp option, see example.

Otherwiese, without -openmp option or without the statement every things works fine.

      PROGRAM test
      IMPLICIT NONE
      CHARACTER(255) :: datei
      LOGICAL :: lopen
      LOGICAL :: lexists
!
      datei = 'dateiname.dat'
!
!     This situation work fine in all test cases.
      INQUIRE (FILE=datei,EXIST=lexists)
!
!     This situation fails if combined with the -openmp option
      INQUIRE (FILE=datei,OPENED=lopen)
      END PROGRAM test

Can somebody comment on this problem? Thankyou

 

OMP_GET_WTIME and names as_is option

$
0
0

When testing Fortran with the ffte (Version 6.0; http://www.ffte.jp/) I came across the following issue:

The code uses a call OMP_GET_WTIME for runtime measurement. When using everything without modification, everything works fine. When I added the compiler option "-names as_is" I get the error, that the function cannot be found. OpenMP uses the function name "omp_get_wtime" so I changed the two calls. When I compile the source now (with -names as_is) I get different strange-looking (wrong) results. After removing names as_is the code compiles again and produces correct results again.

Does anyone know what causes this behaviour? I suspect that a different module/interface is used causing wrong times to be reported but I cannot confirm that.

Fotran pointers traveling through C++ code

$
0
0

Dear all,

I read a lot of tutorials about calling Fortran functions from C++ code, and I was wondering if it was possible to call a Fortran function from C++ code with pointers arguments that come from Fortran without declaring the pointed type in C++.

Let me explain: I created a derived type in Fortran, which contains a lot of derived types. I would like to be able to insert a layer of C++ between a call from one Fortran subroutine to another, and I would like to avoid to redefine the Fortran derived types in C++, something like:

module my_module
  implicit none

	 

	  type :: my_type

	    real :: x

	  end type my_type

	 

	end module my_module
subroutine fortran_subroutine(b)
  use my_module

	  implicit none
  type(my_type), pointer, intent(in) :: b
  print *, b%x
end subroutine fortran_subroutine
program test

	 

	  use my_module

	  implicit none
  abstract interface

	      subroutine sub (b)

	        import :: my_type

	        type(my_type), pointer, intent(in) :: b

	      end subroutine sub

	  end interface
  type(my_type), pointer :: a
  procedure (sub), pointer :: f_ptr => null ()

	  procedure (sub) :: fortran_subroutine
  allocate(a)

	  a%x = 1.0
  f_ptr => fortran_subroutine

	  call c_plus_plus_layer(f_ptr,a)
end program

extern "C"

	{

	  void c_plus_plus_layer_(void (*pointer_to_fortran_function)(void **), void ** x);

	}
// Intermediate layer of C++ designed to launch a Fortran subroutine

	// which doesn't have any argument

	void c_plus_plus_layer_(void (*pointer_to_fortran_function)(void **), void ** x)

	{

	  pointer_to_fortran_function(x);

	}

 

Thank you for your help !


Intel Visual Fortran XE 2013 and the TFS Build System

$
0
0

I have installed Intel Fortran XE 2013 SP 1 on our Build Server. I was expecting the TFS Build System (MSBuild) to be able to build my Intel Fortran XE 2013 SP 1 project. However I get a "must be opened in the Visual Studio IDE and converted to the latest version" message. Does this indicate that Intel Fortran is not integrated with the TFS Build system? If so, how should I proceed given that I have several Fortran projects I was hoping to be able to build in the build definition?

Compile under dos command line

$
0
0

I just purchased the Intel Visual Fortran composer XE 2013 SP1 for Windows with IMSL; OS Windows 7.

What is the syntax to compile a fortran program directly in dos command line? (I try to avoid the MS Visual environment).

I tried ifort, fl90, does not work.

Thanks:  Eva
 

Finalizer with allocatable components

$
0
0

Hello,

I am trying to understand how finalizers work in Fortran.

I have written a minimal test program containing a derived type with just a final procedure and an allocatable component.

It appears that the finalizer is called more that once, and I don't understand why.

I noticed this behaviour only if the derived type contains an allocatable component, and if more than one object is instantiated from that class.

Here is the code :

module finalizer_module
implicit none
type :: obj
    real,allocatable :: var
    contains
        final :: clean
end type
contains
    subroutine clean(this)
    type(obj) :: this
        write(*,*) "in finalizer"
    end subroutine clean
end module finalizer_module
!
program test_finalizer
use :: finalizer_module
    call sub
contains
    subroutine sub
    type(obj) :: f1,f2
    end subroutine sub
end program test_finalizer

And here the output :

 in finalizer
 in finalizer
 in finalizer

I think I should have only two "in finalizer", as I have two objects (f1,f2) that are destroyed at "end subroutine sub"?

NB:

$ ifort --version
ifort (IFORT) 14.0.2 20140120

 

"Traveling" forrtl: severe(408): fort (2): error

$
0
0

I am using Intel Fortran Compiler 14.02.2.14.

I am compiling with the following flags " -fpp -O0 -check all -traceback -g -vec-report0 -debug all  -heap-arrays -ftrapuv".

I keep on getting errors of the type: "forrtl: severe (408): fort: (2): Subscript #2 of the array XXXXX has value 1 which is greater than the upper bound of 0" where the array XXXX that seems to be the culprit of the error changes as I try to fix the problem.

In addition to the problem of the traveling error, I cannot figure out what is going wrong for the following reason. It is not uncommon that, all the times I get this error, I perform some operations on the second subscript of the array a few lines before I get the error. For example:

array(1,10) = 1.d0 ! -- ok

! -- some code

array(1,1) = 0.d0 ! -- forrtl: severe (408) etc.etc.

I apologize, but it is impractical to report the full code here, because the code base is large, and the error is "traveling" from place to place.

This behavior smells like memory error, but I think I am turning on all flags that should point me to an error like that. I am looking for some suggestion on how to move from here.

I am sorry about the choppy message, but I am having an hard time figuring out what is going on.

Use of tiny / 2

$
0
0

I have been trying to understand the use of the intrinsic TRANSFER, to store a mixture of integer and real values in an integer array and then recover them. I had hoped to do this in a more standard conforming way.
Anyway, I experimented with TINY to see how real zero might look. I wrote the following program to test real underflow and how this might be stored.

  integer*4, parameter :: sp = selected_real_kind (p=6)
   real(sp) :: x

	   integer*4 i(4),j

	!

	   i = 0

	   write (*,*) 'test for real kind =',sp, kind(1.0), kind(1.0d0)

	   x = 1

	   i(1) = transfer (x,j)

	   write (*,*) '1   ', x, i

	!

	   x = tiny(x)

	   i(1:2) = transfer (x,j,2)

	   write (*,*) 'tiny', x, i

	!

	   x = x/2

	   i(1:2) = transfer (x,j,2)

	   write (*,*) 'x/2 ', x, i

	!

	   end

this produced the following result:

Intel(R) Visual Fortran Compiler XE for applications running on IA-32, Version 12.1.5.344 Build 20120612
Copyright (C) 1985-2012 Intel Corporation.  All rights reserved.

Microsoft (R) Incremental Linker Version 10.00.30319.01
Copyright (C) Microsoft Corporation.  All rights reserved.

-out:tiny2.exe
-subsystem:console
tiny2.obj
 test for real kind =           4           4           8
 1      1.000000      1065353216           0           0           0
 tiny  1.1754944E-38     8388608           0           0           0
 x/2   5.8774718E-39     4194304           0           0           0

To my surprise x/2 is not zero !

My aim is to transfer 4 byte and 8 byte reals into an integer*4 vector for later recovery, but I thought I'd test a 4 byte real first. I find the use of the size argument of TRANSFER a bit confusing.

John

Warning 10182

$
0
0

Which compiler switches are causing this warning, and where do I find them in VS?

warning #10182: disabling optimization; runtime debug checks enabled

Thanks,

David

Why the result depends on -g option and type of function

$
0
0

Just a small program.

      REAL(8) FUNCTION DUMMY(i)
      implicit none
      integer, intent(in) :: i

      DUMMY=dble(i)
      write(*,*) 'i=', dble(i),'res=',DUMMY

      RETURN
      END FUNCTION


      program test
      real(8) :: xxx

      xxx=DUMMY(2)
      write(*,*) 'xxx=',xxx

      stop
      end program

If I do    ifort -o test test.f    the result is
 i=   2.00000000000000      res=   2.00000000000000     
 xxx=   2.00000000000000
But with   ifort -g -o test test.f    the result is
 i=   2.00000000000000      res=   2.00000000000000     
 xxx=  0.000000000000000E+000

The result is also depend on type of my function. If I put REAL DUMMY(i) instead of REAL(8) DUMMY(i) then the result will be always correct.

ifort -V
Intel(R) Fortran Intel(R) 64 Compiler XE for applications running on Intel(R) 64, Version 14.0.2.144 Build 20140120
Copyright (C) 1985-2014 Intel Corporation.  All rights reserved.
FOR NON-COMMERCIAL USE ONLY


MPICH2-1.5 Install problem - help!

$
0
0

I am trying to install mpich2-1.5 on my linux system (RHEL 6.5) but I can't

The configure failed showing

configure error: ***** Incompatible Fortran and C Object File Types! *****

F77 object file type produced by 'ifort' is ::ELF 32-bit LSB relocatable, Intel 80386. version 1 (GNU/Linux). not stripped.

C object file type produced by 'gcc -02' is ::ELF 64-bit LSB relocatable. x86-64. version 1 (SYSV). not striped.

 

I am using 64 bit system and installed intel parallel studio 2013 (evaluation version)

 

ifort 14.0.2 bug prevents scipy tests to pass

$
0
0

I've tried to use Intel MKL with numpy 1.8.0 and scipy 0.13.3 python packages.

When I use -O2 option for ifort scipy tests in scipy.odr subpackage fails everytime.

Using -O1 instead of -O2 results in passing the tests.

Here is detailed description of bug: http://software.intel.com/en-us/forums/topic/505993

error PRJ0019 for 'link' tool

$
0
0

I have error PRJ0019 during linking my quickwin project (possibly for 'link' tool).
This error comes only in x64 platform (not in 32 bit)
The objectives

Intel(R) Visual Fortran Compiler XE 12.1.1.258 [IA-32]
Intel(R) Visual Fortran Compiler XE 12.1.1.258 [Intel(R) 64]
under MS visual studio 2010 SP1
Windows 7, 64 bit
Build Log
Build started: Project: Sph_proj, Configuration: Release|x64
Output
Compiling manifest to resources...
rc.exe /fo "D:\Programs\SPH_New_3_10\HD\Sph_proj\x64\Release\sph3D_intx64.exe.embed.manifest.res""D:\Programs\SPH_New_3_10\HD\Sph_proj\x64\Release\sph3D_intx64.exe.embed.manifest.rc"
Microsoft (R) Windows (R) Resource Compiler Version 6.1.6723.1
Copyright (C) Microsoft Corporation. All rights reserved.

Linking...
Creating temporary file "RSP1.rsp" with contents
[
/OUT:"x64\Release\sph3D_intx64.exe" /NOLOGO /LIBPATH:"C:\Program Files (x86)\Intel\Composer XE 2011 SP1\\mkl\lib\intel64" /LIBPATH:"C:\Program Files (x86)\Intel\Composer XE 2011 SP1\\redist\intel64\mkl" /MANIFEST /MANIFESTFILE:"D:\Programs\SPH_New_3_10\HD\Sph_proj\x64\Release\sph3D_intx64.exe.intermediate.manifest" /MANIFESTUAC:"level='asInvoker' uiAccess='false'" /SUBSYSTEM:WINDOWS /IMPLIB:"D:\Programs\SPH_New_3_10\HD\Sph_proj\x64\Release\sph3D_intx64.lib" vfw32.lib mkl_intel_thread.lib mkl_core.lib "x64\Release\param.obj""x64\Release\Palettin.obj""x64\Release\Utilin.obj""x64\Release\Listin.obj""x64\Release\Filein.obj""x64\Release\SingStepin.obj""x64\Release\consolin.obj""x64\Release\Dialin.obj""x64\Release\Commandin.obj""x64\Release\AVIin.obj""x64\Release\vararrays.obj""x64\Release\Linklin.obj""x64\Release\Graphin.obj""x64\Release\Tensin.obj""x64\Release\Ggridin.obj""x64\Release\Fmenu.obj""x64\Release\Timingin.obj""x64\Release\grid_geom.obj""x64\Release\begdata_cmnd.obj""x64\Release\DefGwin3D.obj""x64\Release\Grinit.obj""x64\Release\ObjProc.obj""x64\Release\divV.obj""x64\Release\PicPpress.obj""x64\Release\Savefile.obj""x64\Release\Data_input.obj""x64\Release\NewTimeStep.obj""x64\Release\CornMirror.obj""x64\Release\PicFsound.obj""x64\Release\Point.obj""x64\Release\TuneProc.obj""x64\Release\eos_u_call.obj""x64\Release\art_visc.obj""x64\Release\DefGwin.obj""x64\Release\Graphics.obj""x64\Release\MirrProc.obj""x64\Release\variable_time_step.obj""x64\Release\Density_Int.obj""x64\Release\PicPmass.obj""x64\Release\SaveAVI.obj""x64\Release\CmdLine.obj""x64\Release\Mises.obj""x64\Release\BndMirror.obj""x64\Release\PicFpress.obj""x64\Release\Picture.obj""x64\Release\TstepProc.obj""x64\Release\eos_u.obj""x64\Release\PicPType3D.obj""x64\Release\time_print.obj""x64\Release\InterfProc.obj""x64\Release\Value_Rates.obj""x64\Release\Density_cont.obj""x64\Release\PicPenergy.obj""x64\Release\PWoutput.obj""x64\Release\AVIdraw.obj""x64\Release\link_list.obj""x64\Release\PicFenergy.obj""x64\Release\Main.obj""x64\Release\TmetProc.obj""x64\Release\eos_call.obj""x64\Release\PicPType.obj""x64\Release\time_elapsed.obj""x64\Release\DomProc.obj""x64\Release\Time_Int_PC.obj""x64\Release\DefPtlMass.obj""x64\Release\PicPdens.obj""x64\Release\PsearchStat.obj""x64\Release\AVIcreate.obj""x64\Release\kernel.obj""x64\Release\PicFdens.obj""x64\Release\Loadfile.obj""x64\Release\TimeProc.obj""x64\Release\eos.obj""x64\Release\picPstr.obj""x64\Release\SavePointAs.obj""x64\Release\ADisProc.obj""x64\Release\Tens.obj""x64\Release\DefPosProp3D.obj""x64\Release\PicGcap.obj""x64\Release\PrintStep.obj""x64\Release\AVIclose.obj""x64\Release\i_force.obj""x64\Release\LegndPal.obj""x64\Release\Input_cmnd.obj""x64\Release\PropProc.obj""x64\Release\EdgeMirror.obj""x64\Release\PicPpress3D.obj""x64\Release\SavePCX.obj""x64\Release\Data_inputAVI.obj""x64\Release\sphsub.obj""x64\Release\DefMass_a.obj""x64\Release\PicFvelocity.obj""x64\Release\PointVer00.obj""x64\Release\AddCommands.obj""x64\Release/Script_AVI.res""x64\Release/Script1.res""D:\Programs\SPH_New_3_10\WinKisa14\DWKisad\x64\Release\DWKisad.lib""D:\Programs\SPH_New_3_10\Command_Lib\x64\Release\Command_Lib.lib""D:\Programs\SPH_New_3_10\HD\Sph_proj\x64\Release\sph3D_intx64.exe.embed.manifest.res"
]
Creating command line "Link @"D:\Programs\SPH_New_3_10\HD\Sph_proj\x64\Release\RSP1.rsp""

Link: executing 'link'

Sph_proj : error PRJ0019: A tool returned an error code

Sph_proj - 1 error(s), 0 warning(s)

Help with Fortran Wrapper that Interfaces with C Library

$
0
0

Dear Fortran Gurus,

Let me begin with a disclaimer. I'm not a Fortran developer, but a library that I've written has been adopted by some parallel scientific codes written in Fortran, so I thought I would provide a nice interface to said codes. Until yesterday, I thought I was successful in doing so. I need help. Maybe I'm doing something funky in my C wrapper written in Fortran. I'll get into this later, but my wrapper works perfectly with Intel 13.1.3 20130607, but is completely broken with Intel 14.0.1 20131008. For what it is worth, my Fortran interface also works with all the GFortrans that I've tried.

Background

I have a C library that operates on opaque handles (pointers to opaque typedef'd structs). Users never directly operate on the data contained within these handles (I call them contexts). The first call into my library would look something like (C):

// in my library's header, this is what QUO_context looks like
struct QUO_t;                                                                           
typedef struct QUO_t QUO_t;                                                           
/* external QUO context type */                                                        
typedef QUO_t * QUO_context;
// the definition of QUO_t is in a .c file "hidden" from the rest of the world

// this is an example of how a user would interact with my library in C
QUO_context q = NULL;
QUO_create(&q); // allocates and initializes the context.
// NOTE: QUO_create's signature is really QUO_create(QUO_t **t);
// So, q will point to the allocated struct when the call returns. 
QUO_free(q); // tears down and frees all the initialized infrastructure

A n00bs Fortran Interface

I would like to retain the same abstraction that I've provided in the C interface. That is, I don't want the users to allocate/free the context explicitly. I want the library to do all that in C land and simply set the provided quo_context such that it points to the initialized QUO_t. I thought I had succeeded in doing so, but it appears as if there is a difference between Intel 13.1.3 20130607 and 14.0.1 20131008.

This is what my Fortran interface looks like (any suggestions in implementing this in idiomatic Fortran is also welcome!)

module quo
      use, intrinsic :: iso_c_binding
      type, bind(c) :: quo_context
          type(c_ptr) :: qcp
      end type quo_context
interface
      integer(c_int) &
      function quo_create_c(q) &
          bind(c, name='QUO_create')
          use, intrinsic :: iso_c_binding, only: c_int
          import :: quo_context
          implicit none
          type(quo_context), intent(out) :: q
      end function quo_create_c
end interface

interface
      integer(c_int) &
      function quo_free_c(q) &
          bind(c, name='QUO_free')
          use, intrinsic :: iso_c_binding, only: c_int
          import :: quo_context
          implicit none
          type(quo_context), value :: q
      end function quo_free_c
end interface
contains
      subroutine quo_create(q, ierr)
          use, intrinsic :: iso_c_binding, only: c_int
          implicit none
          type(quo_context), intent(out) :: q
          integer(c_int), intent(out) :: ierr
          ierr = quo_create_c(q)
      end subroutine quo_create

      subroutine quo_free(q, ierr)
          use, intrinsic :: iso_c_binding, only: c_int
          implicit none
          type(quo_context), value :: q
          integer(c_int), intent(out) :: ierr
          ierr = quo_free_c(q)
      end subroutine quo_free
end module quo

And the user would interact with the Fortran interface thusly:

program quofort
    use quo
    use, intrinsic :: iso_c_binding
    implicit none
    type(quo_context) quoc
    call quo_create(quoc, info)
    call quo_free(quoc, info)
end program quofort

With Intel 13.1.3 20130607, quoc correctly "points" to the allocated struct and I can pass this around within the Fortran code with no problems. With Intel 14.0.1 20131008, quoc doesn't get set properly. What am I doing wrong?

Hopefully this post makes sense.

If this makes things easier, below is a link to the full source.

https://github.com/losalamos/libquo/blob/master/src/quof.f90

Thanks for your help. I really appreciate your time!

-- Sam

UMAT subroutine usage

$
0
0

Hi,

I need to develop a UMAT subroutine for inputting a material model into ABAQUS.

I interfaced ABAQUS 10.1, Visual studio 2008 and Fortran 11.1 successfully(PFA image of abaqus cmd showing PASS)

I then read about UMAT subroutine and started coding it in Fortran 11.1.

But, I am totally confused as to where to use this code. When i debug the code in Fortran 11.1, I got 31 errors, most of which being syntax errors.

Can you please tell me the procedure of inputting an UMAT into ABAQUS.

PFA the code i am using for isotropic elasticity. Please get back to me if there are any errors in it and also any material i've to go through to understand fortran architecture.

It would be great if anyone who have already ran UMAT in abaqus guide me through this and briefly explain
How to use this subroutine if the code is correct?
Can it be successfully debugged in Fortran 11.1?

Suggestions from anybody will be of great use to me as i still am a beginner to this software.

Regards,
Yeshwanth.

Viewing all 3270 articles
Browse latest View live


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