V2106: Erroneous Velocity's on decomposePar

siefer92 · July 30, 2021, 17:40

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

.

siefer92 · July 30, 2021, 17:42

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.

siefer92 · July 30, 2021, 17:48

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.

siefer92 · July 30, 2021, 18:41

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.

July 30, 2021, 17:40	V2106: Erroneous Velocity's on decomposePar	#1
siefer92 Member Join Date: Aug 2017 Posts: 32 Rep Power: 9	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

July 30, 2021, 17:42		#2
siefer92 Member Join Date: Aug 2017 Posts: 32 Rep Power: 9	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.

July 30, 2021, 17:48		#3
siefer92 Member Join Date: Aug 2017 Posts: 32 Rep Power: 9	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*

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

July 30, 2021, 18:41		#4
siefer92 Member Join Date: Aug 2017 Posts: 32 Rep Power: 9	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.