Issue with loop for allocatable array in private (openmp)

[Danny_L_]

Dear community,

​I am encountering a weird problem involving OpenMP. This simple code snippet

integer :: elem_no

integer :: no_nod_elem

real(dp), allocatable, dimension(:) :: fiss_den

!$OMP PARALLEL DO &

!$OMP& DEFAULT(none) &

!$OMP& SHARED(mesh) &

!$OMP& PRIVATE(no_nod_elem,fiss_den)

do elem_no=1,mesh%no_active_elem

  no_nod_elem = 5

  allocate(fiss_den(no_nod_elem)) ! X

  fiss_den = 0.0_dp

  deallocate(fiss_den)

enddo

!$OMP END PARALLEL DO

fails with the message that fiss_den is already allocated (on line marked X).

Mesh is a complex data_type with the entry no_active_elem an integer. If I replace mesh%no_active_elem by some new integer variable that was set to the correct value, then it does work (at least running on single thread). So something fishy going on. Are there any restrictions I am not aware of?

Any ideas why this would happen? I have seen similar questions posted before, but I believe these issues were fixed in previous versions (I am using 17.0.4 on linux).

Thanks for any pointers you might have.

Danny.

[Ferdinand_T_]

Hi Danny,

I encountered a lot of similar errors on using Fortran-2003 features (e.g. polymorphic types) with openMP in the past. In your code, the problem seems to be related to the "mesh" -type. Maybe it helps if you provided the declaration of that object?

I tested the following code and it worked fine (Ubuntu 14.0.4, ifort 17.0.4, openMP 3.0 11/2015, compiled with -qopenmp -fpp):

program p
	type :: mesh_type
		integer :: no_active_elem = 10
	end type
	type(mesh_type) :: mesh

	integer, parameter :: dp = kind(0d0)
	real(kind=dp), allocatable, dimension(:) :: fiss_den

	integer :: elem_no
	integer :: no_nod_elem

	print *, _OPENMP

	!$OMP PARALLEL DO &
	!$OMP& DEFAULT(none) &
	!$OMP& SHARED(mesh) &
	!$OMP& PRIVATE(no_nod_elem,fiss_den)
	
	do elem_no=1,mesh%no_active_elem

	  no_nod_elem = 5

	  allocate(fiss_den(no_nod_elem)) ! X

	  deallocate(fiss_den)

	enddo

	!$OMP END PARALLEL DO

end program

Regards,
Ferdinand

[Danny_L_]

Hello Ferdinand,

Yes indeed it seems to come from the mesh variable. I can use the workaround I mentioned by first copying into another integer variable but I'd rather have it working as is. Here is the mesh declaration for completeness.

  type fem_mesh

    integer :: dimen

    integer :: no_vertices

    integer :: no_elem

    integer :: no_active_elem

    integer :: old_no_active_elem

    logical, allocatable, dimension(:) :: list_of_elems_tobe_refined

    type(elem_id), allocatable, dimension(:) :: active_elem_list

    type(elem_id), allocatable, dimension(:) :: elem_list

    type(elem_id), allocatable, dimension(:) :: old_active_elem_list

    type(elem_list), pointer :: elem_list_head => null()

    type(elem_list), pointer :: elem_list_ptr => null()

    type(face_list), pointer :: face_list_head => null()

    type(face_list), pointer :: face_list_ptr => null()

    type(vertex_list), pointer :: vertex_list_head => null()

    type(vertex_list), pointer :: vertex_list_tail => null()

    type(vertex_list), pointer :: vertex_list_ptr => null()

  end type fem_mesh

I will see if I can reconstruct a self-contained example that actually uses mesh which is of type fem_mesh.

Cheers,

Danny.

[TimP]

Note that currently supported ifort linux releases are 17.0.5 and 18.0.  I'm trying to find my way around the updated ism schemes.

[jimdempseyatthecove]

Make the unallocated array FIRSTPRIVATE, not PRIVATE. First private copies in the current state of the private variable/array ... including an unallocated array descriptor.

Jim Dempsey

[Danny_L_]

Thank you all for your comments. They are much appreciated !

The FIRSTPRIVATE construct did it. Not sure if I find it all logical, but I will not forget this construct when I encounter this again.  Still am puzzled that the behaviour depends on the way the last index of the loop is written. Apparently internally, there is a slight difference how it is handled.

Thanks again,

Danny Lathouwers.