Refactoring of the fluid-structure interaction input sections

[georghammerl]

Many parameters in the FSI input sections need expert knowledge to be filled properly.
@ischeider, @mayrmt, and @georghammerl discussed how to improve the situation.

Please find the following base for discussion how to rename/cluster the parameters (in combination with some variants to be proposed for deletion):

PROBLEM TYPE:
  PROBLEMTYPE: Fluid_Structure_interaction (default) | Fluid_Structure_interaction_XFEM

FSI DYNAMIC:
  COUPALGORITHM: partitioned (default) | monolithic | xfem
  COUPMETHOD: conforming (default) | 
                 non-conforming-using-mortar | 
                 immersed --> proposed for deletion

FSI DYNAMIC/PARTITIONED
  ALGORITHM:	AITKEN_rel_param (default) |
                                fixed_rel_param |
				MFNK_FD |
				MFNK_FSI |
				MPE | --> proposed for deletion
				NLCG | --> proposed for deletion
				RRE | --> proposed for deletion
				steep_desc --> proposed for deletion
  SEQUENCE: fluidsolid (default) | solidfluid
  COUPLING VARIABLE: displacement | velocity | force 
  (only certain combinations of SEQUENCE and COUPLING VARIABLE are valid?!)

FSI DYNAMIC/MONOLITHIC
  SLAVE: solid (default) | fluid (better name instead of SLAVE tbd)
  PARAMETER1: normal | fluidfluid | mortar | sliding (maybe: COUPMETHOD)
  PARAMETER2: none | nonox | saddlepoint (maybe: BLOCK_STRUCTURE)

The latter two parameters need to be further investigated as several monolithic coupling algorithms are also proposed for deletion, namely:

iter_fluidfluid_monolithicfluidsplit_nonox
iter_fluidfluid_monolithicstructuresplit_nonox
iter_sliding_monolithicfluidsplit
iter_sliding_monolithicstructuresplit

The coupling algorithms which should definitely be kept are:

iter_mortar_monolithicstructuresplit --> standard case
iter_mortar_monolithicfluidsplit --> standard case
iter_monolithicfluidsplit --> special case of mortar_mono_fs, maybe unify Adapter::Coupling
iter_monolithicstructuresplit --> special case of mortar_mono_ss, maybe unify Adapter::Coupling
iter_mortar_monolithicfluidsplit_saddlepoint --> current research

and the following two coupling algorithms need further investigation after the important ones are migrated to the new solid time integration:

iter_fluidfluid_monolithicfluidsplit
iter_fluidfluid_monolithicstructuresplit

Interested parties

@maxfirmbach

[mayrmt]

A thought on partitioned algorithms: AITKEN_rel_param and fixed_rel_param could be combined into one coupling algorithm, since they both rely on a fixed-point iteration with a relaxation parameter. The only difference is the choice of relaxation parameter, which could be moved to its own input parameter RELAX_PARAM_STRATEGY = {Aitken, fixed}.

[ischeider]

I came across all these (at least in my opinion) unintuitive parameters when trying to rewrite/extend the FSI tutorial. I think there is room for a much cleaner input file, which can then be read intuitively with respect to the FSI controls.

The parameter name non-conforming-using-mortar seems a bit long, maybe "mortar" is sufficient?