2018-04-20 11:21 BST

View Issue Details Jump to Notes ]
IDProjectCategoryView StatusLast Update
0002886OpenFOAM[All Projects] Bugpublic2018-04-18 13:18
Assigned To 
PlatformGNU/LinuxOSUbuntuOS Version15.04
Product Versiondev 
Target VersionFixed in Version 
Summary0002886: bug in compressibleInterDyMFoam after removing ddtCorr from MRF
DescriptionI am referencing to the fixed bug 0002824 from 7.2.2018 and the newest commit from 10.2.2018 to pEqn.h with:

- + fvc::interpolate(rho*rAU)*fvc::ddtCorr(U, Uf)
+ + MRF.zeroFilter(fvc::interpolate(rho*rAU)*fvc::ddtCorr(U, Uf))

The changes from 7.2.2018 "Improved conservation for morphing mesh cases" solved the issue in the described bug report 0002824. Unfortunately the changes to MRF with "Remove ddtCorr from MRF regions" reversed it.

I did not have time to investigate deeper into the validation case. I could just observe that with the version from 7.2 it works fine and with a dev-version after 10.2 it gives wrong results as before. With the same case and settings.

Steps To ReproduceOne might use the old validation case from bug report 0002824.
Additional InformationIf required, I will do some tests with the validation case to give some more insights in what's going wrong with the moving mesh part, etc.
Attached Files




henry (manager)

> Unfortunately the changes to MRF with "Remove ddtCorr from MRF regions" reversed it

Does your test-case have an MRF region in it? If not it should not make a difference.

Have you run the case with

    fvc::interpolate(rho*rAU)*fvc::ddtCorr(U, Uf)

rather than

    MRF.zeroFilter(fvc::interpolate(rho*rAU)*fvc::ddtCorr(U, Uf))

If the case does not have an MRF in it this change should not make any difference.


henry (manager)

When you say that

> Unfortunately the changes to MRF with "Remove ddtCorr from MRF regions" reversed it.

could you explain? As far as I can see the changes for report 0002824 are still present in the solver.


arohner (reporter)

Ok. I checked it with reverting the changes from 02.10 and as you said it has no effect, since the model is not using any kind of mrf. I ran the case on two different pc's, one with the version 02.07 and the other with 02.10, but as it seems this is not what produces the difference. Since the case setup is identically it can just be the system, where I am using for both windows sub with ubuntu. I will do further investigations in finding some hints for the difference.


henry (manager)

The cases I have run fine with or without the ddtCorr term and with or without the MRF correction. To investigate this further I will need a specific case with details of the specific problem, at the moment it is just too vague.


arohner (reporter)

Ok. I found the reason for the difference. The last changes to TEqn.H are responsible for it. It seems to overcorrect the pressure term. I will add some diagrams (sim vs. exp) in the next post, where I can show the difference. With the previous version we had quite good agreement to experimental data, but after the changes the pressure amplitude for a specific measurement point dropped for around 300-400 Pa, which has significant impact on the simulation output. I will check the case also with my compressed box case.


henry (manager)

The change to TEqn.H is zero at convergence, i.e. when the contErr -> 0. If this change is affecting your results it is either because you do not have sufficient outer iterations to achieve convergence within the time-step or the iteration sequence is not converging.

The addition of the contErr*K term is obvious as it relates to the transport of K but the addition of the contErr/rho*p is less clear as there is not corresponding time derivative of p, however in the test I have run it improves convergence significantly.


arohner (reporter)

Ok. I can confirm, that with sufficient outer iterations the simulation converges to the same solution as before. Until now the solver has been running in piso mode with automatic adjusting time-step, hence really no outer iterations. I wonder if it was just luck, that we got a correct solution. Using pimple with some outer iterations might be the better way, ensuring, having a converged solution.

Unfortunately I could not manage to set residualControl for the pimple's outer iteration, saying:
"Solution convergence criteria specified in PIMPLE.residualControl must be given as single values. Corrector loop convergence criteria, if appropriate, are specified as dictionaries in PIMPLE.<loopName>ResidualControl."

I didn't find any documentation on how to set it up correct. I know, this is not a question for the bug report, hence I will ask this question elsewhere if you don't find it appropriate to answer here.

Anyway, the bug can be closed and sorry for the inconvenience again.

regards Adrian


henry (manager)

I would recommend fixing the number of outer iterations rather than using the convergence controls and outer iterations are needed to correct the continuity error for compressible VoF.

Could you test the behaviour with and without the two pressure work corrections, in particular are either of them beneficial separately? I would expect the contErr*K term to be fine but I am not sure about the contErr/rho*p term and have only tested it on a limited number of cases.


arohner (reporter)

Ok. I could perform some tests with the old and new version of TEqn.H, but I didn't manage to compile versions where I have only one of the two terms. Just removing 'contErr/rho*p' from fvc::div(fvc::absolute(phi, U), p)() - contErr/rho*p gave an error. How should the line look like with only one of the two terms?


henry (manager)

With both corrections:

      + (
            fvc::div(fvc::absolute(phi, U), p)()() - contErr/rho*p
          + (fvc::ddt(rho, K) + fvc::div(rhoPhi, K))()() - contErr*K

with p correction:

      + (
            fvc::div(fvc::absolute(phi, U), p)()() - contErr/rho*p
          + (fvc::ddt(rho, K) + fvc::div(rhoPhi, K))()() // - contErr*K

with K correction:

      + (
            fvc::div(fvc::absolute(phi, U), p)()() // - contErr/rho*p
          + (fvc::ddt(rho, K) + fvc::div(rhoPhi, K))()() - contErr*K

without correction:

      + (
            fvc::div(fvc::absolute(phi, U), p)()() // - contErr/rho*p
          + (fvc::ddt(rho, K) + fvc::div(rhoPhi, K))()() // - contErr*K


arohner (reporter)

Hi Henry

Attached you find some residual plots with the different solver settings int TEqn.h. The case is a simple compressed cavity with only air inside. In a next test I might check it with two phases, because there we have some convergence issues, when refining the mesh. I didn't have this effect, when I was using the solver in piso mode, so it is somehow related to the pimple loops, but I didn't figure out yet, what drives the solver to blow up.

The discrepancy in the validation plots comes partly from neglecting heat transfer as we assume.


arohner (reporter)

an the files


henry (manager)

Have you drawn any conclusions from these plots?

-Issue History
Date Modified Username Field Change
2018-03-24 14:59 arohner New Issue
2018-03-24 14:59 arohner Tag Attached: compressibleInterDyMFoam
2018-03-24 16:14 henry Note Added: 0009440
2018-03-24 16:19 henry Note Added: 0009441
2018-03-25 11:16 arohner Note Added: 0009443
2018-03-25 11:50 henry Note Added: 0009444
2018-03-26 19:30 arohner Note Added: 0009446
2018-03-26 20:07 henry Note Added: 0009447
2018-03-28 16:11 arohner Note Added: 0009453
2018-03-28 16:28 henry Note Added: 0009454
2018-04-04 07:18 arohner Note Added: 0009468
2018-04-04 20:25 henry Note Added: 0009469
2018-04-18 13:11 arohner File Added: compIntDyFoamSolverCheck.zip
2018-04-18 13:11 arohner Note Added: 0009503
2018-04-18 13:12 arohner File Added: compIntDyFoamSolverCheck-2.zip
2018-04-18 13:12 arohner File Added: compIntDyFoamSolverCheck-3.zip
2018-04-18 13:12 arohner Note Added: 0009504
2018-04-18 13:18 henry Note Added: 0009505
+Issue History