Classification of subroutines to make rules more specific

[mlange05]

One of the common themes with several of the rules added for GPU-adaptation and source-to-source tool compliance is that they only pertain to subroutines that process NPROMA blocks, while others are targeted at routines that spawn parallel sections. This is closely aligned with the previous idea of "single column" format rules.

I propose to extend this idea to define clearly three initial classes of subroutines, using similar nomenclature used in the recent Arpege porting report:

• Control, Parallel or Driver - Control flow routine that spawn either one or several parallel regions over a list of blocks (either via OpenMP threads for CPU or offloaded for GPU).
• Vector, NPROMA or kernel - Computing routines that process a single block. The field data declared in these routines contains a single NPROMA block.
• Communication - Subroutines with inter-process communication via MPI, including packing and unpacking of messages.

Once we pick the initial three classifications, I propose to re-classify some of the L-rules into P|V|C rules, or other abbreviations as appropriate.

In the future we might extend this with rules for other classifications (eg. "setup" or "sequential").

[mlange05]

My personal preference for nomenclature would be PARALLEL | VECTOR | COMM, where "parallel" and "vector" are aligned with the Loki concept of "driver" and "kernel" respectively.