src/core_atmosphere/physics/physics_wrf/module_bl_gwdo.F

[pridley]

Hello,

it appears there are a couple of bugs in this file. These can cause problems at run-time when running with more than a single OpenMP thread. Please can someone take a look. The fixes are mentioned below.

The bugs are at lines 182 and 368.

At line 182, in the call to gwdo2d, dx is a 2-d array which is being passed to dxmeter which is a 1-d array, so the following

,dxmeter=dx,deltim=dt &

should be

,dxmeter=dx(ims,j),deltim=dt &

At line 368, in the subroutine gwdo2d the 1-d arrays cleff and dxmeter may have different bounds, so the following

cleff(its:ite) = dxmeter

should be

cleff(its:ite) = dxmeter(its:ite)

Thanks.

 

[mgduda]

Thanks so much for the bug report! It looks like we've found and addressed the second issue you pointed out with MPAS-Model PR #396, which will appear in the MPAS v7.1 release that I'm hoping will be released very soon. I'll take a second look at the first issue you pointed out (on L.182), and follow-up with a GitHub pull request as needed. Thanks, again (and on a side note, I see that you're the first person to post in the MPAS-Atmosphere Support < Bugs section of the forum!).

 

[mgduda]

I looked more closely at the dxmeter/dx argument issue. To recap, dx is declared as a 2-d array on L.106-106 of module_bl_gwdo.F

  real,   dimension( ims:ime, jms:jme )                                      , &
             intent(in  )   ::                                             dx

, and it's passed as a whole array as the actual argument to dxmeter on L.182 of module_bl_gwdo.F

              ,dxmeter=dx,deltim=dt                                            &

, with the dxmeter dummy argument declared as a 1-d array on L.274 of module_bl_gwdo.F

   real, dimension(ims:ime)          , intent(in   ) :: dxmeter

.

Although the code appears at first to be in error, the Fortran 2003 standard apparently has no problem with this; according to Section 12.4.1.5 of the Fortran 2003 standard:

18 An actual argument that represents an element sequence and corresponds to a dummy argument that is
19 an array is sequence associated with the dummy argument if the dummy argument is an explicit-shape
20 or assumed-size array. The rank and shape of the actual argument need not agree with the rank and
21 shape of the dummy argument, but the number of elements in the dummy argument shall not exceed
22 the number of elements in the element sequence of the actual argument. If the dummy argument is
23 assumed-size, the number of elements in the dummy argument is exactly the number of elements in the
24 element sequence.

Importantly, jms and jme are both declared as 1 in MPAS-Atmosphere on L.650 of mpas_atmphys_manager.F:

!initialization of physics dimensions to mimic a rectangular grid:
 ims=1   ; ime = nCellsSolve
 jms=1   ; jme=1
 kms=1   ; kme = nVertLevels+1

 

[pridley]

Thanks a lot for taking a look into this. I see what you mean but I came across this by using the

-fcheck=bounds

flag with gfortran, so there may not be enough information in the source for that compiler to determine the right part of the array

dx

to pass to the subroutine. E.g. it may not know that

 ims=1, jme=1

at the point of compilation.

That's really why I raised this, as it looks like it's a simple modification that would make this subroutine more robust.

 

[mgduda]

Which version of the GNU compilers are you using? I've been able to run without any problems using "-fbounds-check" with the GNU 11.1.0 compilers (and I recall having used earlier versions of the GNU compilers without hitting this issue when building with DEBUG=true).

In any case, I agree that the code as written isn't as clear as it could be, and we should probably fix this up.

 

[pridley]

Thanks for checking. It was GCC10.2.0, the issue at line 368 showed up at runtime as

Fortran runtime error: Array bound mismatch for dimension 1 of array 'cleff' (1888/15105)

Line 182 doesn't show up, so I understand that's a bit subjective.