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

V2106: Erroneous Velocity's on decomposePar

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

Reply
 
LinkBack Thread Tools Search this Thread Display Modes
Old   July 30, 2021, 17:40
Default V2106: Erroneous Velocity's on decomposePar
  #1
Member
 
Join Date: Aug 2017
Posts: 32
Rep Power: 8
siefer92 is on a distinguished road
Howdy Yall:

I am having another problem as it pertains to case conversion from OFv2012 to OFv2106.

Fortunately my last issue was solved, thanks Oleson , and I have since downloaded the openfoam_master source code. I can now convert my gmsh mesh into OpenFOAM and decompose it. Olesen's post in that thread has a link which will take to the resolved issue:

Error in gmshToFoam on ESI v2106

Now I bring that thread up because I am getting erroneous values for the velocity on certain processors after I decompose the mesh. I originally thought this was a result of converting my mesh via v2012 and running in v2106. But now I am no longer certain.

The first image is of the cellDist field as provided by: decomposePar -cellDist

using a 32 core decomposition

ProcDistribution.JPG

When visualizing the velocity field Proc16 stands out with a strange value. Shown in the next Image:

Proc16 erroneous velocity.JPG

Additionally, such an erroneous assignment exists on my inlet boundary. Mind the sliver as this is a "2d" case.

Erroneous Boundary Assignment.JPG

Now the weird part. Normally, with such high velocities, you would expect the solver to crap out rather quickly. But it runs to completion.

I manually checked the processor files for any values with "e+" mag>1000 as my inlet BC is 500 m/s and for the test case the velocity should cap around 950 m/s as the flow diverts around the cylinder.

No values containing e+ are written to any of the processors at any timestep.

Normally I would chalk this up as a Paraview error and be on my way.... Hell when I reload the files, the erroneous processors and values shift around.

Additionally, when I view the cell data in Paraview for any timestep not = 0, see the next attachment. There are no erroneous velocity readings.

Cell Data.JPG

vs interpolated by paraview

Paraview non-cell.JPG

So for time = 0 there is some sort of problem going on. Though I'm not certain what.

The reason why I bring this up in the programming forum is because There are some interesting, previously non-observed, effects on the coupled lagrangian debris field.

In what should be a a uniform velocity and temperature injection and a lognormal size distribution, there is a large amount of variance near the inlet on the reported Reynolds and Nusselt Numbers. I've hit the Image cap on this post and with post the views as well as a histogram of the various non-dimensional numbers on a comment post below.

Placing the test case in the next message as well. Not including the source code of the particular solver as I am confident it is not the problem as this issue has, until now, not been encountered. v2012, v2006, v1912 works with the custom code I am working on. I do plan on releasing it once I've done some V&V though .

Last edited by siefer92; July 30, 2021 at 17:49. Reason: Forgot to include OF Version number
siefer92 is offline   Reply With Quote

Old   July 30, 2021, 17:42
Default
  #2
Member
 
Join Date: Aug 2017
Posts: 32
Rep Power: 8
siefer92 is on a distinguished road
Images of the particle Stokes, Nusselt and Reynolds Numbers.

Stokes Number
ParticleStokes.jpg

Nusselt Number
ParticleNusselt.jpg

Reynolds Number
ParticleReynolds.jpg

The reported stokes number looks reasonable and it's distribution is very much lognormal.

My issue with the Reynolds & Nusselt numbers isn't their distributions. Looking at the particles in the lower left hand corner of the domain you can see a distinct difference in particles entering near the bottom portion of the inlet. Nusselt numbers are lower than the rest of the particles entering the domain as are the reynolds numbers as well.

Last edited by siefer92; July 30, 2021 at 17:59. Reason: Added some clarifying commentary at the end.
siefer92 is offline   Reply With Quote

Old   July 30, 2021, 17:48
Default
  #3
Member
 
Join Date: Aug 2017
Posts: 32
Rep Power: 8
siefer92 is on a distinguished road
Not able to attach the .zip file for some reason so I have attached a google drive link to the compressed test case.

https://drive.google.com/file/d/162M...ew?usp=sharing


----------------------------------------------
Currently working on***

Running the case as a serial process to see if it is truly an issue associated with v2106 parallelization.

Last edited by siefer92; July 30, 2021 at 18:21. Reason: Added a currently working on notice***
siefer92 is offline   Reply With Quote

Old   July 30, 2021, 18:41
Default
  #4
Member
 
Join Date: Aug 2017
Posts: 32
Rep Power: 8
siefer92 is on a distinguished road
Ok so some new images.

When I look at the velocity of the serial test case and reload the files for visualization I can sometimes get a normal looking velocity field. The majority of the time I get the following:

Correct-ish "not V&V'ed"
Serial Velocity.JPG

Wrong Velocity

Serial Velocity Reloaded.JPG

For the same exact case ran in serial, I get the following distributions for Stokes, Nusselt and Reynolds.

Stokes Number:
Serial Stokes.jpg

Nusselt Number:
Serial Nusselt.jpg

Reynolds Number:
Serial Reynolds.jpg

Through visual inspection I can tell that there is something wrong as the solution has changed between the parallel and serial cases. Though the serial case looks more as I would expect for a uniform inlet and injection condition.
siefer92 is offline   Reply With Quote

Reply

Tags
boundaries, decomposed, mesh, parallel, paraview

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
decomposePar problem: Cell 0contains face labels out of range (Again)) limonegiallo OpenFOAM Pre-Processing 4 August 28, 2017 06:18
decomposePar error chia87 OpenFOAM Pre-Processing 1 May 28, 2017 16:23
decomposePar for custom solvers and boundary conditions cfdopenfoam OpenFOAM Programming & Development 4 October 31, 2015 10:05
decomposePar 4-core warning/error? Boloar OpenFOAM Bugs 23 April 8, 2014 09:57
decomposePar gives errors of_user_ OpenFOAM 1 July 4, 2011 06:27


All times are GMT -4. The time now is 07:27.