BUG: atmBoundaryLayerInlet

Summary

Every write resets z0 value to 0 on atmBoundaryLayerInlet boundaries It will create issue when restarting from certain time step. Found this issue in Openfoam v2012.

Junting Chen

Steps to reproduce

1. in the 0 directory, use z0 of anything. Can be simplest cases.
2. run this simulation to a time step for example 200.
3. vim into the U file in the latest time stamp
4. You will see z0 on the inlet boundary has been reset to 0.

Example case

What is the current bug behaviour?

What is the expected correct behavior?

Relevant logs and/or images

Environment information

• OpenFOAM version : v2012
• Operating system : centos (i dont think it matters)
• Hardware info : VM
• Compiler : gcc

Possible fixes

changed the description

assigned to @kuti

@chen112p , thank you very much for your report.

I can reproduce the issue with turbineSiting tutorial when parallel=on.

Yet can't reproduce it when parallel=off and with the HargreavesWright_2007 tutorial in parallel.

Still searching for the culprit.

Could you please tell me if you observe the issue in your local cases apart from the tutorials?

Hello Kutalmis, yes I found this issue in almost all of my local cases. I don't know if this is a parallelization issue (reconstructPar?). I haven't done any serial simulations with it.

Junting Chen

Hi @chen112p

In the turbineSiting tutorial, at the time of writing, the issue was found to be related to the mixing of the decomposition methods (i.e. hierarchical and ptscotch).

When we modified the tutorial, and changed the Allrun script into the this one, the issue disappeared.

Is there any chance for you to provide us a separate, minimal and reproducible example illustrating the issue, if possible?

Otherwise, since we couldn't pinpoint a general culprit, we need to cease our efforts for this ticket for now.

Many thanks for your understanding and help, highly appreciated.

Hello @kuti. Thanks for responding! On your comment, I did a test and found out this bug only exist when running in the parallel mode. Unfortunately, I cannot open the Allrun script you shared, so I am not sure what modification you have made...

So I prepared a small test case heretest_case_atmBC.7z. If you run the allRun.sh, it will create two partitions and run in parallel mode. After it's completed (at 20th time step), you can vim 20/U and see the "north" boundary condition having z0 of 0. However, in 0/U, the z0 was specified as 0.5m.

Junting Chen

added bug label

changed milestone to %v2112

added community label

added Doing label

At Foam::PatchFunction1Types::ConstantField<Type>::getValue, uniformValue is kept Zero for zero-sized this. 

This overwrites the value of a PatchFunction1 in some parallel configurations.

For example, z0 in atmBoundaryLayer.C, i.e. z0_(PatchFunction1<scalar>::New(pp, "z0", dict)),.

Consider a parallel simulation where the input for z0 for a patch is as follows:

z0 uniform 0.5; or z0 constant 0.5; (note that z0 0.5; works fine due to other constructor paths being followed.)

Assume in one of the partitions, the size of the patch is zero.

If we invoke z0_->writeData(os) ; then z0 is written out for this partition only as z0 constant 0; rather than z0 constant 0.5;. And that seems to be the main problem which manifests itself as the issue reported by this ticket.

Agree. Comment out 'if (len)' in ConstantField::getValue?

I will test the change, but I assume you haven't suggested this as the final solution since removing if (len) may cause other complications. Let's see.. Met dank.

Will tackle this (in develop). Can backport to maintenance branch as the need arises.

assigned to @mark and unassigned @kuti

@chen112p - thanks for noticing this one. It's been there for quite a while, and is (was) most certainly wrong.

As mentioned in the last comment, I will push this into develop in the next while. Assuming that it doesn't show up anything odd, can decide which (if any) maintenance branch may get this as a bugfix.

Is this something that you immediately need in a particular version, or are you content with it going into v2112?

mentioned in commit 8f1bad1c

thanks @mark for asking. It's not really an urgent need. We simply modify the z0 by hand if we need to. It will be great if it's fixed in v2112. Thanks!

Junting

Dear @chen112p ,

Is it possible for you to confirm Mark's fix in the develop branch?

I confirm that the fix resolved the issue.

Thank you.

removed Doing label

Dear @chen112p , please reopen the ticket if the issue persists.

Many thanks.

closed

mentioned in issue #2211 (closed)