Inconsistent force field name parameter

[MakisH]

https://github.com/precice/openfoam-adapter/pull/236 introduced the ability to read forces. In that case, we needed to also read the name of the force field from the preciceDict.

Something that went under the radar in the review, though, was that this parameter is inconsistent with the rest. This comes from the perpendicular-flap/solid-solids4foam case:

FSI
{
    solverType solid;

    // Name of displacement fields
    namePointDisplacement pointD;
    nameCellDisplacement D;

    // Name of the force field on the solid
    forceFieldName solidForce;
}

and this comes from the solid-openfoam case:

FSI
{
    solverType solid;

    // Name of cell displacement field
    nameCellDisplacement D;

    // The solidDisplacementFoam does not have a point displacement field so we
    // we use the special name "unused", which tells the adapter that it is not
    // used
    namePointDisplacement unused;

    // Name of the force field on the solid
    forceFieldName solidForce;
}

TODO:

• [ ] Rename forceFieldName to nameForce. In the code, this is actually called nameSolidForce. Is this really specific to solids? @solids4foam
• [ ] Update documentation in https://precice.org/adapter-openfoam-config.html

[philipcardiff]

• [ ] Rename forceFieldName to nameForce. In the code, this is actually called nameSolidForce. Is this really specific to solids? @solids4foam

I guess this should not be specific to solids.

In this case, the Force class already stores a Foam::volVectorField* Force_; field which is created (and deleted) by the adapter. Ideally, this same force field could be used when the adapter is interacting with the solid; however, there are currently two impediments to this:

• The name of the Force_ field is hard-coded as Force. It would be an easy change to make this lookupOrDefault.
• The Force_ is created by the Force class, whereas the solidForce_ pointer points to an existing field from the solver, rather than creating its own field. Since Force_ and solidForce are both just raw pointers, I guess it would not be too difficult to merge their behaviour and have only one Force pointer, which could create a field or just point to an existing one.