|
[Sponsors] |
several fields modified by single boundary condition |
|
LinkBack | Thread Tools | Search this Thread | Display Modes |
April 20, 2015, 05:06 |
several fields modified by single boundary condition
|
#1 |
New Member
Martin S.
Join Date: Apr 2015
Posts: 9
Rep Power: 11 |
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 |
|
April 20, 2015, 15:06 |
|
#2 |
Senior Member
anonymous
Join Date: Aug 2014
Posts: 205
Rep Power: 13 |
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. |
|
April 21, 2015, 04:11 |
|
#3 |
Member
Sören Sander
Join Date: Sep 2012
Location: Germany
Posts: 43
Rep Power: 14 |
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 } } |
|
April 21, 2015, 06:09 |
|
#4 |
New Member
Martin S.
Join Date: Apr 2015
Posts: 9
Rep Power: 11 |
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 |
|
Thread Tools | Search this Thread |
Display Modes | |
|
|
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 |