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

strange processor boundary behavior with linearUpwindV

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

Like Tree7Likes
  • 1 Post By ma-tri-x
  • 3 Post By ma-tri-x
  • 1 Post By wyldckat
  • 1 Post By wyldckat
  • 1 Post By krikre

Reply
 
LinkBack Thread Tools Search this Thread Display Modes
Old   November 4, 2011, 20:42
Default strange processor boundary behavior with linearUpwindV
  #1
New Member
 
Austin Kimbrell
Join Date: Feb 2011
Location: Tennessee, USA
Posts: 8
Rep Power: 15
akimbrell is on a distinguished road
Code used is a recent version of OpenFOAM-1.6-ext.

I observed the following behavior when running a test case in parallel - see attached image. The case is a point vortex with P = 0 boundaries and U boundaries set to zeroGradient. I am running standard icoFoam solver with 3 processors. For discretization schemes I am using the default Gauss linear everywhere except div(phi,U), for that one I use Gauss linearUpwindV Gauss linear. My max Courant number is ~0.3, grid resolution is reasonable.

The quantity shown is vorticity magnitude - you can see that when the scale is minimized, data is not being shared properly across the processor boundaries - they effectively show up in the solution when they should be invisible. I have run this case previously in serial and have not seen anything like this before. Furthermore, most other schemes for the convection term do not show this behavior. I have observed something similar also using SFCDV but it dissipates shortly after initialization.

Is this a known problem with the linearUpwindV scheme? I have also tried pure linearUpwind and did not see this problem at all.
Attached Images
File Type: png linearUpwindV.png (20.4 KB, 363 views)

Last edited by akimbrell; November 4, 2011 at 20:42. Reason: identified OpenFOAM version
akimbrell is offline   Reply With Quote

Old   November 5, 2011, 13:45
Default
  #2
Senior Member
 
Alberto Passalacqua
Join Date: Mar 2009
Location: Ames, Iowa, United States
Posts: 1,912
Rep Power: 36
alberto will become famous soon enoughalberto will become famous soon enough
This is typically due to a missing update of the BC's. If you can reproduce it in 2.0.x, please report it as a bug on http://www.openfoam.com/mantisbt/main_page.php .
__________________
Alberto Passalacqua

GeekoCFD - A free distribution based on openSUSE 64 bit with CFD tools, including OpenFOAM. Available as in both physical and virtual formats (current status: http://albertopassalacqua.com/?p=1541)
OpenQBMM - An open-source implementation of quadrature-based moment methods.

To obtain more accurate answers, please specify the version of OpenFOAM you are using.
alberto is offline   Reply With Quote

Old   February 11, 2013, 15:56
Default
  #3
Member
 
David Hora
Join Date: Mar 2009
Location: Zürich, Switzerland
Posts: 63
Rep Power: 17
david is on a distinguished road
http://www.openfoam.org/mantisbt/view.php?id=676

https://github.com/OpenFOAM/OpenFOAM...01782e30bd4291

Regards
David
david is offline   Reply With Quote

Old   November 6, 2013, 04:53
Default
  #4
s.m
Senior Member
 
saeideh mohamadi
Join Date: Aug 2012
Posts: 229
Rep Power: 14
s.m is on a distinguished road
Hi
would you please tell me that how linearUpwind can be define in OpenFOAM-1.6-ext?
e.g linearUpwind in openFoam 2.2.0 is defind in this way:
div(phi,U) Gauss linearUpwindV grad(U);

i want to know how should i define it in OpenFOAM-1.6-ext?

thank you very much
s.m is offline   Reply With Quote

Old   November 9, 2013, 14:16
Default
  #5
Retired Super Moderator
 
Bruno Santos
Join Date: Mar 2009
Location: Lisbon, Portugal
Posts: 10,974
Blog Entries: 45
Rep Power: 128
wyldckat is a name known to allwyldckat is a name known to allwyldckat is a name known to allwyldckat is a name known to allwyldckat is a name known to allwyldckat is a name known to all
Greetings s.m,

You can find tutorials that use this scheme by running:
Code:
grep -R "linearUpwindV" $FOAM_TUTORIALS/
Best regards,
Bruno
__________________
wyldckat is offline   Reply With Quote

Old   May 18, 2014, 21:04
Default compressible InterFoam
  #6
Member
 
Join Date: Sep 2013
Posts: 46
Rep Power: 12
ma-tri-x is on a distinguished road
Hi !

I worked several months on simualtion of cavitation bubbles. I started with the compressibleInterFoam solver and modified it, but the problem still also remains with the original one(s) (versions: 2.1.1, 2.2.1, 2.3.0):

When at least one of the processor patches crosses the interface, the velocity field is not computed correctly. You observe numerical fragments parallel to the patch like in the following picture
https://www.dropbox.com/s/a4cr4qpyoqjhue2/bug.png

The only version I discovered to be able to deal with the decomposition is the openfoam-extend version.

Has anyone observed this? Is this the same error as discussed here?

Furthermore I discovered that even without decomposing, running a 2D axis-symmetric case has some overestimating properties in the cell of the interface directly at the axis. So if you place a bubble that will collapse onto the axis, it will unphysically get thinner at the axis. This also seems to be no problem in the extend version 3.0 (absolutely same input files).

Regards,
Max
ngj likes this.

Last edited by ma-tri-x; May 18, 2014 at 21:08. Reason: forgot sth
ma-tri-x is offline   Reply With Quote

Old   May 20, 2014, 07:04
Default
  #7
Member
 
David Hora
Join Date: Mar 2009
Location: Zürich, Switzerland
Posts: 63
Rep Power: 17
david is on a distinguished road
Hi Max

Do you see the numerical fragments only with linearUpwindV or also with other schemes? I think it would be good to report this bug. Do you have a simple case that demonstrates your problems?

Regards
David
david is offline   Reply With Quote

Old   May 20, 2014, 13:13
Default I don't use linearUpwind
  #8
Member
 
Join Date: Sep 2013
Posts: 46
Rep Power: 12
ma-tri-x is on a distinguished road
Hi David!

I don't use linearupwind. My fvSchemes looks like:
Code:
ddtSchemes
{
    default         Euler;
}

gradSchemes
{
    default         Gauss linear;
}

divSchemes
{
    default            Gauss vanLeer;
     div(phirb,alpha) Gauss interfaceCompression 1;
}

laplacianSchemes
{
   default              Gauss linear corrected;
}

interpolationSchemes
{
    default         linear;
}

snGradSchemes
{
    default              none;
//     default              Gauss skewCorrected linear;
    snGrad(pd)           limited 0.5;
    snGrad(rho)          limited 0.5;
    snGrad(alpha1)       limited 0.5;
    snGrad(p_rgh)      limited 0.8;
    snGrad(p)          limited 0.8;
}

fluxRequired
{
    default              none;
    p_rgh;
    p;
    pcorr;
    alpha1;
}
A simple example which is reproducable... erm ... I don't know and I'm currently writing my thesis so I have little time to prepare one...

In August, I will be able to prepare one...

I think you will immediately see the symmetry-axis-effect when you set up a bubble with very low pressure on an axis of an axis-symmetric mesh. in the very first timestep, where the bubble wall starts to accelerate, you find that the two cells where the interface hits the axis accelerate faster. It's hidden in the next timesteps because I think you cannot set a threshold for the U-field magnitude in paraview (the two cells are only slightly faster and the range of U-magnitude over the mesh is much larger). I cannot show you this unfortunately, because I didn't save a screenshot. But I can show you another freaky example:

Once I decomposed with scotch and some processor boundaries were parallel to the bubble wall at some time. When the bubble passed the processor patch, droplets were formed. Maybe I can put the screenshot here. A yes, here's an attachment. The left picture is at t=8.18393e-5, the right is at t=8.33299e-5. In between the bubble collapsed further and the interface (="bubble wall") passed the scotch-processor-patch.
Attached Images
File Type: jpg compareDecompositionAndSingleProc.jpg (15.7 KB, 139 views)

Last edited by ma-tri-x; May 20, 2014 at 13:17. Reason: better explanation
ma-tri-x is offline   Reply With Quote

Old   October 17, 2015, 16:57
Default Solved
  #9
Member
 
Join Date: Sep 2013
Posts: 46
Rep Power: 12
ma-tri-x is on a distinguished road
Quote:
Originally Posted by akimbrell View Post
Code used is a recent version of OpenFOAM-1.6-ext.

I observed the following behavior when running a test case in parallel - see attached image. The case is a point vortex with P = 0 boundaries and U boundaries set to zeroGradient. I am running standard icoFoam solver with 3 processors. For discretization schemes I am using the default Gauss linear everywhere except div(phi,U), for that one I use Gauss linearUpwindV Gauss linear. My max Courant number is ~0.3, grid resolution is reasonable.

The quantity shown is vorticity magnitude - you can see that when the scale is minimized, data is not being shared properly across the processor boundaries - they effectively show up in the solution when they should be invisible. I have run this case previously in serial and have not seen anything like this before. Furthermore, most other schemes for the convection term do not show this behavior. I have observed something similar also using SFCDV but it dissipates shortly after initialization.

Is this a known problem with the linearUpwindV scheme? I have also tried pure linearUpwind and did not see this problem at all.
Hi!

After years of calculating in parallel with openFOAM of several versions, I finally found the bug:
have a look at your
Code:
controlDict
. Do you adjustTimeStep? Then you have to go have a look into the several processorN-directories of your run and compare the times. Are they the same? Probably NOT. It is because there exist as many CoNums (Courant numbers) as there are processors used. You have to explicitly take the minimum CoNum of ALL processors. So go into the sources of your solver
Code:
cd $WM_PROJECT_DIR/applications/solvers/path-to-solver
and edit the file
Code:
CorantNo.H
from
Code:
    CoNum = max(SfUfbyDelta/mesh.magSf()).value()*deltaT;
to
Code:
    CoNum = max(SfUfbyDelta/mesh.magSf()).value()*deltaT;
    reduce(CoNum,minOp<scalar>());
if you are using also the acousticCoNum then you have to do it for this one as well.
Now run
Code:
./Allwmake
and you'll be fine forever. I think.
wyldckat, Neka and szamani like this.
ma-tri-x is offline   Reply With Quote

Old   October 17, 2015, 17:17
Default
  #10
Retired Super Moderator
 
Bruno Santos
Join Date: Mar 2009
Location: Lisbon, Portugal
Posts: 10,974
Blog Entries: 45
Rep Power: 128
wyldckat is a name known to allwyldckat is a name known to allwyldckat is a name known to allwyldckat is a name known to allwyldckat is a name known to allwyldckat is a name known to all
Hi ma-tri-x,

Many thanks for sharing this solution!
I've taken a look into how the latest OpenFOAM versions deal with this and they calculate the Courant numbers differently and are able to be consistent with the values for all processors.

I've checked and this issue currently only occurs in foam-extend (and their old OpenFOAM 1.6-ext). Please report this at their bug tracker here: http://sourceforge.net/p/openfoam-ex...extendrelease/

Best regards,
Bruno

Edit: Since 7 days have passed, I've reported this here, so that it wouldn't be lost: https://sourceforge.net/p/openfoam-e...ndrelease/295/
ma-tri-x likes this.

Last edited by wyldckat; October 24, 2015 at 13:54. Reason: see "Edit:" and fixed typo
wyldckat is offline   Reply With Quote

Old   November 3, 2015, 00:44
Default
  #11
New Member
 
anand sudhi
Join Date: Sep 2015
Posts: 16
Rep Power: 10
anandsudhi is on a distinguished road
Hi

It would be a huge help if you can tell me the extra modification done to linearUpwindV to account for direction of the field. I understand there is a new variable 'maxCorr' in the code. But i am not able to understand its implementation. What is the purpose of this modification?

Also does this modification make linearUpwindV bounded with out the need of specifying limited gradients?

Any comments will be very much appreciated.

Thank you

Anand
anandsudhi is offline   Reply With Quote

Old   November 4, 2015, 10:20
Default
  #12
Member
 
Join Date: Sep 2013
Posts: 46
Rep Power: 12
ma-tri-x is on a distinguished road
Quote:
Edit: Since 7 days have passed, I've reported this here, so that it wouldn't be lost: https://sourceforge.net/p/openfoam-e...ndrelease/295/
Hi Bruno!
Sorry, I didn't receive an email that you replied to my post. Thanks a lot for reporting this "bug"! Strangely enough, I only observed this in some special cases. In other cases, the time steps were synchronized but it may have occured that some cores just waited for the others to complete intermediate time steps and afterwards these intermediate ones were deleted again. It seems that deep inside the source code there's something not working properly (because the same version of openmpi sometimes works, sometimes this bug occurs).

@Anand: I don't have a clue about the upwind thing. You must ask someone of the previous posts. I suggested that it doesn't have to do with linearUpdwind since I didn't use that one and got the bug as well... At least it looked alike.

Kind regards,
Max
ma-tri-x is offline   Reply With Quote

Old   April 12, 2016, 06:49
Default
  #13
New Member
 
Carles
Join Date: Aug 2015
Posts: 4
Rep Power: 10
CarlesCQL is on a distinguished road
Hi everyone!

I'm having a similar problem with the processor boundary conditions trying to simulate a trombe wall with chtMultiRegionFoam with 6 processors. The pictures show the velocity in the air region (inside de building and surrounding the trombe wall). The first one is the initial condition I used mapped from a chtMultiRegionSimpleFoam parallel run. In the second one the strange behaviour in the processor boundaries shows up.

It seemed that it was a problem with the 1.6-ext version, but I'm using 2.4, and not seen the inconsistency in the time directories. The tutorial multiRegionHeater runs ok in parallel.

In my case this problem only occurs in the transient run and in the fluid region.

Any idea? Thanks!
Attached Images
File Type: png Ut0.png (68.3 KB, 96 views)
File Type: png Ut003.png (90.6 KB, 83 views)
File Type: png grid.png (92.8 KB, 72 views)
CarlesCQL is offline   Reply With Quote

Old   July 26, 2017, 17:46
Default
  #14
Member
 
Alexander Nekris
Join Date: Feb 2015
Location: France
Posts: 32
Rep Power: 11
Neka is on a distinguished road
Hello everybody!


I have to revive this old thread.


I've observed a very strange behavior at the processor boundaries.
I work with foam-extend- 4.0 and use a kind of a mix between reactingFoam and sonicFoam to simulate chemical kinetics at supersonic velocites. My test case is a 2D wedge in a supersonic flow. I heat the gas locally on the surface of the wedge which leads to a decomposition of molecular nitrogen into atomic nitrogen.


When I run my test case serial then every thing is fine. I get my dissociation of N2 into N at the location, where I heat the gas. But after I switched from serial to parallel (here 4 processors) the N mass fraction started moving along the processor boundary see in the attached image a strip on the left side. What you see is the upper side of the wedge where I heat the gas. For visualizing I reduced the maximum of the color scale.


I tried to update mass fractions after the Yi-equation with Yi.correctBoundaryConditions(). I tried to change the div and laplacian schemes which showed some changes in the behaviour but the behaviour was still there.


When I deactivate the convective and diffusive terms in the Yi-equation then this phenomenon does not occur which means the problem is with the div and laplacian schemes. Correct?


I dont use adjustTimeStep but a fixed time step. My div scheme in the Yi-equation is Gauss limitedLinear01 1 and my laplacian scheme is Gauss linear uncorrected.


Does anybody know what happens with my mass fractions? Has anyone observed the same error?


Any suggestion or advice are welcome!


Regards,
Alex
Attached Images
File Type: png mass_fraction_N.png (17.8 KB, 47 views)
Neka is offline   Reply With Quote

Old   July 31, 2017, 13:14
Default
  #15
Member
 
Alexander Nekris
Join Date: Feb 2015
Location: France
Posts: 32
Rep Power: 11
Neka is on a distinguished road
Hello everyone,

I guess I solved the problem but I don’t know why it works.

I simulate supersonic flows at very high velocities, meaning, at deltaT of about 5.0e-9 I have a max Courant Number of about 0.2.
So, I have to work with very small deltaT values.

I use the following solver conditions for my Y-Equation:

Solver BiCGStab;
preconditioner DILU;
tolerance 1e-08;
relTol 0;

If I reduce the tolerance to 1e-07, the strange behavior at the processor boundaries disappears! I don’t know why it happens.
Anyhow, the proper combination of deltaT and tolerance are needed.

Does anybody know why it happens?

Regards,

Alex

Last edited by Neka; August 1, 2017 at 11:07.
Neka is offline   Reply With Quote

Old   August 1, 2017, 11:20
Default
  #16
Member
 
Alexander Nekris
Join Date: Feb 2015
Location: France
Posts: 32
Rep Power: 11
Neka is on a distinguished road
Ok, it turns out I haven’t solved the problem!

When I reduce the tolerance from 1e-08 to 1e-07, the strange behavior at the processor boundaries disappears, but simultaneously the Y-equation stops convecting, meaning the mass fractions are frozen and don’t move anymore. I probably forgot to mention that my mass fractions of N (atomic nitrogen) are very small (e.g. Y_N = 1.0e-08), so I work with very small numbers here.

Any suggestion or advice are welcome!
Neka is offline   Reply With Quote

Old   March 25, 2018, 10:05
Default
  #17
Member
 
Kristjan
Join Date: Apr 2017
Location: Slovenia
Posts: 36
Rep Power: 8
krikre is on a distinguished road
Does this commit resolve the issue?
https://github.com/OpenFOAM/OpenFOAM...aefb62bb47c0c2

I've been looking at this source but I didn't get my head around the problem. Could someone explain?
https://cpp.openfoam.org/v3/a08663_source.html

I'm using a modified compressibleInterFoam from OpenFOAM v3.0.1 in parallel.
Courant number peaks by orders of magnitude in one of the domains, step time is variable and limited by CoMax and solution discontinuity appeared over the processor boundaries.

I'm guessing I should copy
$(WM_PROJECT_DIR)/src/finiteVolume/lnInclude/CourantNo.H
to my solver dir, make the change and include it under a different name?
krikre is offline   Reply With Quote

Old   March 26, 2018, 17:29
Default
  #18
Retired Super Moderator
 
Bruno Santos
Join Date: Mar 2009
Location: Lisbon, Portugal
Posts: 10,974
Blog Entries: 45
Rep Power: 128
wyldckat is a name known to allwyldckat is a name known to allwyldckat is a name known to allwyldckat is a name known to allwyldckat is a name known to allwyldckat is a name known to all
Quick answers:
Quote:
Originally Posted by krikre View Post
Does this commit resolve the issue?
https://github.com/OpenFOAM/OpenFOAM...aefb62bb47c0c2
Depends on whether your case has parts of the mesh where a sub-domain (one of the processor meshes) only has boundary faces and has no internal faces.

Quote:
Originally Posted by krikre View Post
I've been looking at this source but I didn't get my head around the problem. Could someone explain?
https://cpp.openfoam.org/v3/a08663_source.html
That is a fairly large class, if you can be more specific about what you don't understand, it would be a lot faster/easier to explain.

Quote:
Originally Posted by krikre View Post
I'm using a modified compressibleInterFoam from OpenFOAM v3.0.1 in parallel.
Courant number peaks by orders of magnitude in one of the domains, step time is variable and limited by CoMax and solution discontinuity appeared over the processor boundaries.

I'm guessing I should copy
$(WM_PROJECT_DIR)/src/finiteVolume/lnInclude/CourantNo.H
to my solver dir, make the change and include it under a different name?
There have been several changes to OpenFOAM since 3.0.1 and given that compressibleInterFoam is a very specialized solver, I strongly suggest that you try running your case or a simpler test case with both OpenFOAM 3.0.1 and 5.x, to see if that problem still occurs or not.
krikre likes this.
__________________
wyldckat is offline   Reply With Quote

Old   March 26, 2018, 19:11
Default
  #19
Member
 
Kristjan
Join Date: Apr 2017
Location: Slovenia
Posts: 36
Rep Power: 8
krikre is on a distinguished road
Quote:
Originally Posted by wyldckat View Post
Quick answers:

Depends on whether your case has parts of the mesh where a sub-domain (one of the processor meshes) only has boundary faces and has no internal faces.
All sub-domains contain internal faces. I'll spend some more time on this and come back if I find anything useful. Thank you for your time!
krikre is offline   Reply With Quote

Old   April 2, 2018, 08:42
Default
  #20
Member
 
Kristjan
Join Date: Apr 2017
Location: Slovenia
Posts: 36
Rep Power: 8
krikre is on a distinguished road
Quote:
Originally Posted by krikre View Post
Does this commit resolve the issue?
https://github.com/OpenFOAM/OpenFOAM...aefb62bb47c0c2

I've been looking at this source but I didn't get my head around the problem. Could someone explain?
https://cpp.openfoam.org/v3/a08663_source.html

I'm using a modified compressibleInterFoam from OpenFOAM v3.0.1 in parallel.
Courant number peaks by orders of magnitude in one of the domains, step time is variable and limited by CoMax and solution discontinuity appeared over the processor boundaries.

I'm guessing I should copy
$(WM_PROJECT_DIR)/src/finiteVolume/lnInclude/CourantNo.H
to my solver dir, make the change and include it under a different name?
I apologize for the false alarm. I misused ParaView on a decomposed case.
wyldckat likes this.
krikre is offline   Reply With Quote

Reply

Thread Tools Search this Thread
Search this Thread:

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


Similar Threads
Thread Thread Starter Forum Replies Last Post
Strange Nut behaviour with K-OmegaSST nicolarre OpenFOAM Running, Solving & CFD 12 March 19, 2019 21:35
Strange Flamelet Generation Problem tar FLUENT 11 March 22, 2014 11:52
strange pressure behaviour with symmetricPlane boudary condition - interFoam duongquaphim OpenFOAM Running, Solving & CFD 10 August 20, 2013 15:00
Coordination Frame Problem - strange Luk_Fiz CFX 2 July 30, 2010 09:20
Strange things in SRF (urgent) Cem FLUENT 0 December 19, 2005 11:37


All times are GMT -4. The time now is 03:01.