Modern FORTRAN features of OSLO_AERO

[Ovewh]

I have been following the course by NRIS on modern FORTRAN and I'm trying to relate the information in the course with our code base.

• First question is on the vector/array syntax. In the old code oslo_aero code most of the array where initialized in do loops. If the modern vector syntax is used does that mean that this can be equivalent to some_vector(:,:) = 0.r_8 E.g from oslo_aero_opitcal_params.F90, Is actually the do loop to initialize the Nnatk here required?

    ! initialize concentration fields
    do i=0,nmodes
       do k=1,pver
          do icol=1,ncol
             Nnatk(icol,k,i)  = 0.0_r8
          end do
       end do
    end do
    do k=1,pver
       do icol=1,ncol
          n_aer(icol,k)     = 0.0_r8
       end do
    end do
    kalw(:,:,:,:)=0._r8
    be(:,:,:,:)=0._r8
    ke(:,:,:,:)=0._r8
    asym(:,:,:,:)=0._r8
    ssa(:,:,:,:)=0._r8

• Modern FORTRAN comes with a lot of nice intrinsic array functionality, e.g. packing, reshaping, matrix multiplication etc. So I guess a lot of what is now done in do loops could be done without loops using these intrinsic array functionality and make the code more readable. Is there any performance penalty to using the more modern features?
• Vectors/arrays can also be defined as pointers e,g real(r8), pointer, dimension(:,:,:) :: su what case is this needed compared just defining it as a standard vector? And what is the difference?

[gold2718]

Great questions, I will tackle the first one here. For the specific example above, replacing the loop with your suggested syntax is both (possibly) equivalent and has no performance penalty. I say possibly because the array might not be dimensioned as in the do bounds so a more correct translation is:

Nnatk(:ncol,:pver,:nmodes)  = 0.0_r8

and

n_aer(:ncol,:pver)     = 0.0_r8

although in most of our uses, you can safely skip the upper bound.
While this code is not a great place to learn best practice in modern Fortran coding (that version is coming), there are often cases where we would choose not to use the array intrinsics you mention. Compilers often produce code that is slower than explicit loops when implementing an array intrinsic. For instance, one we almost always avoid is the elemental subroutine or function. For some reason, these are almost always noticeably slower although they are easier to code and to maintain.

[gold2718]

The Fortran pointer needs a whole class to itself. They are both indispensable and something to be avoided as much as possible. A few small "points" about pointers:

• A variable which is declared as a pointer can be assigned to different memory locations (as long as that location is itself a pointer or has the target attribute). This cannot be done with ordinary variables; Their memory location is fixed upon creation or allocation (for allocatable variables).
• When memory is allocated to a pointer variable, it must be deallocated by hand (insert whole topic about pointers inside of Derived Data Type (DDT) objects here). Failure to do this consistently is both a source of memory leaks (forgot to deallocate) and a source of SEGFAULT errors (attempt to use a deallocated pointer).
• Array upper and lower bounds are treated very differently for dummy pointer arguments than for regular dummy arguments. This means one has to be careful in using dummy arrays with the pointer property.
• Because the memory location pointed to by a variable with the pointer argument can change at almost any time, many common performance optimizations CANNOT be performed on variables with the pointer attribute. This is the main reason to avoid them in parameterizations and dycores (where most of the compute time is spent).