laplacianFoam code verification

wilsonrcf · February 25, 2022, 21:40

Hello guys!

In the past few days I was studding ASME v&v standard. I'm getting my self familiar with code verification with the Method of Manufactured Solution (MMS). So I tried to verify laplacianFoam with this technique.

AFAIK, one prove that the code is verified is if the observed order of convergence approximates the order of the schemes utilized.

In this link (https://drive.google.com/file/d/1ZOe...ew?usp=sharing) you can download a pdf file describing the methodology and the results that I used/got and both cases (using blockMesh and snappyHexMesh)

The observed order of convergence (pobs ~ 1) is lower than the theoretical order (pthe = 2, because Gauss scheme is second order).

I think that the reason for this is a human error (some error in a file) or a misunderstanding (maybe the order of convergence is 1). I would be glad if one of you can take a look in the pdf and in the cases.

Hope we can start a healthy discussion about this subject!

theBananaTrick · February 26, 2022, 13:03

Hi,

Try the solution on a square. If you get 2nd order, take a look at how the Laplacian term is being handled on the boundaries.

Additionally, be reasonable with the values you give to the constants and check if the source term is being correctly implemented.

wilsonrcf · February 26, 2022, 15:16

Hey! Thanks for your time!

I tried the solution in the square (2.7x2.7x1)m. The mesh was made using blockMesh. The results:

L2_coarse (h = 3.375e-02) = 1.485e-03
L2_medium (h = 1.688e-02) = 4.652e-04
L2_fine (h = 8.437e-03) = 3.039e-04

p23_obs =1.675
p12_obs = 0.614

It is not yet a 2nd order. Although p23_obs got closer to that. Can you understand this?

I'm only using one constant: thermal diffusivity. And in the tests that I made, the value doesn't play a big role (provided that transportProperties and fvModels have the same value).

I compared the source values for some cells implemented in fvModels with Octave and it was close to each other.

I don't know how to check the Laplacian term in the boundaries. Can you tell me how?

Again, thank you!

theBananaTrick · February 26, 2022, 17:46

See if this solution works for you:

$T (x,y) =10 + x^{2} + y^{2}$

This way the source term will be:

Use something like $D_T = 1 \times 10^{-5}$

Use all Dirichlet boundaries in a unit square domain (2D).

wilsonrcf · February 26, 2022, 19:36

The verification process aims to "high stress" the code. This is done by choosing complexes functions. I understand that you want to start with a more simple function, but this is illogical in my opinion:
1) If we get a 2nd order, we won't be stressing the code;
2) If we don't get a 2nd order, the problem remains.
But thanks for your tip!

theBananaTrick · February 26, 2022, 19:59

The simpler solution is just for you to check if your overall method is Ok...

wilsonrcf · February 28, 2022, 13:04

Hi all!

As our friend suggested, I tried the solution in a square (trying to keep the mesh representative size constant for each mesh) and the results that I got are in the post #3.

But I decided to try with coarser meshes. I got 2nd observed order. The methodology/results/analysis is in a new file. Here is the link: https://drive.google.com/drive/folde...7i?usp=sharing

If i didn't make any mistakes, the geometry and mesh/subdivision values seems to be bottlenecks for convergence tests in laplacianFoam. That explains why p23_obs got closer to 2nd order in post #3.

Again, I would be glad if you guys would proofread my study so we can get rid of possibles mistakes.

February 25, 2022, 21:40	laplacianFoam code verification	#1
wilsonrcf New Member Wilson Filho Join Date: Dec 2020 Location: Minas Gerais, Brasil Posts: 7 Rep Power: 5	Hello guys! In the past few days I was studding ASME v&v standard. I'm getting my self familiar with code verification with the Method of Manufactured Solution (MMS). So I tried to verify laplacianFoam with this technique. AFAIK, one prove that the code is verified is if the observed order of convergence approximates the order of the schemes utilized. In this link (https://drive.google.com/file/d/1ZOe...ew?usp=sharing) you can download a pdf file describing the methodology and the results that I used/got and both cases (using blockMesh and snappyHexMesh) The observed order of convergence (pobs ~ 1) is lower than the theoretical order (pthe = 2, because Gauss scheme is second order). I think that the reason for this is a human error (some error in a file) or a misunderstanding (maybe the order of convergence is 1). I would be glad if one of you can take a look in the pdf and in the cases. Hope we can start a healthy discussion about this subject!

Similar Threads
Thread	Thread Starter	Forum	Replies	Last Post
water injection error (modify the position of water injection)	wjchoi	Main CFD Forum	0	January 17, 2022 08:17
How to make CFD code architechture flexible enough for future modifications?	aerosayan	Main CFD Forum	6	September 3, 2021 05:35
Fortran->Assembly : How to remove redundant non-vectorized code?	aerosayan	Main CFD Forum	6	November 20, 2020 06:37
The FOAM Documentation Project - SHUT-DOWN	holger_marschall	OpenFOAM	242	March 7, 2013 13:30
Design Integration with CFD?	John C. Chien	Main CFD Forum	19	May 17, 2001 16:56

February 26, 2022, 13:03		#2
theBananaTrick New Member Join Date: Feb 2022 Posts: 25 Rep Power: 4	Hi, Try the solution on a square. If you get 2nd order, take a look at how the Laplacian term is being handled on the boundaries. Additionally, be reasonable with the values you give to the constants and check if the source term is being correctly implemented.

February 26, 2022, 15:16		#3
wilsonrcf New Member Wilson Filho Join Date: Dec 2020 Location: Minas Gerais, Brasil Posts: 7 Rep Power: 5	Hey! Thanks for your time! I tried the solution in the square (2.7x2.7x1)m. The mesh was made using blockMesh. The results: L2_coarse (h = 3.375e-02) = 1.485e-03 L2_medium (h = 1.688e-02) = 4.652e-04 L2_fine (h = 8.437e-03) = 3.039e-04 p23_obs =1.675 p12_obs = 0.614 It is not yet a 2nd order. Although p23_obs got closer to that. Can you understand this? I'm only using one constant: thermal diffusivity. And in the tests that I made, the value doesn't play a big role (provided that transportProperties and fvModels have the same value). I compared the source values for some cells implemented in fvModels with Octave and it was close to each other. I don't know how to check the Laplacian term in the boundaries. Can you tell me how? Again, thank you!

February 26, 2022, 17:46		#4
theBananaTrick New Member Join Date: Feb 2022 Posts: 25 Rep Power: 4	See if this solution works for you: $T (x,y) =10 + x^{2} + y^{2}$ This way the source term will be: Use something like $D_T = 1 \times 10^{-5}$ Use all Dirichlet boundaries in a unit square domain (2D).

February 26, 2022, 19:36		#5
wilsonrcf New Member Wilson Filho Join Date: Dec 2020 Location: Minas Gerais, Brasil Posts: 7 Rep Power: 5	The verification process aims to "high stress" the code. This is done by choosing complexes functions. I understand that you want to start with a more simple function, but this is illogical in my opinion: 1) If we get a 2nd order, we won't be stressing the code; 2) If we don't get a 2nd order, the problem remains. But thanks for your tip!

February 26, 2022, 19:59		#6
theBananaTrick New Member Join Date: Feb 2022 Posts: 25 Rep Power: 4	The simpler solution is just for you to check if your overall method is Ok...

February 28, 2022, 13:04		#7
wilsonrcf New Member Wilson Filho Join Date: Dec 2020 Location: Minas Gerais, Brasil Posts: 7 Rep Power: 5	Hi all! As our friend suggested, I tried the solution in a square (trying to keep the mesh representative size constant for each mesh) and the results that I got are in the post #3. But I decided to try with coarser meshes. I got 2nd observed order. The methodology/results/analysis is in a new file. Here is the link: https://drive.google.com/drive/folde...7i?usp=sharing If i didn't make any mistakes, the geometry and mesh/subdivision values seems to be bottlenecks for convergence tests in laplacianFoam. That explains why p23_obs got closer to 2nd order in post #3. Again, I would be glad if you guys would proofread my study so we can get rid of possibles mistakes.