[lr103476]

Consider the movingCone case with the solver icoFoamAutoMotion.

When using the second order CrankNicholson time integration I get an error message after the first mesh update.

FOAM FATAL IO ERROR : attempt to read beyond EOF

From function ITstream::read(token& t)
in file db/IOstreams/Tstreams/ITread.C at line 70.

Later I also tried this scheme in the cavity problems, but with no succes.

Is someone actually using this scheme, or am I doing something wrong.

Frank

[hjasak]

There has been a change in the format that is not reflected in the config files. Add 0.5 after CrankNicholson (now the factor is run-time selectable):

ddtSchemes
{
default CrankNicholson 0.5;
}

Enjoy,

Hrv

[maka]

shouldn't be CrankNicholson 1?

in the user guide:

4.4.6 Time schemeshttp://www.opencfd.co.uk/openfoam/do...#x20-1050004.4

it says:

There is an off-centering coefficient y with the CrankNicholson scheme that blends it with the the Euler scheme. A coefficient of y = 1 corresponds to pure CrankNicholson and and y = 0 corresponds to pure Euler. The blending coefficient can help to improve stability in cases where pure CrankNicholson are unstable.

best regards,
Maka

[mattijs]

Sorry, I don't understand. What shouldn't be 1?

(I only see some duplicate 'the the' and 'and and' in that section)

[maka]

I mean that the previous message seemed to suggest that: a pure CrankNicholson scheme is applied in OpenFOAM by setting:

ddtSchemes
{
default CrankNicholson 0.5;
}

while the help in the user guide seems to says that it is:

ddtSchemes
{
default CrankNicholson 1;
}

which is right?

Many thanks,
Maka

[hjasak]

You should be able to find this out by looking at the source code:

/finiteVolume/ddtSchemes/CrankNicholsonDdtScheme/CrankNicholsonDdtScheme.H

//- Off-centering coefficient, 1 -> CN, less than one blends with EI
scalar ocCoeff_;

Need I say more? :-)

Hrv

[lr103476]

So a factor of 1 corresponds to fully second order Crank-Nicholson? I thought it should be 0.5?

Is this changed in OpenFOAM version 1.3

Frank

[maka]

CrankNicholsonDdtScheme.C changed between V 1.2 and 1.3 but I have no clue if the behavior changed. I'm still using V 1.2 and have been running a one-month simulation assuming it should be CrankNicholson 0.5 as the early post suggested. Do not ask me what is right and what is wrong. All I can say, enjoy :-)

/Maka

[lr103476]

Could someone please explain the differences (if any) between v1.2 and v1.3.

Conform the theory books, a value of 0.5 would makes more sense then 1.0.

Frank

[mattijs]

No basic differences between 1.2 and 1.3.

//- Off-centering coefficient, 1 -> CN, less than one blends with EI

[maka]

Many thanks Mattijs for your clear reply.
/Maka.

[lr103476]

So for the record, Crank Nicholson 1.0 corresponds to fully second order accuracy, while a value less then 1.0 is less accurate.

Sorry to bother you again, but I am not really into the theory at this moment.

Frank

[openfoammaofnepo]

Hi All,

When I choose CN, but set the factor to 1. The pressure is very prone to blow up, which lead to the simulation failure. Could anyone tell me what is the reason for this problem? Thank you very much.

Originally Posted by hjasak

You should be able to find this out by looking at the source code:

/finiteVolume/ddtSchemes/CrankNicholsonDdtScheme/CrankNicholsonDdtScheme.H

//- Off-centering coefficient, 1 -> CN, less than one blends with EI
scalar ocCoeff_;

Need I say more? :-)

Hrv

[KateEisenhower]

Hi,

please have a look at CrankNicolsonDdtScheme.H:

The Crank-Nicosonl scheme is often unstable for complex flows in complex geometries and it is neccessary to "off-centre" the scheme to stabilize it ...

And in the context of this, see also the "Note" a few lines below:

The Crank-Nicolson coefficient for the implicit part of the RHS is related to the off-centering coefficient by

cnCoeff = 1.0/(1.0 + ocCoeff);