Re: [f2py] F2PY: Unable to prevent Fortran ordered array copy

Thank you, Robin & Labrach, for your comments.

The problem I am experiencing boils down to why the F2PY-module is 
unable to identify a legal NUMPY array to be in the correct order, or 
even recognize legal Numpy array objects!  And the problem persists 
irrespective of the F90 compiler I use (Intel, PG, or GNU).  The crux of 
this problem may be illustrated with the following two examples from the 
python interpreter ('pymm' is the f2py-wrapped module):
--------------------------------------------------------
 >>> # Example 1. ROW-MAJOR-ORDERED ARRAY, 'a':
...
 >>> a = reshape(arange(15),(3,5))
 >>> a
array([[ 0,  1,  2,  3,  4],
          [ 5,  6,  7,  8,  9],
          [10, 11, 12, 13, 14]])
 >>> isfortran(a)
False                                   --------->  OK
 >>> a.flags['F_CONTIGUOUS']
False                                   --------->  OK
 >>>
 >>> pymm.has_column_major_storage(a)
0                                       --------->  OK
 >>> a = pymm.as_column_major_storage(a)
Traceback (most recent call last):
     File "<stdin>", line 1, in <module>
pymm.error: expected array object       --------->  (!)
 >>>
--------------------------------------------------------
...
--------------------------------------------------------
 >>> # Example 2. COLUMN-MAJOR-ORDERED ARRAY, 'b':
...
 >>> b = reshape(arange(15),(3,5),order='f')
 >>> b
array([[ 0,  3,  6,  9, 12],
        [ 1,  4,  7, 10, 13],
        [ 2,  5,  8, 11, 14]])
 >>> isfortran(b)
True                                    --------->  OK
 >>> b.flags['F_CONTIGUOUS']
True                                    --------->  OK
 >>> pymm.has_column_major_storage(b)
0                                       --------->  (!)
 >>> c = pymm.as_column_major_storage(b)
Traceback (most recent call last):
   File "<stdin>", line 1, in <module>
pymm.error: expected array object       --------->  (!)
 >>>
--------------------------------------------------------

So, 'pymm' does not seem to recognize the legal NUMPY arrays, 'a' OR 
'b', as valid array objects!  As a result, the NUMPY array seems to be 
cast into a 'suitable' form by F2PY resulting in array copying when I 
invoke the function 'pymm.mmfunc.mm' [if compiled with 
'intent(in,out,overwrite)' OR 'intent(in,out)' OR 
'intent(in,out,overwrite,c)', and passing the appropriate 
F-/C-CONTIGUOUS arrays]:
"copied an array using PyArray_CopyFromObject: size=1440000, elsize=4
  copied an array using PyArray_CopyFromObject: size=1440000, elsize=4
  copied an array using PyArray_CopyFromObject: size=1440000, elsize=4"

--------------------------------------------------------
However, when I compile with 'intent(inout)', OR 'intent(inplace)', OR 
'intent(inout,c)' with appropriate F-/C-CONTIGUOUS arrays, then I get 
the following error:
"pymm.error: failed in converting 4th argument `a' of pymm.mmfunc.mm to 
C/Fortran array"

--------------------------------------------------------
So, I want to know whether:

1) This could be due to a bug in the F2PY version I am using 
[2.45.241_1926] that was later fixed?  Or a problem with my installation 
of F2PY itself.

2) I am using a wrong flag (or not using a specific flag) during F2PY 
compilation (please see CSH & LOG files in TGZ below)?

3) I am making some subtle mistake while calling the F2PY-module (please 
see 'CALL_MM.PY' & 'MM.F90' file in TGZ)?

Again, all the relevant text files (7 in all) are available at: 
ftp://ftp.gps.caltech.edu/pub/rkanda/MemoryDeallocTest.tgz

I don't know where else to look to try to resolve this problem.  So, it 
will be much appreciated if someone can take a look at the F90, PY, PYF, 
CSH, & LOG files, or actually compile/run the module to see whether  I'm 
experiencing a "unique" problem here.

Thank you very much for your time!
Ravi.
--------------------------------------------

labrach wrote:
> It seems ok for me with the followings :
> 
> (but I don't know how to check if the copy appeared or not, since the
> -DF2PY_REPORT_ATEXIT returns an error dealing with undefine reference
> to 'on_exit')
> 
> I run that on a Windows with mingw 5.1.4
> 
<SNIP>