Remove USE Messages from MODULE Types

[BenjaminRodenberg]

Remove implicit re-export of Messages through Types module and add explicit USE Messages, ONLY: <symbols> to all affected files. This clarifies dependencies and prepares for upcoming YAC coupling integration, which would otherwise create a circular dependency (Messages -> elmer_coupling -> Types -> Messages).

See BenjaminRodenberg#1 for an example where the circular dependency caused problems. BenjaminRodenberg#1 is a draft for #723.

[BenjaminRodenberg]

Please let me know if you expect a specific kind of ordering for imports. I first wanted to make sure this change goes in the right direction before taking care of such details. Hope this is ok.

[BenjaminRodenberg]

Not sure if this could cause trouble on the user side? CompressibleNS.F90, for example uses DefUtils. I could also add a DefUtilsWrapper.F90 similar to TypesWrapper.F90 but would happier to not do this.

I need this change since otherwise my code in BenjaminRodenberg#1 will not compile due to this part:

  USE DefUtils, ONLY: ParEnv, GetSolverParams, GetString, GetMesh, GetNOFActive, DefaultVariableAdd
  USE SolverUtils
  USE elmer_coupling, ONLY: coupling_setup, is_main_rank
  USE elmer_ebfm_coupling, ONLY: elmer_ebfm_interface, t_ice_field, smb_field, &
                                 runoff_field
  ! USE elmer_icon_coupling, ONLY: elmer_icon_interface, clt_field

DefUtils implicitly imports Messages if using Types.Fatal from Messages calls coupling_finalize. This conflicts with importing elmer_coupling since it also relies on Types and we get the circular dependency.

[BenjaminRodenberg]

To mimic the changes from BenjaminRodenberg#1 that motivate this PR I added the following part here:

diff --git a/fem/src/Messages.F90 b/fem/src/Messages.F90
index 8a547b297..d22c71642 100644
--- a/fem/src/Messages.F90
+++ b/fem/src/Messages.F90
@@ -55,6 +55,8 @@ MODULE Messages
   USE XIOS
 #endif
 
+   USE Types_  ! Check for circular dependencies
+
    IMPLICIT NONE
    
    CHARACTER(LEN=512) :: Message = ' '

When trying to build this modified version I also had to change the build order (see 18cd4fb). But this was generally quite hard to reproduce and I think this problem also only shows up if building with -DCMAKE_BUILD_TYPE=DEBUG. It might also be due to a race condition with parallel builds...

[BenjaminRodenberg]

After going a bit back and forth I'm reaching a point in this PR where things could be merged.

The main open question is whether a wrapper module Types should be introduced for backwards compatibility. Without this module, tests will fail at the moment because some also rely on implicitly importing subroutines from Messages which were remove from the original Types (which is renamed to Types_ here).

I'm not a big fan of providing such a wrapper module because it supports an anti-pattern. I would rather push users to explicitly USE Messages. It's hard to judge from my perspective whether this is considered a breaking change or a bugfix.

I think it generally does not harm to explicitly import the subroutines from Messages so I kept this part.

Note: The build order was no problem and due to a misconfiguration of my build workflow.

[BenjaminRodenberg]

This is not possible if Types_ (formerly Types) already includes Messages.

USE :: Types_, ONLY: Mesh_t, Element_t, dp is needed by MODULE elmer_coupling imported in Messages (BenjaminRodenberg#1).

[BenjaminRodenberg]

Explicitly importing Messages is needed if using Types_ (without Messages) instead of Types.

[BenjaminRodenberg]

I squashed most commits in this PR. 1c826ce is only for testing and should be reverted before the merge.

[BenjaminRodenberg]

Discussed this with @tzwinger. Here is a summary about the current status of this PR from my side:

• The alternative solution provided on the branch SeraparateMessagesModule works for me. I tested the integration on my fork on the branch yac-coupling-no-Wrapper.
• I had to move some functionality around in Allow user to configure source coordinate reference system #783. This also allowed me to remove the import of Types from my code and I do not run into the cyclic dependency anymore if USE Messages is called inside Types. I still think that the way how Messages is imported implicitly at the moment is not ideal and limits flexibility. From that perspective it's good if this is changed - but the current state is also not problematic anymore.

I would suggest to close this PR in favor of the changes on SeraparateMessagesModule. If we want to change something about how Types and Messages are imported this would rather be moving into the direction of SeraparateMessagesModule.

[raback]

I merged this branch to "devel" so everything should be ok
https://github.com/ElmerCSC/elmerfem/tree/SeraparateMessagesModule
Note that I did a squash to combine the 7 baby steps so rather merge to devel than this.
I will close this PR since to my understanding it is no longer needed.