[DOMaier]

Hi all,

i'm having a problem with the way bc are handled in OF:

I develop a solver that has two levels of iteration. I need the bc to be updated only inside the outer level.

When initializing a fvMatrix the bc are automatically updated. this is not too much of an issue since i can initialize the matrix in the outer loop and add in the terms that get updated in the inner loop afterwards.
During the initialization the updated_ flag is set to true, so the update doesnt happen again in the inner loop in the first iteration.

However, during the call to fvMatrix::solve() the updated_ flag is set to false (by a call to fvPatch::evaluate()) so from the second inner iteration onwords the bc gets updated each time i add in the updated coeffs into the fvMatrix.

Is there any way to handle the resetting of the updated_ flag manually in the solver code and deactivate the "automatic" resetting inside the solve-method?

[dlahaye]

Could you please explain further?

You say that "When initializing a fvMatrix the bc are automatically updated." Is this your code or default OpenFoam code? What do you mean by "initializing a fvMatrix"? Allocating memory? Setting its values? What do you mean by "bc are updated"? Do bc's for field1 depend on field2? What kind of bc's are you considering?

You say that fvMatrix::solve() has an update_flag. Again, is this your code or standard OpenFoam. In case of the latter, could you pls. point to the source?

Thanks. Best wishes, Domenico.

[DOMaier]

HiDomenico, thank you for your interest in my problem.


With initializing a fvMatrix I mean for example:
fvScalarMatrix pEqn
(
fvm::laplacian(p) + divDivUU
);
in potentialFoam. When calling the constructor for the fvScalarMatrix (fvMatrix<scalar> class) in this way the boundary conditions will be evaluated.


When calling pEqn.solve later on, the boundary conditions will be evaluated again, and the updated_ flag is reset to "false".



the updated_ flag is a bool held by the fvPatch class and is changed by it depending on when certain methods are called.



All three are standard Openfoam implementations.


Now, I am implementing a linearization scheme for a nonlinear parabolic equation which has multiple levels of iteration. My boundary condition is a mixed (Dirichlet/Neumann) condition with mixing weights depending on the values of the field.

I want the mixing weights to be recalculated only in the outermost iteration-loop.

But because OpenFoam implementations of the fvMatrix constructor and the "solve()" method the boundary conditions are updated each time i solve the (now linearized) equation. This happens in the innermost loop..


I hope that clearifies your questions. If anything is still unclear, I'm happy to dive in even further.


Greetings

[dlahaye]

You lost me in translation, I am afraid to say.

The same partial differential equation for a field like p can have various boundary conditions. The differential equation and the boundary conditions are two legs of the same horse. By specifying the equation only, the boundary conditions are left unspecified. The boundary conditions cannot be specified by merely specifying

fvScalarMatrix pEqn
(
fvm::laplacian(p) + divDivUU
);

If suffices to look at the source code of https://github.com/OpenFOAM/OpenFOAM...aplacianFoam.C or https://github.com/OpenFOAM/OpenFOAM...otentialFoam.C to see seperate instructions for equation and boundary conditions.

Please elaborate further. I am happy to help.

[DOMaier]

I'm aware that the equation and the boundary conditions are mathematically independent from each other until specified as a set of equations.


However when the the linear system (the matrix) is built the boundary conditions are accounted for as source terms and matrix coefficients. These terms might be dependent on the solution, so the functions i was mentioning are recalculating the coefficients at certain times during the calculation.



I want the coefficients and source terms that come from the B.C. to be constant until i tell the solver to update them.



What i was saying earlier is that the OpenFoam code calculates the coefficients and source terms for the B.C. already by specifying the equation. The code snippet "fvScalarMatrix pEqn(fvm::laplacian(p) + divDivUU);" internally looks up what BC are supplied and puts the values in the right spot in the matrix.

[dlahaye]

I tend to disagree.

There is nothing in fvm::laplacian() that takes boundary conditions into account. See source code or book of Moukalled-Darwish-Mangani.

Boundary conditions are taken into account using internalCoeffs() and boundaryCoeffs(). See L311-L323 of https://github.com/OpenFOAM/OpenFOAM...rix/fvMatrix.H

Boundary conditions are updated using seperate functions. See Chapter 18 of Moukalled-Darwish-Mangani. This should make your case easy to solve.

Good luck.

[DOMaier]

Thank you Dominico for helping me clarify my problem.


I don't think that the call to fvm::laplacian() is responsible for the update of the BC i think

I went into the source code to find the code that's causing my problems:


In the constructor of fvMatrix https://github.com/OpenFOAM/OpenFOAM...rix/fvMatrix.C

Line 333 -> there is a call to psi_.boundaryFieldRef().updateCoeffs();
That is exactly the method in fvPatch that updates the coeffs that i want to keep constant.
This constructor is called everytime I create a new fvMatrix: even if i just take a preexisting one and just add e.g. (ddt(*,*) == pEqn) or something like that.


then in https://github.com/OpenFOAM/OpenFOAM...vMatrixSolve.C in the solve() method (line 57 to 100) it either calls solveSegregated() or solveCoupled(). It doesn't really matter which one is chosen (both do the same for the sake of what i try to convey) so we should follow solveSegregated().


In solveSegregated() in line 211 there is the call to psi_.correctBoundaryConditions()
Thats the main problem that im facing. This call is recalculating the boundaryCoeffs and is resetting the updated_ flag in fvPatch..



It seems like there is no way around that behavior other than implementing my own version of fvMatrix and commenting out the two lines in order to call the correctBoundaryConditions() method myself from where i want it in the main code..

[dlahaye]

I still do not understand your problem as much as I would like to.

In your inner loop, you want to solve differential equation plus boundary conditions.

The lines of codes you refer to merely enforce the boundary conditions. The updating of the boundary conditions is done using correctBoundaryConditions(). As long as you do not update the boundary conditions, the same boundary conditions will be enforced. This is exactly what you want.

Can you try using a small example?

Cheers, Domenico.

[DOMaier]

Let's check my understanding on how boundary conditions are updated:


When implementing a boundary condition on Openfoam I base off of a basic type (in my case mixedFvPatchField. Then I re-implement either the evaluate() or the updateCoeffs() methods in the new class (these are virtual functions in the base class). Usually updateCoeffs() is used (so is done in the book of Moukalled-Darwish-Mangani you mentioned).
This is the exact function that is called by the constructor of fvMatrix in the line 333 of fvMatrix.C.


Also you mentioned that a call to the fields method correctBoundaryConditions() is used to update the boundary condition. This is the exact function used in solveSegregated() and solveCoupled() in line 211 of fvMatrixSolve.C



On a side note:

Internally correctBoundaryConditions() calls the evaluate() instead of the updateCoeffs() function of the implemented boundary condition. I do not know if that's standard but in mixedFvPachField.C the evaluate() function calls the updateCoeffs() function (https://github.com/OpenFOAM/OpenFOAM...FvPatchField.C L144), leading again to an update of the weights for mixing and therefore the coeffs that i try to keep constant..


Nevertheless, since solve() internally calls correctBoundaryConditions() the B.C. will be corrected every time the solve() function gets called. this logically has to be within the inner loop.


I hope I am mistaken at some point of this reasoning but can't find a/the mistake myself.

[DOMaier]

I think if that last call of correctBoundaryConditions() inside the solve() method wasn't called and instead the updateCoeffs() method as done in the constructor in fvMatrix.C it would be fine.


One could implement a boundary condition that is implicitly updated by the fvMatrix object by specifying updateCoeffs(). For all boundary conditions that should only be updated when specifically calling correctBoundaryConditions() one would implement the evaluate() function.
I think that's also the behaviour you are expecting.

[dlahaye]

Apologies for the delay in the reply.

Please note that line 333 in fvMatrix.C (https://github.com/OpenFOAM/OpenFOAM...rix/fvMatrix.C) updates boundaryFieldRef() rather then the internal and boundary coefficients.