0

This is a follow up to a question I asked here... How do I allocate input arrays with f2py?

I've reworked the question in response to comments. The original question was unclear and too lengthy. See comment 1 below.

I am trying to use f2py to wrap various fortran subroutines/functions for reading the data output from a variety of atomic physics codes written in fortran 77. I am using the Anaconda python distribution (python 3.4 64 bit) on Ubuntu 14.04 (64 bit) with the gnu compiler suite (gcc, gfortran, etc.)

I am having issues trying to preallocate the arrays in python. My original question dealt with allocating a character array. Turns out I had the wrong shape. I've fixed that (I think), and am now dealing with a segmentation fault. I've compiled the fortran subroutine with f2py using the --debug-capi flag to enable verbose error reporting.

Here is the relevant portion of the terminal output I get when I run my python script.

debug-capi:Python C/API function adf04_2py.xxdata_04(iunit,titled,iz,iz0,iz1,bwno,npl,bwnoa,lbseta,prtwta,cprta,il,qdorb,lqdorb,qdn,iorb,ia,cstrga,isa,ila,xja,wa,cpla,npla,ipla,zpla,nv,scef,itran,maxlev,tcode,i1a,i2a,aval,scom,beth,iadftyp,lprn,lcpl,lorb,lbeth,letyp,lptyp,lrtyp,lhtyp,lityp,lstyp,lltyp,itieactn,ltied,ndlev=len(ia),ndtrn=shape(tcode,0),ndmet=len(bwnoa),ndqdn=len(qdn),nvmax=len(scef))
debug-capi:int lltyp=:input,required,scalar
debug-capi:lltyp=0

        ####### omitted ##########

debug-capi:int ndmet=len(bwnoa):input,optional,scalar
debug-capi:ndmet=1
debug-capi:Checking `len(bwnoa)>=ndmet'
debug-capi:int ndqdn=len(qdn):input,optional,scalar
debug-capi:ndqdn=1
debug-capi:Checking `len(qdn)>=ndqdn'
debug-capi:int ndlev=len(ia):input,optional,scalar
debug-capi:ndlev=1
debug-capi:Checking `len(ia)>=ndlev'
debug-capi:int lqdorb=:input,required,array,dims((ndqdn*(ndqdn+1))/2|(ndqdn*(ndqdn+1))/2)
debug-capi:string cprta=:input,required,array,string array,dims(ndmet|ndmet,9|9)
debug-capi:double prtwta=:input,required,array,dims(ndmet|ndmet)
debug-capi:double beth=:input,required,array,dims(ndtrn|ndtrn)
debug-capi:string cstrga=:input,required,array,string array,dims(ndlev|ndlev,(*)|(*))
debug-capi:double zpla=:input,required,array,dims(ndmet|ndmet,ndlev|ndlev)
debug-capi:int ltied=:input,required,array,dims(ndlev|ndlev)
debug-capi:int npla=:input,required,array,dims(ndlev|ndlev)
debug-capi:int i2a=:input,required,array,dims(ndtrn|ndtrn)
debug-capi:int lbseta=:input,required,array,dims(ndmet|ndmet)
debug-capi:int i1a=:input,required,array,dims(ndtrn|ndtrn)
debug-capi:int ila=:input,required,array,dims(ndlev|ndlev)
debug-capi:double scom=:input,required,array,dims(nvmax|nvmax,ndtrn|ndtrn)
debug-capi:double qdorb=:input,required,array,dims((ndqdn*(ndqdn+1))/2|(ndqdn*(ndqdn+1))/2)
debug-capi:string cpla=:input,required,array,string array,dims(ndlev|ndlev,1|1)
debug-capi:int isa=:input,required,array,dims(ndlev|ndlev)
debug-capi:double wa=:input,required,array,dims(ndlev|ndlev)
debug-capi:int ipla=:input,required,array,dims(ndmet|ndmet,ndlev|ndlev)
debug-capi:double xja=:input,required,array,dims(ndlev|ndlev)
debug-capi:Fortran subroutine `xxdata_04(&iunit,&ndlev,&ndtrn,&ndmet,&ndqdn,&nvmax,titled,&iz,&iz0,&iz1,&bwno,&npl,bwnoa,lbseta,prtwta,cprta,&il,qdorb,lqdorb,qdn,&iorb,ia,cstrga,isa,ila,xja,wa,cpla,npla,ipla,zpla,&nv,scef,&itran,&maxlev,tcode,i1a,i2a,aval,scom,beth,&iadftyp,&lprn,&lcpl,&lorb,&lbeth,&letyp,&lptyp,&lrtyp,&lhtyp,&lityp,&lstyp,&lltyp,&itieactn,ltied,slen(titled),flen(cstrga))'
Segmentation fault (core dumped)

My first question is this. Is it possible to tell from the debug output exactly what segfaulted? I don't see how.

As a second question, if you look at the beginning of the debug output, you will see something that looks like a function call, which I believe is python calling the function from the shared object. At the end of the debug output you see something almost identical, but is labelled as a 'fortran sub-routine'. The variables in the fortran subroutine are not in the same order as the python function. The shared object was automatically created by f2py from the original fortran code. Any one know why these variables are in a different order?

Thanks in advance

Community
  • 1
  • 1
ivanarnold
  • 115
  • 5
  • Please provide a minimal code with reproducible behavior! We are not here to read all your long code. An example with a single subroutine is the best. – innoSPG Feb 10 '16 at 18:06
  • Not sure why that deserved a down vote? If you had read my original post (which is linked in this one) you would know that there is no such thing as a minimal code in this case. The original fortran code(s) are lengthy, and my python script is available in the original posted question. In any case this is primarily a question about how to interpret the debugging output from f2py, which I've provided. I was simply trying to avoid the inevitable "please post the entire output" comments I see so frequently here. Sorry for wasting your time, but you were always free to simply stop reading. – ivanarnold Feb 10 '16 at 19:10
  • I did not downvote. It is not my nature to downvote! Even if I found your comment more judging while only guessing that I, the commenter is also the downvoter, I am still not going to downvote. That is because your question, despite being difficult to follow seems very reasonable. I usually comment to let OP give more details or improve their questions. That was the case here. And just to assure you, I am not an f2py expert, so even with the clearer question I will certainly not have the knowledge to answer. – innoSPG Feb 10 '16 at 19:42
  • Fair enough. Not trying to pass judgement. And in hindsight my question was way to long and not very clear. I've edited it accordingly. However, in this case posting a minimal version of the code isn't really possible. Thanks for your reply. – ivanarnold Feb 10 '16 at 20:25

1 Answers1

2

No sure if I'm supposed to be answering my own questions like this. If this is against protocol then I beg forgiveness from the stack exchange powers that be.

All the information IS (so far) contained in the debug output. After allocating the 'scef' variabale as a numpy array of the proper size/shape/type the segfault went away.

I am still getting further errors, but so far going through the terminal output using --debug-capi and carefully resizing anything that is not the correct shape/size/type seems to be fixing them.

If any one else is experiencing these issues, I hope this helps.

ivanarnold
  • 115
  • 5
  • "No sure if I'm supposed to be answering my own questions like this" - if you asked a question about a specific problem and then find a solution for that problem yourself, you are even ___encouraged___ to answer your own question ! That's why you can even accept your own answer ! – TheEagle Jun 29 '21 at 17:04