Search code examples
pointersfortranderived-types

Fortran 90/95 Pointers in Derived Type


I have a derived type with a pointer to an array of a second derived type

TYPE vertex
   REAL :: x, y, z
END TYPE

TYPE path
   TYPE(vertex), DIMENSION(:), POINTER :: vertices => NULL()
END TYPE

The intent is to make the vertices array resizable so that any number of vertex points can be added to the array. I have created code to append a vertex to that pointer.

SUBROUTINE path_append_vertex(this, x, y, z)
IMPLICIT NONE

!-------------------------------------------------------------------------------
!  Variable declarations.
!-------------------------------------------------------------------------------
TYPE(path), INTENT(inout) :: this
REAL, INTENT(in)   :: x, y, z

!-------------------------------------------------------------------------------
!  Local Variable declarations.
!-------------------------------------------------------------------------------
INTEGER :: status
TYPE(vertex), DIMENSION(:), ALLOCATABLE :: vertices

!-------------------------------------------------------------------------------
!  Start of executable code
!-------------------------------------------------------------------------------
IF (ASSOCIATED(this%vertices)) THEN
! Create a temporary array the same size as current number of vertices. Copy the
! contents of the old array to the new array then delete the old array.
   ALLOCATE(vertices(SIZE(this%vertices)), STAT = status)
   CALL check_status(status)
   vertices = this%vertices
   DEALLOCATE(this%vertices)

! Create a new array with one extra element. Copy the contents of the temporary
! array to the new one the delete the temporary array.
   ALLOCATE(this%vertices(SIZE(vertices) + 1), STAT = status)
   CALL check_status(status)
   this%vertices(1:SIZE(vertices)) = vertices
   DEALLOCATE(vertices)

   this%vertices(SIZE(this%vertices))%x = x
   this%vertices(SIZE(this%vertices))%y = y
   this%vertices(SIZE(this%vertices))%z = z
ELSE
   ALLOCATE(this%vertices(1), STAT = status)
   CALL check_status(status)

   this%vertices(1)%x = x
   this%vertices(1)%y = y
   this%vertices(1)%z = z
ENDIF

END SUBROUTINE

I create a few path objects.

TYPE ipch_desc
   ...
   TYPE(path) :: chordPath
END TYPE

SUBROUTINE ipch_desc_construct(this, ...)
...
TYPE (ipch_desc), INTENT(inout)          :: this
...
!  Must NULL out the vertices array or else it will point to the last
!  integration_path created in memory. Not sure why these are defaulting
!  to NULL
this%chordPath%vertices => NULL()

CALL path_append_vertex(this%chordPath, xcart_i(1), xcart_i(2), xcart_i(3))
CALL path_append_vertex(this%chordPath, xcart_f(1), xcart_f(2), xcart_f(3))

!  Check the value of the path vertices.
write(*,*) this%chordPath%vertices

END SUBROUTINE

Everything work all well and good and I get the correct values for each vertex. For instance for three path objects created I get

 -0.33808113528699218        1.0467574437103653       0.10713720000000000      -0.16057879084545851       0.49717960298733294       0.10713720000000000     
 -0.33322243268266594        1.0483142707971911       1.42240000000000010E-003 -0.14945358419461796       0.47017940500485894       1.42240000000000010E-003
 -0.33656460666251325        1.0472460386853264      -0.10629900000000000      -0.15821659220752302       0.49230280357365630      -0.10629900000000000

When using these path objects latter in the code,

SUBROUTINE ipch_mc_model_compute(a_ipch, ...)
...
TYPE (ipch_desc), INTENT (inout)     :: a_ipch
...
!  Check the value of the path vertices again.
write(*,*) a_ipch%chordPath%vertices
...
END SUBROUTINE

only the first N-1 values remain correct. For the same values created above I get,

 -0.33808113528699218        1.0467574437103653       0.10713720000000000      -0.16057879084545851       0.49717960298733294       0.10713720000000000     
 -0.33322243268266594        1.0483142707971911       1.42240000000000010E-003 -0.14945358419461796       0.47017940500485894       1.42240000000000010E-003
  0.15094203233057696       6.94277920927416864E-310 -0.10629900000000000       1.63041663127611360E-322  3.01884064661153912E-003  6.94277920927179713E-310

Regardless of the number of path objects I create, the Nth always ends up with wrong values. What could be causing this?


Solution

  • I figured out where the problem was. The ipch_desc object was being constructed to a temp then assigned to an element in an array.

    ipch_desc_arr(icount_chords) = ipch_desc_temp
    

    I will either need to remove this temporary or over load the default assignment operators to fix it.