Updating Boundary Conditions Each Iteration
 

Hello All,

I have a situation where I would like to calculate some boundary conditions from the internal field. The problem is that, for each time step, the boundary conditions should be iteratively updated as part of the solution. I have searched the forum and noticed that many people have recommended the groovyBC or swak4Foam add ons for recalculating a boundary condition from the flow field but these tools seem to do this at the end of a time step and not as part of the iterative process. Can I use one of these tools to somehow calculate the BCs iteratively?

Alternatively, I noticed there is a BC built into openFoam called calculated that might work but I can't really find too much information about this in the forum and the tutorials don't really make it clear to me exactly how it works.

Does anyone have any idea how I can iteratively calculate boundary conditions?

Regards,
Tom

I don't think groovyBC does iterative solutions. You may need to write your own boundary condition, and put the iterative solver into it. See

http://openfoamwiki.net/index.php/Ho...dary_condition

for an overview of writing new boundary conditions.

Hi Marupio,

Thanks for the reply and the link.

I was hoping that I wouldn't have to do that but I'll give it a try.

Best,
Tom

Hi thomas99,

As marupio said you could write your own boundary condition,

alternatively, you could just include a header file which updates the boundary contact inside your solver solution loop,
for example I sometimes use the "fixedGradient" boundary condition in my solid stress solver to apply a traction, this means I must update this fixedGradient every solution iteration.
The header file might look something like the following (where U is the volVectorField I solve for):

Hope it helps,
Philip

Depends on what you mean by iterative. groovyBC is recalculated every time other BCs are recalculated too (sol also in a loop inside the time-loop)

Forget this one. It means "I was calculated once, I won't change again. And I don't know if I'm Dirichlet or Neuman so I will behave like a Dirichlet"

Hi Philip and Bernhard,

Thanks for the information. I think the inclusion of a header file is a good idea and I'll try that first.

Regards,
Tom

Hi Tom,

Do you succeed in updating the boundary in the loop?
I want to update the boundary condition after each iteration for steady state calculation.
Thanks!

Wei

I'm not infront of my FOAM machine right now, but I seem to recall an issue where the boundary condition would update only once per timestep. I was doing multiple iterations per timestep, and I had to call some function to force it to update. I forget the details... but if you encounter the situation where it only seems to update once, then let me know, I'll dig for the answer.

-Dave

Hi Dave,

I am using the steady state solver, so I want to update the valure after each iteration.
Do you know about that?

Thanks!

Wei

Hi Philip,

What should I do if I used the fixedValue and want to update it?
Thanks!

Wei

Hi Wei,

For a fixedValue boundary condition, you can do the following (U is the volVectorField which is solved):
Note the double equal signs, this is how you set the value on a patch. You don't need to cast the patch if it is fixedValue.

Hope it helps,
Philip

Hi Philip,

Your suggestion is very helpful!

If I use U.boundaryField()[patchID] == vector(1,2,3) , the boundary would be uniform.
Can I use a loop to set non-uniform boundary conditions?
Besides, to set the new boundary, I have to make use of the velocity on the boundary face, velocity on the boundary cell and velocity gradient on the boundary cell. Do you know how to access these values?

Many thanks!

Wei

Hi Wei,

You can set non-uniform boundary values based on anything you want:
Best regards,
Philip

Hi Philip,

Thanks for your reply!
I will try it in my program to see how it is works!

Best Regards!

Wei

Hi Philip,

As far as I know, the U.boundaryField()[patchID].snGrad()[facei] returns the patch-normal gradient. How to obtain the velocity gradient on the patch cell, which is a tensor. Can I define a
tensorField gradU = fvc::grad(U),
then use the
tensor faceCellGradientU =
gradU.internalField()[mesh.boundaryMesh()[patchID].faceCells()[facei]];
to obtain the velocity gradient on the patch cell?

Many thanks!

Wei

Hi Philip,

Sorry to bother u again.
If I use

U.boundaryField()[patchID] == vector(0.8, 0, 0);

I could update the boundary condition;
But if I use

forAll(U.boundaryField()[patchID],i)
{
U.boundaryField()[patchID][i] == vector(0.8, 0, 0);
}

The boundary would not be updated.

Do you know the reason?

Thanks!

Wei

Hi Wei,

To answer your first question, to calculate the full gradient (tensor) at the boundary face you use the fvc::grad operator as you have shown:
tensor faceCellGradientU =
gradU.internalField()[mesh.boundaryMesh()[patchID].faceCells()[facei]];

However, be careful because most fvc::grad schemes do not calculate the total gradient fully at boundary faces, they essentially calculate the normal gradient like snGrad and then they set the tangential gradient to be the same as the tangential gradient at the centre of the boundary cell.

As regards the forAll loop not updating the boundary I am not sure but here is a work-around:
Also, did you try chaining the "==" to "=" inside the forAll loop?

Hi Philip,

You are right, I tried to change the "==" to "=" inside the forAll loop and it works.
In your code, you write "U.boundaryField()[patchID][i] == newPatchValues", is it U.boundaryField()[patchID]== newPatchValues? without the [i]?

Many thanks!

Wei

Yes, sorry that was a typo.

Best regards,
Philip

I have the following error when i try to compile the code for a scalar T:

DCP.C: In function ‘int main(int, char**)’:
DCP.C:75:66: error: no match for ‘operator[]’ (operand types are ‘Foam::tmp<Foam::Field<double> >’ and ‘Foam::label {aka int}’)
newPatchValues[i] = -T.boundaryField()[patchID].snGrad()[i];
^
make: *** [Make/linux64GccDPOpt/DCP.o] Error 1


any idea?

fvPatchField::snGrad() return a tmp copy of a scalarField (see OpenFOAM C++ doxygen documentation); so to get your code to compile, change this line:
to this:
However, I suggest that you store this snGrad field before you loop over each face, so as the entire patch snGrad would not be re-calculated for every faces, e.g. something like:
Philip

Thank you very much. I have some more questions.

1) If I need to perform mathematical operations (like log, exp, etc) to calculate new T from grad and old T. I have errors because of the different kind of variables. How can i solve it?

2) wich solver I have to select in order to verify the convergence of the BC?. Or the only change is modifying while (simple.correct Non Orthogonal())?

If you give the mathematics here that you are trying to implement and also your initial non-compiling implementation, then I can give you pointers on the implementation.

I'm not sure I understand your question; typically for verification, you find some benchmark (analytical or numerical) and compare your results.

Philip

could you please post some tutorials or web page?

I am learning from laplacianFoam in steady state (the easy way). My question it is not referred to verification, instead I want to know an easy way to control convergence when BC change after each iteration. In laplacianFoam, the new nonlinear BC iterate only a number of times given by: simple.correct Non Orthogonal() setting in fvSolution

hi Pillip,

Your posts on updating boundary condition on each iteration was very helpful to me. I am implementing a new solver using the icoFoam solver to handle the fluid-solid interaction (Vortex induced vibration). The vibration of the solid is taken into the account by assuming the fluid is in a non-inertial frame vibrate on opposite to the solid motion while the solid stay still. The solid motion due to the fluid forces are solve inside the solver and update the boundary condition accordingly in each iteration.

My question:

Since fluid is in a non-inertial frame the acceleration of the frame needs to add into the navier stokes equations. For that I defined a field variable ddy. This accelaration is a uniform value across the fluid. I can update the boundary condition as you said. Can you please tell me how to update the internal field as well? :( I have defined the internal field initially as a uniform value.

Many thanks,

Methma

Hi,

This is an old thread but am trying to do the same thing, so posting my doubt here.

I am using OpenFOAM 2.4.0 and using pisoFoam solver. I want to change the fixedGradient B.C at each time loop. So I followed what was suggested here:


dU_dy is some "double" variable for which I calculate something.

But I get this error:
"fixedGradientFvPatchVectorField’ was not declared in this scope"

Please suggest where am I going wrong. Thank you.

That's the technical wonder of Polymorphism at work: your source doesn't know the class but the executable does. Try including fixedGradientFvPatchFields.H

Hi Bernhard,

I have in included in myfile:

#include "fixedGradientFvPatchField.H"

Still am gettinhe the error. Just for your reference an pasting the start part of my file here. insertModification.H is where I am trying my thing.

Fields.H not Field.H. The "s" is important

Hi,

Can you post your code segment?

I think the problem is "snGrad()" returns a "tmp" of a field, so either you modify the code to be:
or a better solution (no need to re-generate the entire snGrad filed every iteration) would be to store the snGrad field:

Philip

Hi Bernhard,
It is working. Was indeed a spell typo. Thanks a lot for your help.


Hi Philip,
It seems the error was because of a typo. Here is a section of my code:

Hoping this will set the gradient calculated for each face on the concerned patch.
Thank you.

Hi,

I have a doubt related to my last post.

Problem is when I see the values in output, both values for before and after remain same. Here is a small section of the output

Thank you in advance.

You should not use the "==" operator; you should use the "=" operator to assign the face value.

The "==" operator is just necessary when assigning the value to an entire fixedValue-type boundary condition.

Philip

Hi Philip,

Thank you so much for the reply. I changed '==' to '=', then it gave me the following error:

A bit of searching and I found that declaring wallPatch as a 'const' was the problem. So I changed it to:

Now on printing, I see that the values are changing. Thanks a lot again for the reply.

Suman

Modified pisoFoam for pitzDaily - solver blowing up !!
 

Hi there,

Am having some problem in solving flow over backward facing step in OpenFOAM. I am using LES and Smagorinsky Model. At start it all goes well but after some time utau values at the wall starts increasing and the deltaT of simulation goes on decreasing (till if falls to 10^-12 or so order). I cannot detect what is the problem. I have modified the pisoFoam solver so impose stress boundary condition using the 'fixedGradient' feature of OpenFOAM.

Am attaching my required files here. Please have a look and suggest where am I going wrong. Will be waiting for a reply.

Attachment 51068

Attachment 51069

Hi there,

I think the problems are coming with the pressure solver settings. At t=0.01 pressure values are about -120 at the inlet and then increases linearly to close to zero at the outlet. But at T=0.05, it falls down to -4000 approx. Obviously in an incompressible flow, the absolute value of pressure does not matter, it is the gradient that matters. But what I am not understanding are such low values. Considering inlet velocity has a magnitude of 10 in the x direction (which is max amongst all 3 directions), a value of -50 to -70 may still be understandable but -4000, am not getting at all. Not understanding why the pressure field is behaving such. Maybe that is triggering the problem.

Hi,

Back again with an update on this same issue. So to start with, setting the gradient at the wall was not so much of a good idea it seems. Somehow the wall normal velocity was being calculated to be a non zero value at the wall. This might be one of the reasons for the solver to blow up in that manner. The modified code I am using now, uses fixedValue (0 0 0) as a boundary condition at the wall and in the modified solver, I calculate the velocity at the wall using the gradient and set the velocity. The solver now runs properly and does not blow up.

The only issue am facing with this is, the reynolds stress when calculated comes out to be very less; flow is not becoming turbulent only. Am wondering if it's an issue with the gradient schemes being used or not. If anyone has any views on this, it will be really helpful.

So the question is, what is the best gradient scheme to be used for solving incompressible turbulent flow (using LES) in openFOAM?

Sorry for maintaining two threads for the same topic. I will from now on post the updates on one particular thread itself:

Link: http://www.cfd-online.com/Forums/ope...tml#post623038

Dear Suman,
I have a similar problem, that is my piece of code
Commenting the last line
it compiles and the values stored in newPatchValues are correct, so it seems that the problem is in assigning a new bc value to Index. That is the error:

error: no match for ‘operator==’ (operand types are ‘const Foam::fvPatchField<double>’ and ‘Foam::scalarField {aka Foam::Field<double>}’)
Index[0][0].boundaryField()[patchi] == newPatchValues;

If I substitute with I have the following error
error: passing ‘const Foam::fvPatchField<double>’ as ‘this’ argument of ‘void Foam::fvPatchField<Type>::operator=(const Foam::UList<T>&) [with Type = double]’ discards qualifiers [-fpermissive]
Index[0][0].boundaryField()[patchi] = newPatchValues;

It seems to be the same problem as you, but I do not have any const!
Any idea?
Simone

Dear Philip,
I post here the same problem that I posted in an other thread since here it is older but seems more appropriate

...

I have a similar problem, that is my piece of code
Commenting the last line
it compiles and the values stored in newPatchValues are correct, so it seems that the problem is in assigning a new bc value to Index. That is the error:

error: no match for ‘operator==’ (operand types are ‘const Foam::fvPatchField<double>’ and ‘Foam::scalarField {aka Foam::Field<double>}’)
Index[0][0].boundaryField()[patchi] == newPatchValues;

If I substitute with I have the following error
error: passing ‘const Foam::fvPatchField<double>’ as ‘this’ argument of ‘void Foam::fvPatchField<Type>::operator=(const Foam::UList<T>&) [with Type = double]’ discards qualifiers [-fpermissive]
Index[0][0].boundaryField()[patchi] = newPatchValues;

It seems to be the same problem as you, but I do not have any const!
Any idea?
Simone

Hi Simone,

This error:
is saying that this 'Index[0][0].boundaryField()[patchi]' is const.

From this code:
it should not be const, and the code should compile; it compiles for me in foam-extend-32 (I would expect the same in other version too); of course I had to make some unrelated changes where I replace "yindex.size" with "1", "Np_[0]*(p - one_p*pmin_[0])/( one_p*pmax_[0] - one_p*pmin_[0] )" with "mag(U)", "this->pair_.phase1().time()" with "runTime" and "this->pair_.phase1().mesh()" with "mesh".

Are you sure this is the code you are compiling? did you, for example, post "simplified" code? If possible I would suggest making a very simple OpenFOAM utility that shows this compilation problem and then upload this for others to try.

Philip