C header for fortran dll to be called from matlab

[bmoumen]

hi everybody
iwantcallmany fortran subroutines from matlab; the mex approach is too difficult forme because i don't know fortran;
but i've generated just a dll for one subroutine us a sample;
the problem is that i don't know how write the correspondant C header

C***********************************************************************
SUBROUTINE LAMBDA (T,XLAM,DXLAM)
C***********************************************************************
C
C COMPUTE INTEGRATION PARAMETER XLAM=LAMBDA FROM PARAMETER T.
C
IMPLICIT REAL*8(A-H,O-Z)
SAVE
COMPLEX*16 A,B,XLAM,DXLAM
COMMON /CNTOUR/ A,B
DXLAM=B-A
XLAM=A+DXLAM*T
RETURN
END
C***********************************************

how i do that;

thank's

[TimP]

Look up iso_C_binding. Honestly, even if you have existing code written in a non-standard 1970 era Fortran dialect, it will be easier to learn a little Fortran than for us to give irrelevant advice. Your Fortran compiler probably documents some advice on legacy interfaces with C, but your time is better spent learning standard methods.

[bmoumen]

Quoting - tim18

Look up iso_C_binding. Honestly, even if you have existing code written in a non-standard 1970 era Fortran dialect, it will be easier to learn a little Fortran than for us to give irrelevant advice. Your Fortran compiler probably documents some advice on legacy interfaces with C, but your time is better spent learning standard methods.

ok
but frankly if you have an example will be better

[Steven_L_Intel1]

I don't see a !DEC$ ATTRIBUTES DLLEXPORT :: LAMBDA in there - without that, the DLL will not export the routine name.

Your use of COMPLEX*16 complicates things, as not until recently has C had a complex type. I am unfamiliar with the use of MATLAB so don't know how a C header would be helpful here.

[bmoumen]

Quoting - Steve Lionel (Intel)

I don't see a !DEC$ ATTRIBUTES DLLEXPORT :: LAMBDA in there - without that, the DLL will not export the routine name.

Your use of COMPLEX*16 complicates things, as not until recently has C had a complex type. I am unfamiliar with the use of MATLAB so don't know how a C header would be helpful here.

thank you steve;
i know that it's not evedent but i dont know if the mex approach is easier or the dll approach;
i want use the fortran source code of the 4nec2dxs (+10000 lines of code)in matlab;
i sent a message for the develloper of this code but he cant help me;
so i'm searching for someones how can give me the best solution

[Steven_L_Intel1]

Perhaps a Matlab forum would be an alternative to get help on this.

[IanH]

Quoting - bmoumen

i know that it's not evedent but i dont know if the mex approach is easier or the dll approach;
i want use the fortran source code of the 4nec2dxs (+10000 lines of code)in matlab;

The question around dll/mex/other_options depends more on how to get the +10000 lines of code to do its useful stuff, rather than details about Matlab-Fortran interfaces. At a conceptual level - how do you provide the code with all the inputs and parameters that it needs? How do you go about getting the results out? How do you interface with the code now, in the absence of Matlab? Why do you want to integrate the two together? Where do you want to manage the any complexity associated with integration? Do you actually need to integrate at a "code" level, or can you do it at some higher level (input/output files, etc)?

You need to understand these aspects first. You've said there are many subroutines, so this is probably not a trivial exercise. "Not knowing fortran" will ... complicate ... this.

Consider the example you used at the start of this thread. It contains variables in common CNTOUR, A and B, that need to be initialised somehow. How (conceptually) does that initialisation happen? Without that initialisation, this subroutine can't do anything useful.

Beyond the above issues, there is actually no robust answer to your specific question for that specific subroutine. There are answers that will work in some situations, one below, but then there are important requirements on the matlab side of things and you are at the mercy of numerous compiler options and calling/naming conventions. Plenty of room for error, not exactly beginner territory. Hence the recommendation around learning and using the C interoperability features made by tim18 above is a good one - it goes a long way towards overcoming some of the pitfalls here. The suggestion would be to either rewrite the routine or provide a wrapper for it that uses this feature. Then the relevant C-header file becomes trivial.

As a minimum change example to the provided "fortran" code, this should work as well as the original routine was ever going to, on IA-32 under Windows with recent versions of ifort and matlab, when compiled with "ifort /dll MatlabDLL.for", on Tuesdays:

MatlabDLL.for

lambda.h

call_LAMBDA.m

See here for a more robust approach.

[bmoumen]

Quoting - IanH

The question around dll/mex/other_options depends more on how to get the +10000 lines of code to do its useful stuff, rather than details about Matlab-Fortran interfaces. At a conceptual level - how do you provide the code with all the inputs and parameters that it needs? How do you go about getting the results out? How do you interface with the code now, in the absence of Matlab? Why do you want to integrate the two together? Where do you want to manage the any complexity associated with integration? Do you actually need to integrate at a "code" level, or can you do it at some higher level (input/output files, etc)?

You need to understand these aspects first. You've said there are many subroutines, so this is probably not a trivial exercise. "Not knowing fortran" will ... complicate ... this.

Consider the example you used at the start of this thread. It contains variables in common CNTOUR, A and B, that need to be initialised somehow. How (conceptually) does that initialisation happen? Without that initialisation, this subroutine can't do anything useful.

Beyond the above issues, there is actually no robust answer to your specific question for that specific subroutine. There are answers that will work in some situations, one below, but then there are important requirements on the matlab side of things and you are at the mercy of numerous compiler options and calling/naming conventions. Plenty of room for error, not exactly beginner territory. Hence the recommendation around learning and using the C interoperability features made by tim18 above is a good one - it goes a long way towards overcoming some of the pitfalls here. The suggestion would be to either rewrite the routine or provide a wrapper for it that uses this feature. Then the relevant C-header file becomes trivial.

As a minimum change example to the provided "fortran" code, this should work as well as the original routine was ever going to, on IA-32 under Windows with recent versions of ifort and matlab, when compiled with "ifort /dll MatlabDLL.for", on Tuesdays:

MatlabDLL.for

lambda.h

call_LAMBDA.m

See here for a more robust approach.

thank you for the valuable guidence and for the samples