|
[Sponsors] |
June 20, 2007, 09:21 |
Hi,
there seems to be a incon
|
#1 |
Member
Rolando Maier
Join Date: Mar 2009
Posts: 89
Rep Power: 17 |
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 |
|
June 20, 2007, 09:31 |
The max and sum functions of G
|
#2 |
Senior Member
Join Date: Mar 2009
Posts: 854
Rep Power: 22 |
The max and sum functions of GeometricField call gMax and gSum of the internal field from which it is derived.
|
|
June 20, 2007, 09:33 |
OK, then itīs clear.
Thanks.
|
#3 |
Member
Rolando Maier
Join Date: Mar 2009
Posts: 89
Rep Power: 17 |
OK, then itīs clear.
Thanks. |
|
August 17, 2016, 06:35 |
|
#4 |
New Member
Join Date: Mar 2012
Posts: 20
Rep Power: 14 |
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(); If I replace it with Code:
surfaceScalarField Co = amaxSfbyDelta/mesh.magSf()*runTime.deltaT(); CoNum = gMax(Co); And this happens in serial mode. Any idea of what could be the cause? |
|
August 20, 2016, 18:39 |
|
#5 | |
Retired Super Moderator
Bruno Santos
Join Date: Mar 2009
Location: Lisbon, Portugal
Posts: 10,974
Blog Entries: 45
Rep Power: 128 |
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:
For example:
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.
__________________
|
||
September 5, 2016, 05:16 |
|
#6 |
New Member
Join Date: Mar 2012
Posts: 20
Rep Power: 14 |
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. |
|
Thread Tools | Search this Thread |
Display Modes | |
|
|
Similar Threads | ||||
Thread | Thread Starter | Forum | Replies | Last Post |
WAVE & TAB breakup inconsistency | Orrin | FLUENT | 0 | January 7, 2009 11: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 19:03 |