Expose *_caf_init(), *caf_finalize()

[amckinstry]

Hi,

I've been experimenting with running CAF under Python using f2py. Its a bit hacky at the moment (proof of concept time) but I can now compile and run CAF programs under Python3 using f2py3.5, OpenCoarrays 1.6.0 and OpenMPI 1.10.3 on Debian.

So I have a Fortran module:

module caftest
contains
  subroutine bar
    implicit none
    integer:: np, me

    np = num_images()
    me = this_image()
    write (*,*) "I am image ", me, " of ", np
  end subroutine bar
end module

caftest.py:

#!/usr/bin/env python3
# hacky setup code here
caftest.bar()

mpiexec -n 2 ./caftest.py
I am image 1 of 2
I am image 2 of 2

To do this, I've needed to call _gfortran_caf_init() and _gfortran_caf_finalize() from the Python / f2py layer, in order to setup mpi_init, etc. But there is no coarray.h, API exposed, so this was a little .. unorthodox. Can they be exposed?

Regards
Alastair McKinstry

[zbeekman]

I'm wondering if it would make sense to expose this in the alternate user interface module (opencoarrays.F90)

[amckinstry]

@zbeekman I think so, yes.
I've been working in C, but I think I may be able to work directly in Fortran. It'll be two or three weeks before I can work on this properly, though

[rouson]

Cool stuff! Without checking, I'm pretty sure these are already public functions so they are exposed, but if I'm missing something, let me know.

As an aside, @rasmussn, who is working with us on the source transformation capability, published an article on coarray Python. I wonder if that would be of interest. If so, I'd be very interested in reviving the concept.

[amckinstry]

Thanks, thats interesting. 2004 is a bit prescient. I'll think about it. At the moment I'm working on examining performance aspects of CAF + MPI3 features. Python wrappers for Fortran code are becoming increasingly frequent, and if CAF becomes more popular, f2py support for CAF is needed.

[afanfa]

Hello,
is there any progress on this issue?

[amckinstry]

@afanfa not at the moment, busy with other things.
The public interface (opencoarrays.mod) currently doesn't ship any _init or _finalize methods, so should we ship libcaf.h (and its dependency ./src/libcaf-gfortran-descriptor.h) ?

[zbeekman]

@amckinstry it should be relatively quick to add public interfaces in opencoarrays.mod... to me that seems like the best solution. However, I think most of us have a lot on our plates at the moment, so the timeline on this is unknown, for now.

[rouson]

@McKinstry, the requested functions are exposed in src/cafe/opencoarrays.F90 on the caffeinate-opencoarrays branch as part of a plan to facilitate source-to-source translation of Fortran 2008/2015 CAF programs into Fortran 2003 to facilitate compiling CAF programs with non-CAF compilers. If this topic is still of interest to you, then I'll be glad to merge the relevant changes into the master branch so that they can appear in an upcoming release.

[vikramsg]

I have been experimenting with coarrays and I am thinking of wrapping the code using Python. I would be really interested in knowing how f2py can be used with coarrays.

[amckinstry]

My current work is a hack that I need to finish cleaning up for submission to numpy. Basically it calls caf_init() and caf_fini(), needed to set things up.
So, the module code above for caftest, then run your python script under mpitest:

#!/usr/bin/env python3

from mpi4py import MPI
# import cafout
comm = MPI.COMM_WORLD

print("rank, size = (%d, %d)" % (comm.rank, comm.size))
# cafout.cafinit(1, "")
from caftest import caftest
caftest.bar()
# cafout.cafend()

The cafout bits are being embedded in the f2py code.

rank, size = (0, 2)
rank, size = (1, 2)
 I am image            1  of            2
 I am image            2  of            2

This is the minimum just to allow CAF programs to be run under Python. The interesting bits are when the arrays are properly handled at the Python level: returning an array view for the coarray so we don't have to sync all the data onto one thread for Python, etc.

[zbeekman]

The public interface (opencoarrays.mod) currently doesn't ship any _init or _finalize methods, so should we ship libcaf.h (and its dependency ./src/libcaf-gfortran-descriptor.h) ?

@amckinstry just to clarify, by "ship" you mean install these into "/include" or something like that? One concern that I have about this is that this will create a tighter coupling with the CAF implementation, and violates some principles of data hiding and encapsulation. My preference is to put it into opencoarrays.mod but this is a little bit less striaight forward than I initially thought due to the lack of standardization of preprocessing in Fortran. (One must calculate the function name prefixes....)