# OF ignores relaxation factor

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

 November 18, 2011, 07:24 OF ignores relaxation factor #1 New Member   Join Date: Jul 2011 Posts: 18 Rep Power: 8 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

 November 18, 2011, 12:39 #2 Senior Member   Steven van Haren Join Date: Aug 2010 Location: The Netherlands Posts: 149 Rep Power: 9 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?

November 18, 2011, 15:15
#3
Assistant Moderator

Bernhard Gschaider
Join Date: Mar 2009
Posts: 4,016
Rep Power: 43
Quote:
 Originally Posted by hugo17 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
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

 November 21, 2011, 03:23 Relaxation in laplacianFoam #4 New Member   Join Date: Jul 2011 Posts: 18 Rep Power: 8 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

November 21, 2011, 18:38
#5
Assistant Moderator

Bernhard Gschaider
Join Date: Mar 2009
Posts: 4,016
Rep Power: 43
Quote:
 Originally Posted by hugo17 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

solve( <the eqn >);

write

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

 November 22, 2011, 10:35 #6 New Member   Join Date: Jul 2011 Posts: 18 Rep Power: 8 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

November 22, 2011, 15:17
#7
Assistant Moderator

Bernhard Gschaider
Join Date: Mar 2009
Posts: 4,016
Rep Power: 43
Quote:
 Originally Posted by hugo17 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?
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"?

 November 23, 2011, 03:28 #8 New Member   Join Date: Jul 2011 Posts: 18 Rep Power: 8 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?

November 23, 2011, 18:15
#9
Assistant Moderator

Bernhard Gschaider
Join Date: Mar 2009
Posts: 4,016
Rep Power: 43
Quote:
 Originally Posted by hugo17 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)

November 24, 2011, 03:37
#10
New Member

Join Date: Jul 2011
Posts: 18
Rep Power: 8
Quote:
 Originally Posted by gschaider Please specify "does not have any effect".
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?

 January 13, 2012, 12:52 #11 Senior Member   Illya Shevchuk Join Date: Aug 2009 Location: Darmstadt, Germany Posts: 176 Rep Power: 10 Hi, I have the same problem. In my PIMPLE-based solver I try to relax the TEqn. In the outer iteration cycle I have: Code: ```{ fvScalarMatrix TEqn (...); TEqn.relax(); eqnResidual = TEqn.solve().initialResidual(); }``` and in the system/fvSolution I added a subDict: Code: ```relaxationFactors { T x; }``` 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

 May 10, 2012, 13:25 #12 New Member   Alton Luder III Join Date: Oct 2009 Location: Michigan Posts: 22 Rep Power: 9 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.

May 10, 2012, 14:11
#13
Assistant Moderator

Bernhard Gschaider
Join Date: Mar 2009
Posts: 4,016
Rep Power: 43
Quote:
 Originally Posted by sleepdeprivation 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) )
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

 May 10, 2012, 16:18 #14 New Member   Alton Luder III Join Date: Oct 2009 Location: Michigan Posts: 22 Rep Power: 9 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?

May 10, 2012, 19:26
#15
Assistant Moderator

Bernhard Gschaider
Join Date: Mar 2009
Posts: 4,016
Rep Power: 43
Quote:
 Originally Posted by sleepdeprivation 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.
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)

Quote:
 Originally Posted by sleepdeprivation 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?
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

 Thread Tools Display Modes Linear Mode

 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 OffTrackbacks are On Pingbacks are On Refbacks are On Forum Rules

 Similar Threads Thread Thread Starter Forum Replies Last Post dhxlxz CFX 10 August 11, 2015 20:52 jing113cn FLUENT 0 November 2, 2009 13:13 Benzaa Main CFD Forum 1 August 18, 2009 07:27 CFD Rookie Main CFD Forum 3 January 26, 2004 15:37 Moon Siemens 1 June 13, 2003 11:13

All times are GMT -4. The time now is 19:27.