Błąd segmentacji z openmp w programie Fortran 90 [duplikat]

Piszę mały program do ćwiczenia Fortran 90 i openmp . Poniższy przykład zwraca kod błędu segmentacji kiedy mogę skompilować go gfortran -fopenmp heat.f90 -o heatale działa dobrze, gdy skompilowany bez tej -fopenmpopcji. Czy ktoś może mi pomóc zrozumieć, dlaczego tak się dzieje?

Ustawiam export OMP_NUM_THREADS=4w mojej powłoce (Bash w systemie Ubuntu w systemie Windows 10)

program heat

    use omp_lib
    implicit none

    integer, parameter :: nx = 1000
    integer, parameter :: ny = 800
    real, parameter :: H = 1.
    real, parameter :: alpha = 1.e-4
    real, parameter :: dt = 0.001
    real, parameter :: physical_time = 50.

    real aspect, L, dx, dy
    real, dimension(nx,ny) :: T

    aspect = real(nx)/real(ny)
    L = H*aspect
    dx = L/real(nx)
    dy = H/real(ny)

    T = initialize_T()
    call evolve_field()

    contains

        function initialize_T() result(T)
            implicit none
            real, parameter :: sigma = 0.2
            integer i, j
            real x, y
            real, dimension(nx,ny) :: T
            do i=1, nx
                do j=1, ny
                    x = real(i)/real(nx)*L
                    y = real(j)/real(ny)*H
                    T(i,j) = 10. + &
                             2.* ( &
                                   1./(2.*3.14*sigma**2.) * &
                                   exp(-1. * ( (x-L/2.)**2. + (y-H/2.)**2. ) / (2.*sigma**2.)) &
                                 )
                enddo
            enddo
        end function initialize_T

        subroutine heat_eqn()
            implicit none
            real, dimension(nx,ny) :: Tn
            real d2Tdx2, d2Tdy2
            integer i, j

            Tn(:,:) = T(:,:)

            !$omp parallel shared(T) private(i,j,d2Tdx2,d2Tdy2) !$omp do
            do i=2, nx-1
                do j=2, ny-1            
                    d2Tdx2 = ( Tn(i+1,j) - 2.*Tn(i,j) + Tn(i-1,j) ) / dx**2.
                    d2Tdy2 = ( Tn(i,j+1) - 2.*Tn(i,j) + Tn(i,j-1) ) / dy**2.
                    T(i,j) =  Tn(i,j) + dt*(alpha*(d2Tdx2 + d2Tdy2))
                end do
            end do
            !$omp end do !$omp end parallel

            T(:, 1)  = T(:, 2)
            T(:, ny) = T(:, ny-1)
            T(1, :)  = T(2, :)
            T(nx, :) = T(nx-1, :)

        end subroutine heat_eqn

        subroutine evolve_field()
            implicit none
            integer ts, total_ts, frames_total, output_period_ts, pic_counter
            real progress_pct
            character(len=16) :: pic_counter_str

            total_ts = ceiling(physical_time/dt)
            frames_total = 30*20
            output_period_ts = int(total_ts/frames_total)

            pic_counter = 0

            do ts = 0, total_ts

                if (mod(ts,output_period_ts) .eq. 0) then

                    progress_pct = 100.*real(ts)/real(total_ts)
                    print '(I8, F7.2, A)', ts, progress_pct, "%"

                    !! -- for plotting

                    !open(3, file="T.dat", access="stream")
                    !write(3) T(:,:)
                    !close(3)

                    !write (pic_counter_str,'(I5.5)') pic_counter
                    !call system('gnuplot -c plot3d.gnu '//trim(pic_counter_str))
                    !pic_counter = pic_counter + 1

                end if

                ! -----

                call heat_eqn()

                ! -----

            end do

        end subroutine evolve_field

end program heat

Jak sugeruje evets w komentarzach, program ulega awarii z powodu braku pamięci stosu. Oznacza to, że utworzono zbyt wiele zbyt dużych tablic automatycznych (przydzielonych na stosie). Jako wskazówkę możesz uruchomić program w Valgrind

> gfortran -fopenmp heat.f90
> valgrind ./a.out

Przed wydrukowaniem wielu błędów „nieprawidłowego zapisu”, wyświetli coś takiego

==31723== Warning: client switching stacks?  SP change: 0x1ffefffbc0 --> 0x1ffecf2740
==31723==          to suppress, use: --max-stackframe=3200128 or greater

W przypadku braku pamięci stosu często pojawia się ostrzeżenie o „przełączaniu stosów klientów”.

W prawdziwym programie używałbyś allocatabletablic, które nie są sztucznie ograniczane. Jednak w tym prostym przypadku udało mi się uzyskać flagę -fno-automatic, która pozwala uniknąć użycia automatycznych (przydzielonych na stos) tablic, umieszczając je zamiast tego w innym rodzaju pamięci:

> gfortran -fno-automatic -fopenmp heat.f90
> ./a.out
       0   0.00%
     500   0.17%
    1000   0.33%
    1500   0.50%
...

Możesz przeczytać szczegóły na temat tej opcji na stronie podręcznika.

Uwaga: testowałem program w innej dystrybucji Linuksa (nie w Windows).