View Issue Details

IDProjectCategoryView StatusLast Update
0001748OpenFOAM[All Projects] Bugpublic2015-06-19 16:45
Reporteruser528Assigned Tohenry 
Status closedResolutionfixed 
PlatformLinuxOSSUSE Linux Enterprise ServerOS Version11
Product Version 
Fixed in Version 
Summary0001748: rhoCentralFoam: density non-conservation as temperature jump BC
DescriptionIn rhoCentralFoam, if I set zero fixedValue boundary conditions for velocity, and fixed value BC for temperature that does not match the internal temperature, the density flux through that boundary is not zero.
Steps To ReproduceConsider the attached case. Its initial conditions are uniform across all volume, and the boundary conditions are: for velocity, fixedValue zero on all patches; for pressure, zeroGradient on all patches; and for temperature, zeroGradient on two patches and fixedValue with different values on two other patches. The value set for temperature on one patch ("bottom") matches that inside the volume, and the value on the other patch ("top") does not match.

Run rhoCentralFoam on it. For each time step, calculate the integral of density over the volume (I use IntegrateVariables filter in Paraview). This integral changes (increases) substantially over time, showing that density is not conserved, while it should be.

Also, make rhoCentralFoam print its value of "phi" field and notice that its values on the "top" patch are essentially non-zero, thus showing where the density is gained from.
Additional InformationI am not sure that this is indeed a bug in OpenFOAM, maybe I am missing some special boundary condition class to be used in such a situation, but nevertheless my choice of BCs seems rather sensible, and the results do not seem so.

I also have not been able yet to re-run this case on a latest OpenFOAM version.
TagsNo tags attached.



2015-06-16 10:36 (1,175,224 bytes)


2015-06-16 17:06

manager   ~0004960

This issue is a consequence of the outlet fix you proposed:

If this change is reverted the flux through the walls is 0 as it should be.


2015-06-17 08:49

manager   ~0004961

I have added code to ensure fixed value BCs are preserved even with the correction of #1548.

This fix is in OpenFOAM-dev:
commit 0d3bfc0a96bbaf4d549d663f1ddd5c23548c833f

could you test it and if it is satisfactory I will apply it to OpenFOAM-2.4.x.


2015-06-18 09:49


This fix breaks #1548 again for me: the density in the testcase from #1548 again builds up near the boundary there instead of flowing freely.

In fact, I'm afraid this problem can be solved by changing the way the interpolation is done, maybe some corrections to the main solver code is required. Currently I use a rather crude fix of manually setting the flux to zero when the boundary value of velocity is zero:

        phi = aphiv_pos*rho_pos + aphiv_neg*rho_neg;
        // force zero phi on patches where velocity is set to zero
        forAll(phi.boundaryField(), patchi) {
            if (max(mag(U.boundaryField()[patchi])) < 1e-10)
                phi.boundaryField()[patchi] = 0;

but this does not seem reliable or even proper for me.


2015-06-18 10:22

manager   ~0004964

The problem with your #1548 case is that it has a fixed outlet (called inlet) pressure but the outlet flow goes supersonic which is unphysical. Currently the density boundary conditions are inferred from the pressure BCs which means that the outlet density is fixed (but updated due to changes in compressibility). The alternative would be to read the density and obtain the pressure from it; in this case what outlet BC (at the patch called inlet) would you specify for the density?


2015-06-19 15:53


Ok, I will look into this on the following week.


2015-06-19 16:45

manager   ~0004975

#1548 reverted.

Issue History

Date Modified Username Field Change
2015-06-16 10:36 user528 New Issue
2015-06-16 10:37 user528 File Added:
2015-06-16 17:06 henry Note Added: 0004960
2015-06-17 08:49 henry Note Added: 0004961
2015-06-18 09:49 user528 Note Added: 0004963
2015-06-18 10:22 henry Note Added: 0004964
2015-06-19 15:53 user528 Note Added: 0004974
2015-06-19 16:45 henry Note Added: 0004975
2015-06-19 16:45 henry Status new => closed
2015-06-19 16:45 henry Assigned To => henry
2015-06-19 16:45 henry Resolution open => fixed