[schröder]

Dear Foamers,
what is the recommended way to implement a boundary condition that affects more than one field?

For example, the surface of a melting ice block in seawater. At the same time, the temperature inside and outside, the boundary velocity, the water velocity and the salt concentration must converge.

The existing boundary conditions that I have studied, only solve for one quantity (e.g. p) and take other quantities (e.g. U) as given. This may be possible in solvers, where an inner iteration brings the boundary conditions to convergence. But the melting ice example is highly nonlinear, so that many inner iterations are required, at best supported by an appropriate Newton method. I see a problem, if such a boundary condition is used in one of the standard solvers, which does not allow to iterate the specific (water-ice) boundary to convergence.

My idea is to implement such a water-ice boundary ("wiBC"), which solves all involved boundary fields at once and iterates them until convergence of all boundary conditions. I would assign each p,T,U and cs (salt concentration) each with "type wiBC" and determine the "role" (pressure, concentration etc.) of each field by its units. Probably only one of the fields (e.g. T) may actually update the boundary values, whereas the other fields would know that they rely on T and they do nothing, when their update-method is executed.

Is this approach reasonable? I see a few problems.
The "active" boundary field (T) must get non-const access to the other boundary fields, because it performs the actual updates - this seems to be possible.
Secondly, the "wiBC" boundaries must be updated in the correct moment between the pEqn, UEqn, EEqn and transport equations. I don't know how I can make sure e.g. that the pEqn uses the correct velocity boundary values if the velocity boundary is written during the update of the "active" T field, which happens in the EEqn.

You could help me with an example of such a highly nonlinear simultaneous solution of several fields at the same boundary, or with a short explanation how to use the standard method providing individual boundary types for p,T,U,cs and using a custom iteration for a specific boundary in standard solvers.

Thank you
Martin

[ssss]

I don't think that you could do this in OpenFOAM. And if it is possible then it would be a pain in the ass to develop it.

You could just use groovyBC to introduce difficult boundary conditions + PIMPLE algorithm with a lot of outerCorrectores, to ensure a good temporal convergence.

[Sören Sander]

Hi Martin,

you can access and overwrite boundaries at any point in your code using something like

const fvPatchList& patches = mesh.boundary();

forAll (patches, patchi)
{

    const fvPatch& currPatch = patches[patchi];

    forAll (currPatch, faceI)
    {

        label faceCelli = myCurrPatch.faceCells()[faceI];

        //Do your stuff

    }

}

[schröder]

Thank you, ssss and Sören,
my question is not so much about the details of the implementation, but rather about the general organization inside the newly implemented boundary conditions: does it make sense that one boundary field is responsible for updating other boundary fields? what if e.g. T wants to update cs in the first time step, but cs is not yet initialized? how to get the correct ordering of pEqn, UEqn, TEqn and boundary condition update?

I would like to hear from experienced openfoam-users/developers why my approach might be wrong - in this case I would have to rewrite the standard solvers with an additional inner loop to handle the specific boundary conditions that link several fields together.

Technically, it is not that difficult to implement this. Done it, and it was no pain in the ass. However, I am making assumptions on the standard solver, which uses my "wiBC", so the the boundary condition loses generality, which I think is far from ideal.

Thank you
Martin