Optimization 通过动态切片的纯Fortran子程序

Optimization 通过动态切片的纯Fortran子程序,optimization,parallel-processing,fortran,gfortran,pure-virtual,Optimization,Parallel Processing,Fortran,Gfortran,Pure Virtual,我最近读到()纯子例程可以允许更好的并行优化。假设这是真的,有没有办法让下面的例程变得纯粹 subroutine diff_stag(operator,dfdh,f,T,dir,pad,gt) implicit none procedure(stencils_stag) :: operator type(realField),intent(inout) :: dfdh type(realField),intent(in) :: f type(triDiag),in

我最近读到()纯子例程可以允许更好的并行优化。假设这是真的,有没有办法让下面的例程变得纯粹

 subroutine diff_stag(operator,dfdh,f,T,dir,pad,gt)
   implicit none
   procedure(stencils_stag) :: operator
   type(realField),intent(inout) :: dfdh
   type(realField),intent(in) :: f
   type(triDiag),intent(in) :: T
   integer,intent(in) :: dir,pad,gt
   integer :: i,j,k
   select case (dir)
   case (1)
   !$OMP PARALLEL DO SHARED(T,f,gt)
   do k=1+pad,f%s(3)-pad; do j=1+pad,f%s(2)-pad
     call operator(dfdh%f(:,j,k),f%f(:,j,k),T,f%s(dir),dfdh%s(dir),gt)
   enddo; enddo
   !$OMP END PARALLEL DO
   case (2)
   !$OMP PARALLEL DO SHARED(T,f,gt)
   do k=1+pad,f%s(3)-pad; do i=1+pad,f%s(1)-pad
     call operator(dfdh%f(i,:,k),f%f(i,:,k),T,f%s(dir),dfdh%s(dir),gt)
   enddo; enddo
   !$OMP END PARALLEL DO
   case (3)
   !$OMP PARALLEL DO SHARED(T,f,gt)
   do j=1+pad,f%s(2)-pad; do i=1+pad,f%s(1)-pad
     call operator(dfdh%f(i,j,:),f%f(i,j,:),T,f%s(dir),dfdh%s(dir),gt)
   enddo; enddo
   !$OMP END PARALLEL DO
   case default
   stop 'Error: dir must = 1,2,3 in delGen_T in ops_del.f90.'
   end select
 end subroutine
我认为,问题在于选择案例会带来一种副作用,这是不允许的

是否有一种方法可以对字段
f%f(I,j,k)
dfdh%f(I,j,k)
进行切片,以便不需要选择案例


非常感谢您的帮助

给定的子例程不能是纯的,因为它包含STOP语句

除此之外,子例程是否可以变得纯净取决于
操作符
子例程是否纯净(或者可以变得纯净),可能还取决于派生类型是否有指针组件


我不认为“动态切片”是相关的。

给定的子例程不能是纯的,因为它包含STOP语句

除此之外,子例程是否可以变得纯净取决于
操作符
子例程是否纯净(或者可以变得纯净),可能还取决于派生类型是否有指针组件


我不认为“动态切片”是相关的。

我明白了,我并没有收到关于删除停止的编译器投诉,但我收到了关于编译器标志的投诉。我认为重要的是,
calloperator
是纯的,而不是
diff\u stag
。我想我的问题有点草率。如果你能评论/确认我在评论中的结论,我会接受这个答案。我不理解这个评论。什么是“编译器标志”?当你说“什么是重要的”,对什么重要?对不起,我指的是
$OMP并行DO共享(T、f、gt)
语句,而不是“编译器标志”。另外,我所说的“重要的”是,我相信,
操作符
子例程应该是编译器优化并行循环的纯函数,而不是
diff_stag
子例程。如果您使用OpenMP并行指令,编译器很可能只执行这些指令明确要求它执行的操作,而不是任何聪明的并行优化。被调用的过程是否纯粹可能会分散注意力。不过,一个纯粹的过程不会影响优化。我明白了,我并没有收到关于删除停止的编译器投诉,但我收到了关于编译器标志的投诉。我认为重要的是,
calloperator
是纯的,而不是
diff\u stag
。我想我的问题有点草率。如果你能评论/确认我在评论中的结论,我会接受这个答案。我不理解这个评论。什么是“编译器标志”?当你说“什么是重要的”,对什么重要?对不起,我指的是
$OMP并行DO共享(T、f、gt)
语句,而不是“编译器标志”。另外,我所说的“重要的”是,我相信,
操作符
子例程应该是编译器优化并行循环的纯函数,而不是
diff_stag
子例程。如果您使用OpenMP并行指令,编译器很可能只执行这些指令明确要求它执行的操作,而不是任何聪明的并行优化。被调用的过程是否纯粹可能会分散注意力。不过,一个纯粹的过程不会影响优化。