laplacianFoam code verification
 

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!

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.

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!

See if this solution works for you:




This way the source term will be:




Use something like

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

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!

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

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.