- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
Link Copied
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page