topic Hi Danny, in Intel® Fortran Compiler

Issue with loop for allocatable array in private (openmp)

Danny_L_ — Tue, 17 Oct 2017 11:38:19 GMT

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.

Hi Danny,

Ferdinand_T_ — Wed, 18 Oct 2017 10:27:04 GMT

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

Hello Ferdinand,

Danny_L_ — Wed, 18 Oct 2017 11:13:44 GMT

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.

Note that currently supported

TimP — Wed, 18 Oct 2017 15:05:07 GMT

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.

Make the unallocated array

jimdempseyatthecove — Wed, 18 Oct 2017 16:33:32 GMT

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

Thank you all for your

Danny_L_ — Wed, 18 Oct 2017 18:39:21 GMT

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.