I'm writing a HDF5 wrapper subroutine that will read/write a double precision array of any shape from/to a dataset inside a HDF5 file. To achieve this, I use some C pointer trickery such that the subroutine takes in only the first element of the array as val, but it actually reads/writes the whole array using the temporary buffer buf(1:sz_buf).
So far I have the following for the read subroutine (after removing error checks to keep it concise):
SUBROUTINE hdf5_read_array_d( fname, path, name, val, dims )
USE ISO_C_BINDING, ONLY: C_SIZE_T, C_LOC, C_F_POINTER
! Input arguments
CHARACTER(LEN=*), INTENT(IN) :: fname, path, name
REAL(KIND(1.D0)), TARGET, INTENT(OUT) :: val
INTEGER, DIMENSION(:), INTENT(IN) :: dims
! Internal variables
INTEGER(KIND=HID_T) :: h5root, h5path, h5dset
INTEGER(KIND=HSIZE_T), DIMENSION(SIZE(dims)) :: h5dims
REAL(KIND(1.D0)), DIMENSION(:), POINTER :: buf
INTEGER(KIND=C_SIZE_T) :: sz_buf
INTEGER :: dim
! Open the file in read-only mode
CALL h5fopen_f( TRIM(fname), H5F_ACC_RDONLY_F, h5root, ierr )
! Open the pre-existing path in the file as a group
CALL h5gopen_f( h5root, TRIM(path), h5path, ierr )
! Open the dataset
CALL h5dopen_f( h5path, TRIM(name), h5dset, ierr )
! Convert dims to HSIZE_T
h5dims(:) = dims(:)
! C pointer trickery: cast double -> void* -> double*
sz_buf = PRODUCT(dims)
ALLOCATE( buf( sz_buf ) )
CALL C_F_POINTER( C_LOC(val), buf, (/sz_buf/) )
! Read data from dataset through buffer
CALL h5dread_f( h5dset, H5T_NATIVE_DOUBLE, buf, h5dims, ierr )
! Clean up and close HDF5 file
NULLIFY(buf)
CALL h5dclose_f( h5dset, ierr )
CALL h5gclose_f( h5path, ierr )
CALL h5fclose_f( h5root, ierr )
RETURN
END SUBROUTINE hdf5_read_array_d
Now, the question is, do I need to also put in DEALLOCATE(buf) in addition to / in place of the NULLIFY(buf)?
Any help would be appreciated.
Note: I am aware that Fortran 2018 includes assumed-rank arrays val(..) that will elegantly solve this problem. But again, it's a newer feature that might not be implemented by all compilers yet.
Edit: On C_F_POINTER(), here's a screenshot of Metcalf, Reid, and Cohen (4th Edition, not the newest one that has Fortran 2018 stuff):
You can use C-style pointer trickery to do what you want, but you have some things to address in your approach:
you have a memory leak with allocate(buf)
you are (subtly) lying about the scalar nature of val
you'll horribly confuse anyone reading your code
The reason why this is horribly confusing, is because you don't need to do this trickery. That's also why I won't show you how to do it, or to address the question "do I need to deallocate as well as nullify?".
You know that you have an array val to stuff n values in, in a contiguous lump. You worry that that can't do that because you (without using an assumed-rank dummy) have to match array shape. Worry not.
integer :: a(2,2,2,2), b(4,2,2), c(4,4)
are all arrays with 16 elements. So is
integer :: d(16)
You can associate actual arguments a, b and c with dummy argument d. Let's see that in action:
implicit none
integer :: a(2,2,2,2), b(4,2,2), c(4,4)
call set_them(a, SHAPE(a))
call set_them(b, SHAPE(b))
call set_them(c, SHAPE(c))
print '(16I3)', a, b, c
contains
subroutine set_them(d, dims)
integer, intent(in) :: dims(:)
integer, intent(out) :: d(PRODUCT(dims))
integer i
d=[(i,i=1,SIZE(d))]
end subroutine
end program
You can even associate array sections in this way to define portions.
You can see several other questions around here about this sequence association, in particular looking at changing shapes of arrays. This answer is more of a motivation of what to look for when tempted to do something complicated instead.
complex to real+imag part
Given a complex array we can assign pointers to its real and imaginary part following the answer in https://stackoverflow.com/a/54819542
program main
use iso_c_binding
implicit none
complex, target :: z(2) = [(1,2), (3,4)]
real, pointer :: re(:), im(:), buf(:)
call c_f_pointer(c_loc(z), buf, shape=[size(z)*2])
re(1:2) => buf(1::2)
im(1:2) => buf(2::2)
print *, 'z', z
print *, 're', re
print *, 'im', im
end program
real+imag part to complex
My question is how to do it the other way around?
Given two real arrays re,im. How can one assign a complex pointer z where the real part is given by re and imaginary part by im? Something similar to
program main
implicit none
real, target :: re(2)=[1,3], im(2)=[2,4]
complex, pointer :: z(:)
z => cmplx(re, im) ! doesnt work as cmplx doesnt return a pointer result
end program
Is it even possible as re,im are not always contiguous in memory?
There are basically two ways to pass arrays to a subroutine in Fortran 90/95:
PROGRAM ARRAY
INTEGER, ALLOCATABLE :: A(:,:)
INTEGER :: N
ALLOCATE(A(N,N))
CALL ARRAY_EXPLICIT(A,N)
! or
CALL ARRAY_ASSUMED(A)
END PROGRAM ARRAY
SUBROUTINE ARRAY_EXPLICIT(A,N)
INTEGER :: N
INTEGER :: A(N,N)
! bla bla
END SUBROUTINE ARRAY_EXPLICIT
SUBROUTINE ARRAY_ASSUMED(A)
INTEGER, ALLOCATABLE :: A(:,:)
N=SIZE(A,1)
! bla bla
END SUBROUTINE ARRAY_ASSUMED
where you need an explicit interface for the second, usually through the use of a module.
From FORTRAN77, I'm used to the first alternative, and I read this is also the most efficient if you pass the whole array.
The nice thing with the explicit shape is that I can also call a subroutine and treat the array as a vector instead of a matrix:
SUBROUTINE ARRAY_EXPLICIT(A,N)
INTEGER :: N
INTEGER :: A(N**2)
! bla bla
END SUBROUTINE ARRAY_EXPLICIT
I wondered if there is a nice way to do that kind of thing using the second, assumed shape interface, without copying it.
See the RESHAPE intrinsic, e.g.
http://gcc.gnu.org/onlinedocs/gfortran/RESHAPE.html
Alternatively, if you want to avoid the copy (in some cases an optimizing compiler might be able to do a reshape without copying, e.g. if the RHS array is not used afterwards, but I wouldn't count on it), as of Fortran 2003 you can assign pointers to targets of different rank, using bounds remapping. E.g. something like
program ptrtest
real, pointer :: a(:)
real, pointer :: b(:,:)
integer :: n = 10
allocate(a(n**2))
a = 42
b (1:n, 1:n) => a
end program ptrtest
I was looking to do the same thing and came across this discussion. None of the solutions suited my purposes, but I found that there is a way to reshape an array without copying the data using iso_c_binding if you are using the fortran 2003 standard which current fortran 90/95 compilers tend to support. I know the discussion is old, but I figured I would add what I came up with for the benefit of others with this question.
The key is to use the function C_LOC to convert an array to an array pointer, and then use C_F_POINTER to convert this back into a fortran array pointer with the desired shape. One challenge with using C_LOC is that C_LOC only works for array that have a directly specified shape. This is because arrays in fortran with an incomplete size specification (i.e., that use a : for some dimension) include an array descriptor along with the array data. C_LOC does not give you the memory location of the array data, but the location of the descriptor. So an allocatable array or a pointer array don't work with C_LOC (unless you want the location of the compiler specific array descriptor data structure). The solution is to create a subroutine or function that receives the array as an array of fixed size (the size really doesn't matter). This causes the array variable in the function (or subroutine) to point to the location of the array data rather than the location of the array descriptor. You then use C_LOC to get a pointer to the array data location and C_F_POINTER to convert this pointer back into an array with the desired shape. The desired shape must be passed into this function to be used with C_F_POINTER. Below is an example:
program arrayresize
implicit none
integer, allocatable :: array1(:)
integer, pointer :: array2(:,:)
! allocate and initialize array1
allocate(array1(6))
array1 = (/1,2,3,4,5,6/)
! This starts out initialized to 2
print *, 'array1(2) = ', array1(2)
! Point array2 to same data as array1. The shape of array2
! is passed in as an array of intergers because C_F_POINTER
! uses and array of intergers as a SIZE parameter.
array2 => getArray(array1, (/2,3/))
! Change the value at array2(2,1) (same as array1(2))
array2(2,1) = 5
! Show that data in array1(2) was modified by changing
! array2(2,1)
print *, 'array(2,1) = array1(2) = ', array1(2)
contains
function getArray(array, shape_) result(aptr)
use iso_c_binding, only: C_LOC, C_F_POINTER
! Pass in the array as an array of fixed size so that there
! is no array descriptor associated with it. This means we
! can get a pointer to the location of the data using C_LOC
integer, target :: array(1)
integer :: shape_(:)
integer, pointer :: aptr(:,:)
! Use C_LOC to get the start location of the array data, and
! use C_F_POINTER to turn this into a fortran pointer (aptr).
! Note that we need to specify the shape of the pointer using an
! integer array.
call C_F_POINTER(C_LOC(array), aptr, shape_)
end function
end program
#janneb has already answered re RESHAPE. RESHAPE is a function -- usually used in an assignment statement so there will be a copy operation. Perhaps it can be done without copying using pointers. Unless the array is huge, it is probably better to use RESHAPE.
I'm skeptical that the explicit shape array is more efficient than the assumed shape, in terms of runtime. My inclination is to use the features of the Fortran >=90 language and use assumed shape declarations ... that way you don't have to bother passing the dimensions.
EDIT:
I tested the sample program of #janneb with ifort 11, gfortran 4.5 and gfortran 4.6. Of these three, it only works in gfortran 4.6. Interestingly, to go the other direction and connect a 1-D array to an existing 2-D array requires another new feature of Fortran 2008, the "contiguous" attribute -- at least according to gfortran 4.6.0 20110318. Without this attribute in the declaration, there is a compile time error.
program test_ptrs
implicit none
integer :: i, j
real, dimension (:,:), pointer, contiguous :: array_twod
real, dimension (:), pointer :: array_oned
allocate ( array_twod (2,2) )
do i=1,2
do j=1,2
array_twod (i,j) = i*j
end do
end do
array_oned (1:4) => array_twod
write (*, *) array_oned
stop
end program test_ptrs
You can use assumed-size arrays, but it can mean multiple layers of wrapper
routines:
program test
implicit none
integer :: test_array(10,2)
test_array(:,1) = (/1, 2, 3, 4, 5, 6, 7, 8, 9, 10/)
test_array(:,2) = (/11, 12, 13, 14, 15, 16, 17, 18, 19, 20/)
write(*,*) "Original array:"
call print_a(test_array)
write(*,*) "Reshaped array:"
call print_reshaped(test_array, size(test_array))
contains
subroutine print_reshaped(a, n)
integer, intent(in) :: a(*)
integer, intent(in) :: n
call print_two_dim(a, 2, n/2)
end subroutine
subroutine print_two_dim(a, n1, n2)
integer, intent(in) :: a(1:n1,1:*)
integer, intent(in) :: n1, n2
call print_a(a(1:n1,1:n2))
end subroutine
subroutine print_a(a)
integer, intent(in) :: a(:,:)
integer :: i
write(*,*) "shape:", shape(a)
do i = 1, size(a(1,:))
write(*,*) a(:,i)
end do
end subroutine
end program test
I am using ifort 14.0.3 and 2D to 1D conversion, I could use an allocatable array for 2D array and a pointer array for 1D:
integer,allocatable,target :: A(:,:)
integer,pointer :: AP(:)
allocate(A(3,N))
AP(1:3*N) => A
As #M.S.B mentioned, in case both A and AP have the pointer attribute, I had to use contiguous attribute for A to guarantee the consistency of the conversion.
Gfortran is a bit paranoid with interfaces. It not only wants to know the type, kind, rank and number of arguments, but also the shape, the target attribute and the intent (although I agree with the intent part). I encountered a similar problem.
With gfortran, there are three different dimension definition:
1. Fixed
2. Variable
3. Assumed-size
With ifort, categories 1 and 2 are considered the same, so you can do just define any dimension size as 0 in the interface and it works.
program test
implicit none
integer, dimension(:), allocatable :: ownlist
interface
subroutine blueprint(sz,arr)
integer, intent(in) :: sz
integer, dimension(0), intent(in) :: arr
! This zero means that the size does not matter,
! as long as it is a one-dimensional integer array.
end subroutine blueprint
end interface
procedure(blueprint), pointer :: ptr
allocate(ownlist(3))
ownlist = (/3,4,5/)
ptr => rout1
call ptr(3,ownlist)
deallocate(ownlist)
allocate(ownlist(0:10))
ownlist = (/3,4,5,6,7,8,9,0,1,2,3/)
ptr => rout2
call ptr(3,ownlist)
deallocate(ownlist)
contains
! This one has a dimension size as input.
subroutine rout1(sz,arr)
implicit none
integer, intent(in) :: sz
integer, dimension(sz), intent(in) :: arr
write(*,*) arr
write(*,*) arr(1)
end subroutine rout1
! This one has a fixed dimension size.
subroutine rout2(sz,arr)
implicit none
integer, intent(in) :: sz
integer, dimension(0:10), intent(in) :: arr
write(*,*) "Ignored integer: ",sz
write(*,*) arr
write(*,*) arr(1)
end subroutine rout2
end program test
Gfortran complains about the interface. Changing the 0 into 'sz' solves the problem four 'rout1', but not for 'rout2'.
However, you can fool gfortran around and say dimension(0:10+0*sz) instead of dimension(0:10) and gfortran compiles and gives the same
result as ifort.
This is a stupid trick and it relies on the existence of the integer 'sz' that may not be there. Another program:
program difficult_test
implicit none
integer, dimension(:), allocatable :: ownlist
interface
subroutine blueprint(arr)
integer, dimension(0), intent(in) :: arr
end subroutine blueprint
end interface
procedure(blueprint), pointer :: ptr
allocate(ownlist(3))
ownlist = (/3,4,5/)
ptr => rout1
call ptr(ownlist)
deallocate(ownlist)
allocate(ownlist(0:10))
ownlist = (/3,4,5,6,7,8,9,0,1,2,3/)
ptr => rout2
call ptr(ownlist)
deallocate(ownlist)
contains
subroutine rout1(arr)
implicit none
integer, dimension(3), intent(in) :: arr
write(*,*) arr
write(*,*) arr(1)
end subroutine rout1
subroutine rout2(arr)
implicit none
integer, dimension(0:10), intent(in) :: arr
write(*,*) arr
write(*,*) arr(1)
end subroutine rout2
end program difficult_test
This works under ifort for the same reasons as the previous example, but gfortran complains about the interface. I do not know how I can fix it.
The only thing I want to tell gfortran is 'I do not know the dimension size yet, but we will fix it.'. But this needs a spare integer arguemnt (or something else that we can turn into an integer) to fool gfortran around.
This question already has an answer here:
Associated pointers in derived type? gFortran vs. Intel
(1 answer)
Closed 3 years ago.
I'm trying to learn the data-strcuture of a linked-list using Pointers in Fortran 90 on the platform of Win32/x86.
But when I runs the test-case that simply aims to build a list of 100 items, the program terminates with and error of 'Access violation'.
And the list is far from finished before the error occurs.
In debug run, it turns out that, at some point, the allocation of NEXT-Pointer fails.
I'm wondering why could this happen?
How could the linked-list be build successfully using pointers?
Codes are as follows:
TYPE Ptr
INTEGER :: I
TYPE(Ptr),POINTER :: PREV,NEXT
END TYPE Ptr
TYPE(Ptr),POINTER :: P
INTEGER :: IP,Err
ALLOCATE(P)
DO IP=1,100
P%I = IP
IF ( .NOT.ASSOCIATED(P%NEXT) ) THEN
ALLOCATE(P%NEXT, STAT=Err )
END IF
P%NEXT%PREV => P
P => P%NEXT
END DO
On UBUNTU with gfortran 7.2 your program compiled and ran just fine. There are, however two issues with your program, that may trip off your compiler:
After you allocate p the status of the pointers p%next and p%prev is undefined. It might be that your compiler then gets tripped on the statement IF(.not.associated(p%next)), as the status of p%next is undefined. Always nullify pointers before you use them or refer to them in any which way. Try:
program pointers
!
TYPE Ptr
INTEGER :: I
TYPE(Ptr),POINTER :: PREV,NEXT
END TYPE Ptr
!
TYPE(Ptr),POINTER :: P => NULL() ! Make sure all pointer are nullified
TYPE(Ptr),POINTER :: head => NULL()
TYPE(Ptr),POINTER :: temp => NULL()
INTEGER :: IP,Err
!
NULLIFY(P) ! This is identical to the nullify in the declaration statement
NULLIFY(head) ! I've added it to show both styles
NULLIFY(temp)
!
ALLOCATE(P)
NULLIFY(P%NEXT) ! Always nullify pointers
NULLIFY(P%PREV) ! Always nullify pointers
head => P ! To keep a header to your list is a good idea
!
DO IP=1,100
write(*,*) ip
P%I = IP*IP ! Trivial unimportant change
!
IF ( .NOT.ASSOCIATED(P%NEXT) ) THEN
ALLOCATE(P%NEXT, STAT=Err )
P%NEXT%I = ip+1 ! define entries
NULLIFY(P%NEXT%NEXT) ! for next node
NULLIFY(P%NEXT%PREV) ! for all elements of your TYPE
END IF
!
P%NEXT%PREV => P
P => P%NEXT
!
END DO
!
temp => head ! temporary pointer to navigate
DO WHILE( ASSOCIATED(temp) )
write(*,*) ' AT NODE ', temp%i
temp => temp%next
ENDDO
!
end program pointers
As pointed out by #Alexander Vogt, you loose the start of the list. I added a pointer called head to retain this beginning of the list. If you look at the output you will notice that the program actually makes a list of 100+1 entries, since you make p first, then you add 100 times a p%next.
In Fortran, you can reshape arrays with pointers:
program working
implicit none
integer, dimension(:,:), pointer :: ptr
integer, dimension(6), target :: trg
trg = (/1,2,3,4,5,6/)
ptr(1:2,1:3) => trg
! Here, you can use the 6-sized 1D array trg
! or the 2 by 3-sized 2D array ptr at the same time.
! Both have the same content (6 integers), but are only indexed
! differently.
write(*,*) ptr(1,2)
end program working
This program writes "3", which is according to the reshape rules.
Similarly, I attempted to do the same, but not with 1D to 2D, but 0D to 1D.
program not_working
implicit none
integer, dimension(:), pointer :: ptr
integer, target :: trg
trg = 1
ptr(1:1) => trg
! I hoped to be able to use the scalar trg at the same time as
! the one-sized 1D array ptr. I thought they both have the same
! content, but are only indexed differently.
write(*,*) ptr(1)
end program not_working
I expected to see a "1". But it does not compile.
Gfortran 4.9 says:
Error: Rank remapping target must be rank 1 or simply contiguous at
(1)
Ifort 14.0.2 says:
<file>.f90: catastrophic error: Internal compiler error:
segmentation violation signal raised Please report this error along
with the circumstances in which it occurred in a Software Problem
Report. Note: File and line given may not be explicit cause of this
error. compilation aborted for <file>.f90 (code 1)
I do not understand how the scalar trg can be not contiguous and what the fundamental difference between the two example programs is.
The scalar is not simply contiguous array because it is not an array at all. It is as simple as that. Gfortran detects it and complains, ifort is confused and crashes. But your code is invalid, you cannot point an array pointer on a scalar.
Array pointers are desinged to point to arrays, so cannot point to scalars (instead, we can use scalar pointers for this purpose). But if we definitely want to use array pointers to point to scalars (for some reason), we could use c_f_pointer() such that
use iso_c_binding
integer, target :: a
integer, pointer :: p(:), q(:,:), r(:,:,:)
a = 777
call c_f_pointer( c_loc( a ), p, [1] )
call c_f_pointer( c_loc( a ), q, [1,1] )
call c_f_pointer( c_loc( a ), r, [1,1,1] )
print *, "p = ", p(:), "with shape", shape(p)
print *, "q = ", q(:,:), "with shape", shape(q)
print *, "r = ", r(:,:,:), "with shape", shape(r)
But this is clearly an "unsafe" feature (in the sense that it allows access to raw memory), and if used with wrong arguments, it could give a wrong result (or even disaster), for example:
call c_f_pointer( c_loc( a ), p, [3] )
print *, "p = ", p(:) !! gives "p = 777 202 0" etc with garbage data
So, unless there is some special reason, I think it is probably better (safer) to use scalar pointers for scalar variables...