For me personally this particular example from slide 8:
u_t = -(.grad.p)/rho + nu*(.laplacian.u) -(u.dot.(.grad.u))
looks similar to the equation in the text book at the high level, but I have no idea what is going on underneath, because it is hidden underneath the layers of derived types and overloaded operators. To maintain such code, fix bugs, improve performance, etc., one has to understand all the pieces and how they interact with each other. I personally prefer to explicitly expose all arrays and loops, such as here:
where you see all the arrays and all the operations and the loop corresponds directly to the mathematics derived in the corresponding paper, equations (79)-(82).
At first it might seem more complicated, but what you see is all the complexity there is to solving the equation on the grid. Nothing else is happening and it is only using Fortran primitives. So you can easily go in, and refactor it in any way you would like.
For a fair comparison, one should also include all the code needed to make the line u_t = -(.grad.p)/rho + nu*(.laplacian.u) -(u.dot.(.grad.u)) work, so all the derived types and the overloaded operators.
@milancurcic’s book has examples of both approaches.
This is an important topic and I would like to later work on more examples of this and have full working examples, using the OO approach as well as the direct approach.
The OO style is more like using a framework, such as MOOSE, deal.II, libmesh or mfem. If you look at any of their examples, such as here, you have to understand the framework to know what is going on. It takes time. The libmesh’s style example is more readable at the lowest level, so I like that more. It could be that mfem is doing more complicated parallelization and mesh handling under the hood, so they had to do it the way they did. Either way, with these large frameworks it always takes time to get into it and understand what is going on and how to improve things. It’s probably inevitable. But many times it is possible to write code, such as the dftatom atomic solver above, that is not written as a framework, but rather uses Fortran primitives directly, and if the engineering problem that I am trying to solve allows that approach, I personally always prefer it.