OF ignores relaxation factor
 

Hi foamers,

I'm calculation temperature fields (steady-state) using laplacianFoam. Now I need to force under-relaxation in order to obtain convergence - but OpenFoam does not consider the relexation factor I define in fvSolution by

relaxationFactors
{
T 0.7;
}

What could be wrong?

Regards
Hugo

there is no call to the relaxation function in laplacianFoam

This function needs to be called and will then read the relaxationfactor from the dictionary.

But why do you need relaxation for this simple diffusion equation?

The main problem is that (unless you have a different laplacianFoam than I have) that laplacianFoam doesn't DO any relaxation.

In general: if you're unsure whether your relaxationFactor is being read replace it with an x (or your name). If the solver fails, then you're sure that it is being read

Relaxation in laplacianFoam
 

Thank you very much for your remarks!

I have got a groovyBC which calculates the gradient depending on the wall temperature (simulating steady-state heat flow through an insulation which is beyond the OpenFOAM domain). When this "virtual" insulation is relatively thin, huge temperature gradients occure at the boundary - and convergence is not reached.

Thus, I think that under-relaxation should allow convergence. Is it difficult to add relaxation to the laplacianFoam solver? Which solver is the simplest one with relaxation which I can use as an example?

Regards
Hugo

Instead of

solve( <the eqn >);

write

fvScalarMatrix TEqn( < the eqn >);
TEqn.relax();
TEqn.solve();

Thank you so much, Bernhard. I created own_laplacianFoam including the following algorithm:

for (int nonOrth=0; nonOrth<=simple.nNonOrthCorr(); nonOrth++)
{
fvScalarMatrix TEqn
(
fvm::ddt(T) - fvm::laplacian(DT, T)
);
TEqn.relax();
TEqn.solve();
}

Unfortunately, the relaxation factor is still not read. Do you have any idea?

Regards
Hugo

How do you know that it is "not read" (because there is always the possibility that you're not using the binary that you compiled or that you mistyped the dictionary entry)?

Or do you mean "is rad but has no effect"?

Your are right - actually, it does not have any effect, but it's read.

I checked if I'm using the right binary by adding a message output to own_laplacianFoam - it is displayed when I run the solver.

My entry in fvSolution is

relaxationFactors
{
T 0;
}

and if I change "0" to "b", I get an error - hence, it is read. But what could be the reason that the relaxationFactor is not taken into account by the solver?

Please specify "does not have any effect".

Or, in other words: your relaxation parameter would give a super-stable solution: nothing changes at all (as the new solution would not be considered)

1. After 10 iteration steps, the results are identical both with relaxation factor 0 and 1 - but different from the results after one step (but with the factor 0 considered, the results after all iteration steps would be the same if I understand it in the right way)

2. During calculation, the output is "Initial residual = 1" for time=1, "Initial residual = 0.75..." for time =2 and so on both with relaxation factor 0 and 1 - but I expect the initial residual remaining 1 for every time step when the relaxation factor 0 is considered?

Hi,

I have the same problem. In my PIMPLE-based solver I try to relax the TEqn. In the outer iteration cycle I have: and in the system/fvSolution I added a subDict:The value of x is being read, but doesn't change anything. All residuals remain exactly the same in each iteration, no matter if x==0.1 or x==1. What am I doing wrong? :)

Best regards,
Illya

I had similar problems in 2.0.x.

It seems that for incompressible flow the relxation factors are specified as:
relaxationFactors
{
p 0.3;
U 0.7;
}

while in multiphase they must be specified:
relaxationFactors
{
"p.*" 0.3;
"U.*" 0.7;
}

You can add some info statements before and after UEqn.relax() to check that your code is indeed finding the relaxation factors. (Or just hard code using UEqn.relax(0.7) )

It looks like 2.1 has changed the format to
relaxationFactors
{
fields
{
"p.*" 0.3;
}
equations
{
"U.*" 0.7;
}
}

So good luck finding your answer.

No need to change the solver. Just replace the relaxation factor with "x" (or your name). If the solver fails ("not a scalar" or something like this) then the factor is read

That trick only checks that the value is getting read in right, not that its actually getting used properly inside the solver.
For instance, it won't tell you if you put a relaxation factor on "p" when only the "p_rgh" field can be relaxed.

Speaking of this problem, do any of you know a way to have to the solver output what field names can use an underrelaxation factor?

That was my point. "p" is only checked for (and fails) if the relax()-method is called. So if "p x;" doesn't fail it means that there is no relaxation (have a look at GeometricField.C)

No. The relaxationFactors are only read "on demand" so nobody knows beforehand whether they will be used.

Maybe (but I havn't tried it) a variation of the above might word. Set a "catch all" regular expression in the relaxation factors:

".+" x;

and remove all other entries. Then the first relaxation should fail. Add a "correct" (==numeric) factor for that field and retry. As soon as the solver doesn't fail you found all relaxations for that solver