Includes and suffixes

[luflarois]

I have 3 questions:

1. Why the MPAS code is using "includes" instead of modules? For example, looking at the code mpas_derived_types.F we see:

#include "mpas_attlist_types.inc"

#include "mpas_hash_types.inc"

#include "mpas_dmpar_types.inc"

#include "mpas_field_types.inc"

Wouldn't construction be better with the use of modules/use? Why not?

2. Why it uses "#include" instead of "include"?

3. Why the fortran suffix is ". F" instead of ". F90"? Most editors like VSCode, Eclipse (Photran) understand the code with ". F" as Fortran Fixed Form. The photran refactoring function (for example) does not work well with the suffix". F".

 

[mgduda]

1. In general, we do use modules throughout the MPAS source code; in fact, mpas_derived_types.F is a module. The use of include statements in mpas_derived_types.F is simply a convenience to allow us to keep derived type definitions associated with specific parts of the model infrastructure confined to their own files while still making all definitions available through a single module. Note that there are some dependencies among derived types (you can grep for the word 'import' in the *.inc files in the src/framework directory), and I think our motivation was to avoid having to track these dependencies in the case where each set of derived types had its own module.

2. The use of #include allows us to define preprocessing macros at the top of a module, and to have those macros be expanded in any included code. For example:

#define COMMA ,
#define DEBUG_PRINT(mesg) write(0,*) mesg

program main

real :: x = 3.141592

#include "code.inc"

end program main

with the "code.inc" file containing

x = 2.71828
DEBUG_PRINT('Current value of x is ' COMMA x)

In the case of the mpas_derived_types.F file specifically, we could have used Fortran 'include' statements; but I suppose we didn't see a good reason to not use preprocessing includes at the time of writing.

3. I think there are good arguments for switching to .F90 as the file suffix, and indeed, we may do this in a future release of the code.

 

[luflarois]

1. In general, we do use modules throughout the MPAS source code; in fact, mpas_derived_types.F is a module. The use of include statements in mpas_derived_types.F is simply a convenience to allow us to keep derived type definitions associated with specific parts of the model infrastructure confined to their own files while still making all definitions available through a single module. Note that there are some dependencies among derived types (you can grep for the word 'import' in the *.inc files in the src/framework directory), and I think our motivation was to avoid having to track these dependencies in the case where each set of derived types had its own module.

2. The use of #include allows us to define preprocessing macros at the top of a module, and to have those macros be expanded in any included code. For example:

#define COMMA ,
#define DEBUG_PRINT(mesg) write(0,*) mesg

program main

real :: x = 3.141592

#include "code.inc"

end program main

with the "code.inc" file containing

x = 2.71828
DEBUG_PRINT('Current value of x is ' COMMA x)

In the case of the mpas_derived_types.F file specifically, we could have used Fortran 'include' statements; but I suppose we didn't see a good reason to not use preprocessing includes at the time of writing.

3. I think there are good arguments for switching to .F90 as the file suffix, and indeed, we may do this in a future release of the code.

Thank you for your reply. We are studying to use the dynamic core of MPAS (and perhaps part of the physics - to be studied) for our new MONAN model. We have a defined code patterns. Thus, to use MPAS as a basis, we will have to make the appropriate adaptations and refactorings. My questioning helps us understand whether part of the coding practice used in MPAS could be leveraged. Thanks again for the reply.