CFD Online Logo CFD Online URL
www.cfd-online.com
[Sponsors]
Home > Forums > OpenFOAM Bugs

Inconsistency in CourantNoH

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

Like Tree1Likes
  • 1 Post By henry

Reply
 
LinkBack Thread Tools Display Modes
Old   June 20, 2007, 09:21
Default Hi, there seems to be a incon
  #1
Member
 
Rolando Maier
Join Date: Mar 2009
Posts: 89
Rep Power: 9
rolando is on a distinguished road
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
rolando is offline   Reply With Quote

Old   June 20, 2007, 09:31
Default The max and sum functions of G
  #2
Senior Member
 
Join Date: Mar 2009
Posts: 854
Rep Power: 14
henry is on a distinguished road
The max and sum functions of GeometricField call gMax and gSum of the internal field from which it is derived.
hua1015 likes this.
henry is offline   Reply With Quote

Old   June 20, 2007, 09:33
Default OK, then itīs clear. Thanks.
  #3
Member
 
Rolando Maier
Join Date: Mar 2009
Posts: 89
Rep Power: 9
rolando is on a distinguished road
OK, then itīs clear.
Thanks.
rolando is offline   Reply With Quote

Old   August 17, 2016, 06:35
Default
  #4
New Member
 
Join Date: Mar 2012
Posts: 16
Rep Power: 6
Maff is on a distinguished road
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:
Code:
CoNum = max(amaxSfbyDelta/mesh.magSf()).value()*runTime.deltaTValue();
And I get maxCo=0.419.

If I replace it with
Code:
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?
Maff is offline   Reply With Quote

Old   August 20, 2016, 18:39
Default
  #5
Super Moderator
 
Bruno Santos
Join Date: Mar 2009
Location: Lisbon, Portugal
Posts: 9,636
Blog Entries: 39
Rep Power: 99
wyldckat is just really nicewyldckat is just really nicewyldckat is just really nicewyldckat is just really nicewyldckat is just really nice
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:
Quote:
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: strange processor boundary behavior with linearUpwindV - post #9. Therefore, please also make sure that the results from dbnsTurbFoam in foam-extend 4.0 are correct as well.
__________________
wyldckat is offline   Reply With Quote

Old   September 5, 2016, 05:16
Default
  #6
New Member
 
Join Date: Mar 2012
Posts: 16
Rep Power: 6
Maff is on a distinguished road
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.
Maff is offline   Reply With Quote

Reply

Thread Tools
Display Modes

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 Off
Trackbacks are On
Pingbacks are On
Refbacks are On


Similar Threads
Thread Thread Starter Forum Replies Last Post
WAVE & TAB breakup inconsistency Orrin FLUENT 0 January 7, 2009 12:02
Inconsistency of GRidgen Prapanj Pointwise & Gridgen 3 September 30, 2007 15:08
Problem with BC inconsistency segersson OpenFOAM Running, Solving & CFD 5 April 28, 2005 12:34
Units inconsistency (CFX5.5) gilberto CFX 3 December 14, 2001 20:03


All times are GMT -4. The time now is 23:13.