CFD Online Logo CFD Online URL
www.cfd-online.com
[Sponsors]
Home > Forums > Software User Forums > OpenFOAM > OpenFOAM Programming & Development

several fields modified by single boundary condition

Register Blogs Members List Search Today's Posts Mark Forums Read

Like Tree2Likes
  • 1 Post By ssss
  • 1 Post By Sören Sander

Reply
 
LinkBack Thread Tools Search this Thread Display Modes
Old   April 20, 2015, 05:06
Default several fields modified by single boundary condition
  #1
New Member
 
Martin S.
Join Date: Apr 2015
Posts: 9
Rep Power: 11
schröder is on a distinguished road
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
schröder is offline   Reply With Quote

Old   April 20, 2015, 15:06
Default
  #2
Senior Member
 
anonymous
Join Date: Aug 2014
Posts: 205
Rep Power: 13
ssss is on a distinguished road
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.
Kummi likes this.
ssss is offline   Reply With Quote

Old   April 21, 2015, 04:11
Default
  #3
Member
 
Sören Sander
Join Date: Sep 2012
Location: Germany
Posts: 43
Rep Power: 14
Sören Sander is on a distinguished road
Hi Martin,

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

const fvPatchList& patches = mesh.boundary();

Code:
forAll (patches, patchi)
{

    const fvPatch& currPatch = patches[patchi];

    forAll (currPatch, faceI)
    {

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

        //Do your stuff

    }

}
Kummi likes this.
Sören Sander is offline   Reply With Quote

Old   April 21, 2015, 06:09
Default
  #4
New Member
 
Martin S.
Join Date: Apr 2015
Posts: 9
Rep Power: 11
schröder is on a distinguished road
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
schröder is offline   Reply With Quote

Reply

Thread Tools Search this Thread
Search this Thread:

Advanced Search
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are Off
Pingbacks are On
Refbacks are On


Similar Threads
Thread Thread Starter Forum Replies Last Post
Wind turbine simulation Saturn CFX 60 July 17, 2024 06:45
An error has occurred in cfx5solve: volo87 CFX 5 June 14, 2013 18:44
CFX fails to calculate a diffuser pipe flow shenying0710 CFX 7 March 26, 2013 05:13
External Radiation Boundary Condition for Grid Interface CFD XUE FLUENT 0 July 9, 2010 03:53
External Radiation Boundary Condition (Two sided wall), Grid Interface CFD XUE FLUENT 0 July 8, 2010 07:49


All times are GMT -4. The time now is 13:14.