Sizing of private arrays in OpenACC

Dear all,
I am getting well up to speed in porting a pretty big radiation transport code to the GPU using OpenACC. During this endeavour I am running into various issues and learning from them.

I am encountering an issue with a private array that apparently has to be fixed-size. The following code snippet has the array elem_flux that is sized depending on the actual argument (it depends on SN_set%no_dirs). Tye compiler tells me:

I have the following code snippet

sorry, somehow posted when not done yet …

The compiler tells me that it expects a data clause with default(none). If I size it with a constant the code complies fine. Here’s the snippet:

subroutine CT_project_grp_ang_to_mom(SN_set)

type(SN_set_type) :: SN_set

integer, parameter :: no_nod_elem=4
real(dp), dimension(SN_set%no_dirs*no_nod_elem) :: elem_flux

!$acc parallel default(none) present(…)
!$acc loop independent private(elem_flux, …)
do elem_no=1,CTscan_no_voxels
flux_index_start = …
flux_index_end = …

elem_flux(1:flux_index_end-flux_index_start+1) = flux(flux_index_start:flux_index_end)
!$acc end loop
!$acc end parallel

end subroutine CT_project_grp_ang_to_mom

Can anyone tell me what is allowed and what is not?
In my case I can restructure the code to solve it, but what are the options when the array needs to be sized on entering the subroutine?

Note: this is for version 23.5.

Thx and sorry for the reply-post.

Hi D Lathouwers,

I am encountering an issue with a private array that apparently has to be fixed-size.

The size needs to be known on entering the parallel region, but should not need to be fixed-size.

I’m not seeing anything obvious so suspect something else is going on.

Can you please post the error message and if possible a reproducing example?

While this shouldn’t be necessary since the compiler will know elem_flux is an array, you might try:

!$acc loop independent private(elem_flux(:), …)


I put a lot of effort in coming up with an easy example that throws the same error. The error BTW was NVFORTRAN-S-1069-Data clause required with default(none) - elem_flux(:).

Turns out that it is triggered by using the compiler flag -Mchkptr. Seems to me that this check has nothing to do with my example (see below). So I am not certain if it’s a bug or feature (FYI am still on version 23.5).

Anyhow: this problem is fixed for me.
Thanks for your help and clarifications.


subroutine XXX(flux,moments,no_dirs)

integer, intent(in) :: no_dirs
real, dimension(:) :: flux
real, dimension(:) :: moments

integer, parameter :: no_nod_elem=4
integer :: elem_no
integer :: dir
integer :: mom
integer :: mom_index_start,mom_index_end
integer :: flux_index_start,flux_index_end
integer :: elem_flux_index_start,elem_flux_index_end
real, dimension(no_dirs*no_nod_elem) :: elem_flux

!$acc enter data copyin(flux)
!$acc enter data create(moments)

!$acc parallel default(none) present(flux,flux,moments)
!$acc loop independent private(elem_no,dir,mom,elem_flux,flux_index_start,flux_index_end,mom_index_start,mom_index_end)
do elem_no=1,100
flux_index_start = 1
flux_index_end = 3

elem_flux(1:flux_index_end-flux_index_start+1) = flux(flux_index_start:flux_index_end)

do mom=1,1
mom_index_start = 1
mom_index_end = mom_index_start + no_nod_elem - 1
do dir=1,1
elem_flux_index_start = (dir-1)*no_nod_elem + 1
elem_flux_index_end = elem_flux_index_start + no_nod_elem - 1

  moments(mom_index_start:mom_index_end) = elem_flux(elem_flux_index_start:elem_flux_index_end)


!$acc end loop
!$acc end parallel

end subroutine XXX

Thanks Danny!

Interesting. I’m not sure what -Mchkptr is doing to cause this, it should just be checking if the array argument is NULL. I added a problem report, TPR #35529, and sent it to engineering for investigation. Given it’s an uncommon use case, they may not make it a high priority (unless it’s an easy fix), but it’s good to make them aware.


Cheers Mat.