Inline::F2003 - New ILSM proposed

[Ron Grunwald via inline]

Hello all,

I've been thinking about this for quite some time now, and have finally decided to pursue the idea of a modern FORTRAN Inline module. Given that soon I'll be having some time available through to the end of this year, I'm confident that I can make this work.

The name of the proposed module is Inline::F2003

The module will only work for compilers that are compliant with the FORTRAN 2003 standard and above. The reason for this is that FORTRAN 2003 introduced a new feature named "C Interoperability". This feature, coupled with Inline::C, are the core mechanisms that will make Inline::F2003 work.

For those who have an interest in programming using modern FORTRAN, below is an example Perl program that illustrates how Inline::F2003 would be used. The program performs multiplication of two matrices. Notice the two sections __F2003__ and __C__

The __F2003__ section contains the FORTRAN subroutine that performs the actual matrix multiplication. The subroutine utilises FORTRAN 2003's C interoperability features to make it callable from C.

The __C__ section is the crucial part of an Inline::F2003 program, and must always be present. It prepares any data from Perl that needs to be passed into FORTRAN, and finally calls the FORTRAN subroutine with that data. 

I am always interested to hear people's views. So, if you have any comments/suggestions/questions, please post them or send me an e-mail.

Many thanks for reading this post and reviewing the example program below.

Cheers,

Ron.

 

#!/usr/local/ActivePerl/bin/perl

#

use strict;

use warnings;

use Inline F2003 => Config => (

                       SOURCE    => "ModMatrixOps.f03",

                       LIBRARY   => "libMatrixOps.so",

                       LIBTYPE   => ".so",

                       DIRECTORY => "BLD_Linux.AMD64_nagfor",

                       FOR       => "nagfor",

                       FORFLG    => "-v -g90 -gline -otype=obj -f2003 -fpp"

                    );

use Inline C => Config => (

                   MYEXTLIB  => "/u/BLD_Linux.AMD64_nagfor/libMatrixOps.so",

                   DIRECTORY => "BLD_Linux.AMD64_perl",

                   CCFLAGSEX => "-std=c99"

                );

use Inline F2003 => "DATA";

use Inline C     => "DATA";

MainFunction: {

   my ($M1_rows, $M1_cols) = (3, 3);

   my ($M2_rows, $M2_cols) = (3, 3);

   my @M1_data = ( 2.4,  0.0,  0.0,

                   2.4,  3.8,  0.0,

                   0.0,  3.8,  0.0  );

   my @M2_data = ( 2.4,  2.4,  0.0,

                   0.0,  3.8,  3.8,

                   1.25, 1.25, 1.25 );

   MatrixMultiply( $M1_rows, $M1_cols, @M1_data,

                   $M2_rows, $M2_cols, @M2_data );

}

__DATA__

__F2003__

SUBROUTINE FOR_MatrixMultiply (M1_rows, M1_cols, C_M1_data,  &

                               M2_rows, M2_cols, C_M2_data ) &

           BIND(C, NAME="FOR_MatrixMultiply")

   USE, INTRINSIC :: ISO_C_BINDING, &

                     ONLY : C_INT, C_DOUBLE, C_PTR, C_F_POINTER

   USE ModMatrixOps

   IMPLICIT NONE

   INTEGER (KIND=C_INT), VALUE, INTENT(IN) :: M1_rows, M1_cols

   INTEGER (KIND=C_INT), VALUE, INTENT(IN) :: M2_rows, M2_cols

   REAL (KIND=C_DOUBLE), POINTER :: M1_data(:) => NULL()

   REAL (KIND=C_DOUBLE), POINTER :: M2_data(:) => NULL()

   TYPE (C_PTR), INTENT(IN) :: C_M1_data, C_M2_data

   CALL C_F_POINTER (C_M1_data, M1_data, [M1_rows * M1_cols])

   CALL C_F_POINTER (C_M2_data, M2_data, [M2_rows * M2_cols])

   CALL MOD_SetMatrix (M1_rows, M1_cols, M1_data)

   CALL MOD_SetMatrix (M2_rows, M2_cols, M2_data)

   CALL MOD_MatrixMultiply()

   IF (MOD_MatrixOp_OK()) THEN

      CALL MOD_MatrixDisplay()

   ELSE

      PRINT "(A)", "FOR_MatrixMultiply: Error Condition Occurred."

   END IF

   CALL MOD_MatrixDestroy()

END SUBROUTINE FOR_MatrixMultiply

__C__

#define MAX_MATRIX_SZ 50

extern void FOR_MatrixMultiply(int, int, double *, int, int, double *);

void MatrixMultiply(SV* matrix_data, ...) {

   double M1_data[MAX_MATRIX_SZ], M2_data[MAX_MATRIX_SZ];

   int    M1_rows, M1_cols, M2_rows, M2_cols;

   int    ix, arg_ix = 0;

   Inline_Stack_Vars;

   M1_rows = SvIV(Inline_Stack_Item(arg_ix++));

   M1_cols = SvIV(Inline_Stack_Item(arg_ix++));

   /*

    * Fill values for Matrix 1

    */

   for (ix=0; ix < M1_rows*M1_cols; ix++) {

      M1_data[ix] = SvNV(Inline_Stack_Item(arg_ix++));

   }

   M2_rows = SvIV(Inline_Stack_Item(arg_ix++));

   M2_cols = SvIV(Inline_Stack_Item(arg_ix++));

   /*

    * Fill values for Matrix 2

    */

   for (ix=0; ix < M2_rows*M2_cols; ix++) {

      M2_data[ix] = SvNV(Inline_Stack_Item(arg_ix++));

   }

   FOR_MatrixMultiply(M1_rows, M1_cols, M1_data,

                      M2_rows, M2_cols, M2_data );

   Inline_Stack_Void;

}

________________________________________

Ron Grunwald

ron...@yahoo.com.au

http://www.dvlcorner.org

[Elizabeth Mattijsen]

> On 22 May 2017, at 15:55, Ron Grunwald via inline <inl...@perl.org> wrote:
> I've been thinking about this for quite some time now, and have finally decided to pursue the idea of a modern FORTRAN Inline module. Given that soon I'll be having some time available through to the end of this year, I'm confident that I can make this work.
>
> The name of the proposed module is Inline::F2003

Cool idea!

Have you considered an Inline::Fortran in Perl 6 using NativeCall?


Elizabeth Mattijsen

[sisy...@optusnet.com.au]

From: Ron Grunwald via inline
Sent: Monday, May 22, 2017 11:55 PM
To: inl...@perl.org
Subject: Inline::F2003 - New ILSM proposed

> The name of the proposed module is Inline::F2003

Please let us know when it becomes available from CPAN.

> The module will only work for compilers that are compliant with the
> FORTRAN 2003 standard and above.

With gfortran (from gcc-7.1.0) I tried:

C:\_32>gfortran -f2003 -c demo.f -o demo.o
gfortran: error: unrecognized command line option '-f2003'

I gather this indicates that gcc's gfortran is not compliant with the
FORTRAN 2003 standard ?

Cheers,
Rob

[Ron Grunwald via inline]

Hi Rob,

> On 23 May 2017, at 10:05 am, <sisy...@optusnet.com.au> <sisy...@optusnet.com.au> wrote:
>
>
> From: Ron Grunwald via inline
> Sent: Monday, May 22, 2017 11:55 PM
> To: inl...@perl.org
> Subject: Inline::F2003 - New ILSM proposed
>
>> The name of the proposed module is Inline::F2003
>
> Please let us know when it becomes available from CPAN.

I am likely to provide regular updates here as the work progresses. I expect the first release to be quite primitive but functional.

>
>> The module will only work for compilers that are compliant with the FORTRAN 2003 standard and above.
>
> With gfortran (from gcc-7.1.0) I tried:
>
> C:\_32>gfortran -f2003 -c demo.f -o demo.o
> gfortran: error: unrecognized command line option '-f2003'
>
> I gather this indicates that gcc's gfortran is not compliant with the FORTRAN 2003 standard ?

gfortran is definitely compliant with the FORTRAN 2003 standard. The option to use is "-std=f2003".

The option "-f2003" is relevant only to the commercial NAG FORTRAN compiler.

You could even use the "g95" compiler. Even though g95 is not fully 2003 compliant, it does offer full support for C Interoperability. If you intend to try g95, use the option "-std=f2003".

>
> Cheers,
> Rob

[Ron Grunwald via inline]

Hello all,

The example code below illustrates how Inline::F2003 could be configured to build a shared library from the Fortran source files listed in "SRCLIST". Also, I propose to add a new parameter called "MAKEFILE", and this leads me into an area that I'm unsure about.

use Inline F2003 => Config => (

                       SRCLIST   => "ModMatrixOps.f03",

                       LIBNAME   => "libMatrixOps.so",

                       LIBTYPE   => ".so",

                       MAKEFILE  => "AUTOMAKE",

                       BUILDDIR  => "BLD_Linux.AMD64_gfortran",

                       FOR       => "gfortran",

                       FORFLG    => "-v -g -c -std=f2003 -fpic -cpp"

                    );

This new parameter "MAKEFILE" is intended to allow programmers to specify their own makefile. However, the special value "AUTOMAKE" can also be specified (as shown above), which means that Inline::F2003 would generate a suitable makefile, and this is where I need some advice.

Inline::C uses ExtUtils::MakeMaker to generate the makefile. I would like to use ExtUtils::MakeMaker, but I don't think it would be possible since it generates makefiles for C compilation, not Fortran compilation. Unless there is some clever way to configure ExtUtils::MakeMaker to output Fortran makefiles?

Another option is to use the GNU autotools. In this scenario, Inline::F2003 would read an existing "Makefile.in", then use the parameters specified in the above example, and write out the final Makefile. Sounds simple, but I've never done this before.

If anyone is able to provide advice, suggestions or opinions, I would be really grateful. Many thanks for reading.

Cheers,

Ron.

________________________________________

Ron Grunwald

ron...@yahoo.com.au

http://www.dvlcorner.org

[sisy...@optusnet.com.au]

From: Ron Grunwald via inline

Sent: Saturday, June 10, 2017 8:53 PM
To: inl...@perl.org
Subject: Re: Inline::F2003 - New ILSM proposed

Hello all,

> The example code below illustrates how Inline::F2003 could be configured
> to build a shared library from the Fortran source files listed in
> "SRCLIST". Also, I propose to add a new parameter called "MAKEFILE", and
> this leads me into an area that I'm unsure about.
>
> use Inline F2003 => Config => (
> SRCLIST => "ModMatrixOps.f03",
> LIBNAME => "libMatrixOps.so",
> LIBTYPE => ".so",
> MAKEFILE => "AUTOMAKE",
> BUILDDIR => "BLD_Linux.AMD64_gfortran",
> FOR => "gfortran",
> FORFLG => "-v -g -c -std=f2003 -fpic -cpp"
> );
>
> This new parameter "MAKEFILE" is intended to allow programmers to specify
> their own makefile. However, the special value "AUTOMAKE" can also be
> specified (as shown above), which means that Inline::F2003 would generate
> a suitable makefile, and this is where I need some advice.
>
> Inline::C uses ExtUtils::MakeMaker to generate the makefile. I would like
> to use ExtUtils::MakeMaker, but I don't think it would be possible since
> it generates makefiles for C compilation, not Fortran compilation.

Both PDL and PGPLOT modules use ExtUtils::MakeMaker && perform fortran
compilations.
They make use of the ExtUtils::F77 module.
FAIK it might simply be that EU::F77's job is simply to determine the name
of the fortran compiler, and the flags that it should take ... or perhaps
there's more to it than just that.

The fortran compilations in the PDL build occur during the building of
PDL::Slatec and PDL::Minuit - there might be other places, too.
With EU::F77 installed you should be able to build PDL (such that both
PDL::Slatec and PDL::Minuit are built) with 'cpan -i PDL'.

Hopefully there's something in there that will help.

Any questions about how the fortran stuff is managed by PDL or EU::MM could
also be sent to the PDL devel mailing list. It's an active list that's
fairly well attended by informed and helpful folk.

> Unless there is some clever way to configure ExtUtils::MakeMaker to output
> Fortran makefiles?
>
> Another option is to use the GNU autotools.

PDL::Audio (http://search.cpan.org/~mlehmann/PDL-Audio-1.2/) is the only
module I've ever built that makes use of autotools (in the sndlib folder in
the source distro).
It works well, though I haven't studied it.
Maybe there's something useful to be gleaned from it, too.

> In this scenario, Inline::F2003 would read an existing "Makefile.in", then
> use the parameters specified in the above example, and write out the final
> Makefile. Sounds simple, but I've never done this before.
>
> If anyone is able to provide advice, suggestions or opinions, I would be
> really grateful.

My only other advice would be to also sound this out on perlmonks. (But that
might pay off ... or it might not :-)

Cheers,
Rob

[Ron Grunwald via inline]

Hi Rob,

Many thanks for your expert advice. You've given me quite a few avenues to explore.

Cheers,
Ron.

[Ron Grunwald via inline]

Hi all,

I'm not sure how many people are still subscribed to this list, but today I would like to announce the first release of Inline::F2003.

The URL is https://sourceforge.net/projects/inline-f2003/

There are several reasons why I decided to release the module on Sourceforge rather than CPAN. First, I feel that this initial release is not yet sufficiently mature to be a standalone CPAN module. The other reason is that I'm not sure if the Inline community would allow me to use the "Inline::" namespace in the module name.

I am highly motivated to produce a high quality module that allows Perl to interoperate with modern FORTRAN. This initial release was developed and tested on Linux only. However, I would still encourage users to try running the program even if their system is non-Linux.

I am very interested to hear your views and experiences with Inline::F2003. It would be great to see discussion reinvigorated on this list. Thank you for reading this post. I do hope you'll have an opportunity to tryout the program, and report back your findings.

Cheers,

Ron.

________________________________________

Ron Grunwald

ron...@yahoo.com.au

http://www.dvlcorner.org

On 22 May 2017, at 9:55 pm, Ron Grunwald via inline <inl...@perl.org> wrote:

[sisy...@optusnet.com.au]

From: Ron Grunwald via inline

Sent: Friday, November 03, 2017 10:52 AM

To: inl...@perl.org
Subject: Re: Inline::F2003 - New ILSM proposed

Hi all,

> I'm not sure how many people are still subscribed to this list, but today
> I would like to announce the first release of Inline::F2003.

It will reach a whole lot more perl folk if you also announce it at
http://www.perlmonks.org/?node=Perl%20News .
(Scroll down to the bottom of that page to get to the relevant text boxes.)
You can post to perlmonks without signing up.

>The URL is https://sourceforge.net/projects/inline-f2003/
>There are several reasons why I decided to release the module on
>Sourceforge rather than CPAN. First, I feel that this initial release is
>not yet sufficiently mature to be a standalone CPAN module. The other
>reason is that I'm not sure if the Inline community would allow me to use
>the "Inline::" namespace in the module name.

There's no reason that you should not use the "Inline" namespace ... and
there are very good reasons that you should *not* use anything other than
the "Inline" namespace.

> I am highly motivated to produce a high quality module that allows Perl to
> interoperate with modern FORTRAN. This initial release was developed and
> tested on Linux only. However, I would still encourage users to try
> running the program even if their system is non-Linux.
> I am very interested to hear your views and experiences with
> Inline::F2003. It would be great to see discussion reinvigorated on this
> list. Thank you for reading this post. I do hope you'll have an
> opportunity to tryout the program, and report back your findings.

As a brief preliminary play on MS Windows I ran "perl matopmul.pl" and,
although gfortran is in my PATH, I got:

C:\s>perl matopmul.pl
ERROR: Key name FOR has invalid value ... gfortran
ERROR: Compiler not found in path!
at matopmul.pl line 0.
INIT failed--call queue aborted.

I'm thinking that one should turn out to be simple to fix. (I don't have
time right now to look at it.)

One thing I did notice is that the README.txt lists me as Inline
co-maintainer. Although that might technically be true (not even sure about
that), I haven't been involved in any maintenance of Inline or Inline::C for
a year or two now and, although I still use and take an interest in those
modules, I don't intend doing anything beyond perhaps making bug reports or
submitting patches.
I'm not sure of the state of play at the moment regarding who is doing what
with Inline - though I notice that, according to CPAN, Tina Muller was
responsible for the latest release of Inline::C (version 0.78).
So ... I don't really know whose name(s) should be listed as
"co-maintainers", but I think my name should not.

Anyway - it's good to finally see an Inline fortran module !!

Cheers,
Rob

[Ron Grunwald via inline]

Hi Rob,

Thank you for your suggestions and thank you for trying to run the program on your system.

For MS Windows and Apple OS X I have done zero testing, so I'm not surprised that it failed. For the next release I will focus on those two OS's and introduce support for a fourth compiler - Intel Fortran.

In relation to listing your name in the README.txt, you have done so much work on Inline and Inline::C in past years, that I thought its only fair to acknowledge your name. However, I will remove it if you really want me to.

Finally, my understanding is that Ingy still has the final say on any proposed changes to Inline and Inline::C.

Cheers,
Ron.

[Ron Grunwald via inline]

Hi Rob,

> As a brief preliminary play on MS Windows I ran "perl matopmul.pl" and, although gfortran is in my PATH, I got:
>
> C:\s>perl matopmul.pl
> ERROR: Key name FOR has invalid value ... gfortran
> ERROR: Compiler not found in path!
> at matopmul.pl line 0.
> INIT failed--call queue aborted.

On MS Windows the executable filename for gfortran is probably "gfortran.exe". If you edit "matopmul.pl" by changing the line 'FOR => "gfortran"' to 'FOR => "gfortran.exe"', it should then find the compiler.

I suspect the program may still fail, but at least it got further. If it does fail, I'll create a Sourceforge ticket for the problem.

>
> Anyway - it's good to finally see an Inline fortran module !!

Thank you!