[petsc-users] How to use f2py on a PETSc/SLEPc-based fortran code

Tue Mar 28 16:53:16 CDT 2017

Looks like it isn't finding your source from run_analysis.f90. You still
need to compile that yourself and include in the final link. In my example,
all the "original" source code was precompiled into a library from a
different makefile and then this was run after-the-fact.

Gaetan

On Tue, Mar 28, 2017 at 2:38 PM, Austin Herrema <aherrema at iastate.edu>
wrote:

> Gotcha. In that case, it seems I should be good without that line. I've
> gotten the compile to succeed, but upon attempting to import the module I
> get the following:
>
> >>> import run_analysis_final
> Traceback (most recent call last):
>   File "<stdin>", line 1, in <module>
> ImportError: dlopen(./run_analysis_final.so, 2): Symbol not found:
> _run_analysis_
>   Referenced from: ./run_analysis_final.so
>   Expected in: flat namespace
>  in ./run_analysis_final.so
>
> Seems I may have gotten the linking wrong somehow. Will keep searching,
> but the simplified makefile that I used is attached in case anyone thinks
> they might be able to spot the issue in it. That said, I do realize that
> this may be starting to reach beyond the scope of this mailing list so feel
> free to ignore...
>
> On Tue, Mar 28, 2017 at 2:31 PM, Gaetan Kenway <gaetank at gmail.com> wrote:
>
>> You only get that file if you have wrapped a module explicitly in the
>> .pyf file. If you haven't wrapped a module, that doesn't get created.
>>
>> Gaetan
>>
>> On Tue, Mar 28, 2017 at 12:28 PM, Austin Herrema <aherrema at iastate.edu>
>> wrote:
>>
>>> Gaetan,
>>>
>>> Thank you for this. With your help, I think I am getting close to
>>> getting this to work for my case. At the moment, I am hung up on the line
>>> of your makefile which reads "$(FF90) $(FF90_ALL_FLAGS) -I$(MAIN_DIR)/mod
>>> -c warpustruct-f2pywrappers2.f90". Am I correct that
>>> warpustruct-f2pywrappers2.f90 should be generated by f2py? If so, do you
>>> (or does anyone else) know the command for telling f2py to do so? At the
>>> moment I am using:
>>>
>>> f2py run_analysis.f90 -m run_analysis -h run_analysis.pyf
>>>
>>> to get the requisite .pyf and .c files, but no .f90 file. If I am wrong
>>> about the origin of this file, please do tell me!
>>>
>>> Thank you,
>>> Austin
>>>
>>> On Mon, Mar 27, 2017 at 5:13 PM, Gaetan Kenway <gaetank at gmail.com>
>>> wrote:
>>>
>>>> Austin
>>>>
>>>> Here is the full makefile for a code we use. The variables defined
>>>> externally in a separate config file are:
>>>> $(FF90)
>>>> $(FF90_FLAGS)
>>>> $(LIBDIR)
>>>> $(PETSC_LINKER_FLAGS)
>>>> $(LINKER_FLAGS)
>>>> $(CGNS_LINKER_FLAGS)
>>>>
>>>> $(PYTHON)
>>>> $(PYTHON-CONIFG)
>>>> $(F2PY)
>>>> (These are usually use python, python-config and f2py. You can
>>>> overwrite as necessary)
>>>>
>>>> $(CC)
>>>> $(CC_ALL_FLAGS)
>>>>
>>>> This essentially just mimics what f2py does automatically but we found
>>>> it easier to control exactly what is going on. Essentially you are just
>>>> compiling exactly as you normally an executable, but instead make a .so
>>>> (with the -shared option) and including the additional .o files generated
>>>> by compiling the f2py-generated wrappers.
>>>>
>>>> Hope this helps,
>>>> Gaetan
>>>>
>>>> On Sat, Mar 25, 2017 at 5:38 AM, Lisandro Dalcin <dalcinl at gmail.com>
>>>> wrote:
>>>>
>>>>>
>>>>>
>>>>> On 22 March 2017 at 20:29, Barry Smith <bsmith at mcs.anl.gov> wrote:
>>>>>
>>>>>>
>>>>>>   Lisandro,
>>>>>>
>>>>>>     We've had a couple questions similar to this with f2py; is there
>>>>>> a way we could add to the PETSc/SLEPc makefile rules something to allow
>>>>>> people to trivially use f2py without having to make their own (often
>>>>>> incorrect) manual command lines?
>>>>>>
>>>>>>    Thanks
>>>>>>
>>>>>>
>>>>> Barry, it is quite hard and hacky to get f2py working in the general
>>>>> case. I think the email from Gaetan in this thread proves my point.
>>>>>
>>>>> IMHO, it is easier to write a small Fortran source exposing the API to
>>>>> call using ISO_C_BINDINGS, then wrap that code with the more traditional
>>>>> C-based "static" tools (SWIG, Cython) or even "dynamically" with ctypes or
>>>>> cffi (which use dlopen'ing).
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> Lisandro Dalcin
>>>>> ============
>>>>> Research Scientist
>>>>> Computer, Electrical and Mathematical Sciences & Engineering (CEMSE)
>>>>> Extreme Computing Research Center (ECRC)
>>>>> King Abdullah University of Science and Technology (KAUST)
>>>>> http://ecrc.kaust.edu.sa/
>>>>>
>>>>> 4700 King Abdullah University of Science and Technology
>>>>> al-Khawarizmi Bldg (Bldg 1), Office # 0109
>>>>> Thuwal 23955-6900, Kingdom of Saudi Arabia
>>>>> http://www.kaust.edu.sa
>>>>>
>>>>> Office Phone: +966 12 808-0459 <+966%2012%20808%200459>
>>>>>
>>>>
>>>>
>>>
>>>
>>> --
>>> *Austin Herrema*
>>> PhD Student | Graduate Research Assistant | Iowa State University
>>> Wind Energy Science, Engineering, and Policy | Mechanical Engineering
>>>
>>
>>
>
>
> --
> *Austin Herrema*
> PhD Student | Graduate Research Assistant | Iowa State University
> Wind Energy Science, Engineering, and Policy | Mechanical Engineering
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mcs.anl.gov/pipermail/petsc-users/attachments/20170328/ba0e8860/attachment-0001.html>