Different pressure values on different machines!

[Mohammad]

Thank you dear Yvan,

A linux expert guy solved it for me!

Regards,
Mohammad

[Mohammad]

Hello,

I noticed that the problem only occurs if I use OMP_NUM_THREADS>1 (bigger than 1) and Neumann boundary condition for the pressure at the outlet(as I mentioned before), this problem occurs and the pressure field overshoots and values for the pressure keep getting bigger and bigger after each iteration.
But if I use OMP_NUM_THREADS=1, this problem won't occur! However, the code gets much slower on my case.
Is this a bug? Is there any fix?
I think it's because of threaded numbering can I set the numbering type to default?

Regards,
Mohammad

[Yvan Fournier]

Hello,

This is interesting. It is probably due to a variable which is shared but should be private on the OpenMP code,
Unfortunately, there are no good tools to debug this, except for a LLVM-based tool (Archer) which requires a local LLVM/clang install, so the usual way to debug this is by bisection: replace hald of #pragma omp (in C) and !omp (in Fortran) with a non-recognized pragma/directive (such as nomp), see if the bug occurs, and switch to the other half, or refine that half... which takes some time.

In your case, if I remember correctly, since it relates to the pressure outlet, the volume of code to check is not too large, so I will take a look, but maybe only in a few days (I have a deadline for a presentation).

In any case, you may try calling cs_renumber_set_algorithm (in cs_user_performance_tuning.c) with b_face_cells_numbering set to CS_RENUMBER_B_FACES_NONE. Chances that this will avoid the bug are not very big, but it can provide additional info.

Best regards,

Yvan

[Mohammad]

Hello,

Thank you dear Yvan, I appreciate your helps.
The CS_RENUMBER_B_FACES_NONE did not help.

But since the bug is not fixed yet, can I implement the homogeneous Neuman B.C for the pressure at the outlet as Dirichlet B.C?
I mean for the 1st order Neumann B.C we have (after discretizing):
P[boundary]=P[last cell]
So I can set the pressure at the boundary as the pressure of the last cell which is connected to the boundary. As codes we have:

Code: Select all

double precision, dimension(:), pointer :: cflnum, per
call field_get_val_s(ivarfl(ipr), per)
...
do ilelt = 1, nlelt
   ifac = lstelt(ilelt)
   itypfb(ifac) = isolib                                                                                                                     
   iel = ifabor(ifac)
   icodcl(ifac,ipr) = 1
   rcodcl(ifac,ipr,1) = per(iel)+p0
   rcodcl(ifac,ipr,2) = rinfin
   rcodcl(ifac,ipr,3) = 0.d0
enddo

If it is OK, then the question is that should I use the relative pressure(p) or total pressure(p+p0) for the boundary?

Regards,
Mohammad

[Yvan Fournier]

Hello,

I am not sure about this. You can already impose a constant Dirichlet value, but if you wan to impose a local value based on the current/previous time step value, I would expect this not to be robust as regards the time step.

If found a possible OpenMP error in the turbomachinery module, and another with the volume average of the pressure when not boundary face has a Dirichlet value (which might be the problem).

Could you test adding the two attached files (or at least the C file if not using the turbo-machinery module) ?

Best regards,

Yvan

[Mohammad]

Hello,

Thanks for your reply.

I don't see any attached files in your reply and I'm not using turbomachinery module.

Today I figured out that another problem is happening!
Few days ago, I just stopped using more than 1 threads and ran the code with OMP_NUM_THREADS = 1 to solve the problem with pressure values.
I noticed that when I use hemogenous Neumann B.C for the pressure at the outlet, whether I use OpenMP or not, the residuals for the pressure equation solver and the value of the outlet mass flow keeps growing up and same happens to the number of iterations for the pressure solver which makes the computation very very time consuming. It starts from 10 iterations for the pressure solver and after 2 or 3 days of simulation, it needs 300 iterations to solve the pressure equation for each time step (and still keeps increasing)! Which makes the simulation impossible. There's no problem with the velocity solver and the solution does not seem to diverge because I checked the calculated values. It just keeps getting slower and slower.

This problem does not happen with Dirichlet B.C for the outlet pressure.
But as I need to compare my results with a paper, I need Neumann B.C to have the same boundaty conditions.

Regards,
Mohammad

[Yvan Fournier]

Hello,

Sorry, I missed a step for the attachment. Here is the one which may affect pressure values.

Regarding your other remark, yes, we have much more robustness/stability issues with free outlet pressure BC's than with Dirichlet BC's. I am not sure it is actually "pure" Neumann BC's, but it is mostly that.

If your mesh has non-orthogonal elements, extruding it near the outlet may help. Also, if this i not a pipe flow, but a domain open on many sides, some other Pressure BC's may be better (such as free inlet/outlet).

Also, the "improved pressure interpolation" (iphydr = 1) option may help in some cases with head loss or stratification (more with results quality than with robustness, and probably with more feedback for RANS than LES)

Best regards,

Yvan

[Mohammad]

Hello,

Thank you dear Yvan,
It seems that your attached file solved the problem!

Please keep in mind to fix this problem in newer versions.

Regards,
Mohammad

[Yvan Fournier]

Hello,

The fix is already commited in the development versions. As a rule, we always try to fix the development versions and merge the fixes in older maintenance branches, so as to avoid old bugs which "reappear" in newer versions.

Glad to confirm the fix works.

Best regards,

Yvan