F2PY, Fortran and Netcdf - Memory Fault

Viewed 114

I have a problem with calling Fortran code including NetCDF subroutines from Python using F2PY. I manage to compile the code OK but when I call it from Python I always get a 'Memory Fault' error.

For testing purposes I am using a code from the Unidata website:

http://www.unidata.ucar.edu/software/netcdf/docs/netcdf-f90.

I included the code below:

subroutine simple_xy_wr



   use netcdf
   implicit none   

   ! This is the name of the data file we will create.
   character (len = *), parameter :: FILE_NAME = "simple_xy.nc"

   ! We are writing 2D data, a 12 x 6 grid.
   integer, parameter :: NDIMS = 2
   integer, parameter :: NX = 6, NY = 12

   ! When we create netCDF files, variables and dimensions, we get back
   ! an ID for each one.
   integer :: ncid, varid, dimids(NDIMS)
   integer :: x_dimid, y_dimid

   ! This is the data array we will write. It will just be filled with
   ! a progression of integers for this example.
   integer :: data_out(NY, NX)

   ! Loop indexes, and error handling.
   integer :: x, y

   ! Create some pretend data. If this was not an example program, we
   ! would have some real data to write, for example, model output.
   do x = 1, NX
      do y = 1, NY
         data_out(y, x) = (x - 1) * NY + (y - 1)
      end do
   end do

   ! Always check the return code of every netCDF function call. In
   ! this example program, wrapping netCDF calls with "call check()"
   ! makes sure that any return which is not equal to nf90_noerr (0)
   ! will print a netCDF error message and exit.

   ! Create the netCDF file. The nf90_clobber parameter tells netCDF to
   ! overwrite this file, if it already exists.

   call check(nf90_create(FILE_NAME, NF90_CLOBBER, ncid) )


   ! Define the dimensions. NetCDF will hand back an ID for each.
   call check(nf90_def_dim(ncid, "x", NX, x_dimid) ) 
   call check( nf90_def_dim(ncid, "y", NY, y_dimid) )

   ! The dimids array is used to pass the IDs of the dimensions of
   ! the variables. Note that in fortran arrays are stored in
   ! column-major format.
   dimids =  (/ y_dimid, x_dimid /)

   ! Define the variable. The type of the variable in this case is
   NF90_INT (4-byte integer).
   call check( nf90_def_var(ncid, "data", NF90_INT, dimids, varid) )

   ! End define mode. This tells netCDF we are done defining metadata.
   call check( nf90_enddef(ncid) )

   ! Write the pretend data to the file. Although netCDF supports
   ! reading and writing subsets of data, in this case we write all the
   ! data in one operation.
   call check( nf90_put_var(ncid, varid, data_out) )

   ! Close the file. This frees up any internal netCDF resources
   ! associated with the file, and flushes any buffers.
   call check( nf90_close(ncid) )

   print *, "*** SUCCESS writing example file simple_xy.nc! "

   contains

   subroutine check(status)
      integer, intent ( in) :: status

      if(status /= nf90_noerr) then
        print *, trim(nf90_strerror(status))
        stop 2
      end if
   end subroutine check

end subroutine simple_xy_wr

I compile this code as follows using F2PY:

> f2py -c -L/gfortran-4.4.5/lib -lnetcdff \ 
>         -I/gfortran-4.4.5/include \
>         --fcompiler=gfortran \    
>         --f90flags="-g -fconvert=little-endian -frecord-marker=8 -fdefault-real-8 -Wall -O -fbounds-check -ffixed-line-length-none -ffree-line-length-none -fbacktrace -fcheck=all" \     
>         -m __test__  test2.f90 --debug
> 
> f2py -h __test__.pyf -m __test__  test2.f90 --overwrite-signature

In python I do the following:

import __test__
__test__.simple_xy_wr()

which invariably results in a Memory Fault(coredump) error and nothing else, i.e. I get no other information. Having used print statements it seems that the error occurs at the

call check(nf90_create(FILE_NAME, NF90_CLOBBER, ncid) )

I then replaced this line with (having defined status as an integer):

status=nf90_create(FILE_NAME, NF90_CLOBBER, ncid)

and I still get the Memory Fault(coredump) error. This is seems that it is definitely the call to NF90_create that results in the error.

I have another code (more complicated) where exactly the same error occurs at the first call to a NF90 subroutine.

Any ideas what causes this error and how I can get around it. I am not even sure how to debug this anymore. I had a look at the Unidata webpages but am none the wiser.

0 Answers
Related