[rolando]

Hi,
there seems to be a inconsistency in the calculation of the courant numbers in CourantNo.H.
The maximum Co is built with:
CoNum = max(SfUfbyDelta/mesh.magSf()).value()*runTime.deltaT().value();
The mean Co is built with:
meanCoNum = (sum(SfUfbyDelta)/sum(mesh.magSf())).value()*runTime.deltaT().value( );

This is no problem for serial cases.
But for parallel cases there should be used "gMax" and "gSum" instead of "max" and "sum" to build the Courant numbers considering all processors.

Rolando

[henry]

The max and sum functions of GeometricField call gMax and gSum of the internal field from which it is derived.

[rolando]

OK, then it´s clear.
Thanks.

[Maff]

I know this is a very old thread, but I've also noticed an inconsistency.
I was comparing the acoustic Co calculated with rhoCentralFoam (2.4.0) and with dbnsTurbFoam (foam-extend-4.0), and I was getting different results.
I narrowed it down to the different behaviour of max and gMax.
In particular, in rhoCentralFoam the Co is defined as:

CoNum = max(amaxSfbyDelta/mesh.magSf()).value()*runTime.deltaTValue();

And I get maxCo=0.419.

If I replace it with

surfaceScalarField Co = amaxSfbyDelta/mesh.magSf()*runTime.deltaT();
CoNum = gMax(Co);

I get maxCo=0.242.

And this happens in serial mode.

Any idea of what could be the cause?

[wyldckat]

Quick answer: In commit d28a72f14c9edba6fe77990c9dee6d7692725a57, which was already released in OpenFOAM 4.0, the file you're referring to was changed to do as commented on the commit:

rhoCentralFoam: Updated Courant number calculation to be cell-based rather than face-based

Now consistent with the way the Courant number is calculated for other solvers

This leads me to what I was already deducing based on your findings: using "max" or "gMax" can lead to different ways of consolidating the information from multiple subdomains.
For example:

• by using "gMax" on the "Co" field, it will also take into account the data calculated at the processor patches;
• while the "max" call might only be calculating on the subdomains fields, without accounting for the processor patches.

Or it might be the other way around, I'm not sure. Without a specific test case with which to reproduce this, I'm not sure of what each one is doing.


Nonetheless, if the correction made in the aforementioned commit does solve the issue, then this is because the modified way of calculation is better aware of how the discretization is done between sub-domains. For example, by using the cell values, this means that the processor patches no longer play an important role in how the data is gathered from each sub-domain.
( *better aware: sorry, I couldn't remember a better description.)

Either way, please test with OpenFOAM 4.0 or 4.x and let us know of your findings.


Although... this is reminding me of something... this bug report of mine: https://sourceforge.net/p/openfoam-e...ndrelease/295/ - for foam-extend. I reported it because there was a finding by a fellow forum member on an issue in foam-extend's way of calculating the Courant number, as documented here: http://www.cfd-online.com/Forums/ope...tml#post568787 - post #9. Therefore, please also make sure that the results from dbnsTurbFoam in foam-extend 4.0 are correct as well.

[Maff]

Thank you wyldckat for your reply,
I tested the formulation of OpenFOAM 4.0 and weirdly enough I got another completely different value: Co=0.35.
Hopefully this is the right one but I'm honestly confused.