Added compatibility with multiphase solvers

[fronterapp]

For multiphase simulations, the user must specify two new coefficients: 'multiPhase' (bool, true means multi-phase solver is used) and 'phaseName' (word, only needed if multiPhase is true, should correspond to the main phase name - usually air- as defined in the 'transportProperties' dictionary). This is done to pick the correct value for kinematic viscosity.

This commit is meant to serve as the initial commit for a 'floatingTurbine' branch. As part of my MSc thesis, some modifications are made to the original library to make it compatible with the 6-DoF motion characterizing floating wind turbines (FWTs). The final goal is that the AL turbine can be used in multiphase simulations, where waves2Foam will be used for wave generation and absorption. Both libraries need to be coupled together and, at the same time, to the rigid body solver for the floating turbine motion. The tool resulting from the project should have the potential to be validated and expanded to serve as a reliable technique for the advanced modelling of FWTs.

[petebachant]

Is this actually necessary to define in the fvOptions or can we get at this information implicitly? I've done some preliminary testing with the library in multiphase flows, and I thought it worked as-is, in terms of getting the actuator line elements to use the local density for computing the force. Perhaps I'm missing where this will be used, however.

[fronterapp]

Sorry, I think that I was not clear enough about the purpose of the commit. The goal is to access the kinematic viscosity which will then be used to compute the Reynolds number in actuatorLineElement.C. In single-phase simulations, this constant is stored in the transportProperties dictionary (with the nu keyword). But for multiphase flows, the latter contains multiple subdictionaries corresponding to each phase. Thus, the user must specify in fvOptions which phase to get the kinematic viscosity from (e.g. air).

Of course, I would also prefer the user not to have to define this in fvOptions. The ideal would be to access the fluid fractions (alpha) at the AL element position and use those to compute a weighted average of the kinematic viscosity. However, I do not know how to access the alpha field from within the library. Would you come to a different solution or implementation, please let me know!

[petebachant]

FYI, the style check is failing in Travis CI:

[petebachant]

The ideal would be to access the fluid fractions (alpha) at the AL element position and use those to compute a weighted average of the kinematic viscosity. However, I do not know how to access the alpha field from within the library. Would you come to a different solution or implementation, please let me know!

It sounds like it should be possible. alpha may be passed in to the addSup method for multiphase fvOptions.

[fronterapp]

FYI, the style check is failing in Travis CI:

My apologies, I did not know about Travis CI at all and to be honest, neither was I following OF's style guidelines. Do you think this style guide from openfoam.org suffices?

[petebachant]

The built-in formatter in VS Code may do the trick: https://code.visualstudio.com/docs/cpp/cpp-ide#:~:text=The%20C%2FC%2B%2B%20extension%20for%20Visual%20Studio%20Code%20supports%20source,in%20right%2Dclick%20context%20menu.

Otherwise, the error messages give the instructions: Lines should be shorter than 80 characters and if should be followed by a space or new line. These should be consistent with the OpenFOAM style guide.