> El 22 mar 2017, a las 19:23, Barry Smith <bsm...@mcs.anl.gov> escribió:
>
>
>> On Mar 22, 2017, at 1:08 PM, Austin Herrema <aherr...@iastate.edu> wrote:
>>
>> Thank you for the suggestion! Seems like a reasonable way to go. Not working
>> for me, however, I suspect because I'm using homebrew installations of PETSc
>> and SLEPc (I don't think all the makefiles are kept). Any other way to do
>> the same thing by chance? Worst case I could use a non-homebrew installation
>> but I'd prefer not to mess with that if I can help it...
>
> How do you link a "regular" SLEPc C program using the home-brew libraries?
> You need basically the same link line for f2py as you need for C programs.
What Barry may be suggesting is: instead of using a script to invoke f2py, add
a rule to your makefile
modname.so: outer_driver.f90
f2py -c -m modname outer_driver.f90 file1.o file2.o file3.o
${SLEPC_EPS_LIB}
Then 'make modname.so' will pick the libraries from SLEPc makefiles.
Jose
>
>>
>> Thanks,
>> Austin
>>
>> On Wed, Mar 22, 2017 at 11:20 AM Jose E. Roman <jro...@dsic.upv.es> wrote:
>> Try the following:
>> $ cd $SLEPC_DIR
>> $ make getlinklibs_slepc
>> Then copy the output and paste it at the end of your f2py command.
>>
>> Jose
>>
>>
>>> El 22 mar 2017, a las 16:38, Austin Herrema <aherr...@iastate.edu> escribió:
>>>
>>> Hello all,
>>>
>>> I am trying to do as the subject line describes--use f2py to run a large
>>> PETSc/SLEPc fortran finite element code through python. I really only need
>>> to wrap the outermost function of the fortran code--don't need any access
>>> to subroutines. I'll describe what I'm doing, some of which I'm not 100%
>>> confident is correct (not much experience with f2py)--feel free to
>>> correct/redirect any of it.
>>>
>>> First, I'm editing the fortran code so that the top-level function is a
>>> subroutine rather than a main program (it's my understanding that this is
>>> required for f2py?).
>>>
>>> I use my regular makefile (modeled after a standard SLEPc makefile from the
>>> user guide) to compile all of the .f90/.F90 files (many of them) to .o
>>> files using SLEPc/PETSc rules. The final linking phase fails since there
>>> isn't a main program, but I'm just ignoring that for now since that's not
>>> what I ultimately need...
>>>
>>> Using a python script, I set up and run the f2py command. Right now it has
>>> the form...
>>> "f2py -c -m modname outer_driver.f90 file1.o file2.o file3.o..." etc.
>>>
>>> This appears to work, but upon attempting to import, it cannot find the
>>> SLEPc (and, I presume, PETSc) objects/functions:
>>>
>>>>>> import mod_name
>>> Traceback (most recent call last):
>>> File "<stdin>", line 1, in <module>
>>> ImportError: dlopen(./mod_name.so, 2): Symbol not found: _epscreate_
>>> Referenced from: ./mod_name.so
>>> Expected in: flat namespace
>>> in ./mod_name.so
>>>
>>> Based on this discussion, I believe I need to somehow include PETSc/SLEPc
>>> info when linking with f2py. Is that correct? Any direction on how to do
>>> that? I don't quite understand what the OP of that question ultimately
>>> ended up doing to get it to work. I tried using the -I flag pointing to the
>>> slepc_common file (like the SLEPc makefile does). The problem is that that
>>> is a file, not a directory, which contains a number of other makefile-style
>>> variables--so it works to include it in a makefile, but doesn't work in
>>> python. Maybe there are only a few directories I really need to include? Or
>>> is it possible to somehow run f2py through a makefile? I'm a bit ignorant
>>> in that realm as well.
>>>
>>> Thank you for any help or suggestions!
>>> Austin
>>>
>>>
>>> --
>>> 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
>
