View Issue Details

IDProjectCategoryView StatusLast Update
0002886OpenFOAM[All Projects] Bugpublic2018-04-20 17:19
ReporterarohnerAssigned Tohenry 
PriorityhighSeveritymajorReproducibilityalways
Status resolvedResolutionfixed 
PlatformGNU/LinuxOSUbuntuOS Version15.04
Product Versiondev 
Fixed in Versiondev 
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.
TagscompressibleInterDyMFoam

Activities

henry

2018-03-24 16:14

manager   ~0009440

> 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

2018-03-24 16:19

manager   ~0009441

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

2018-03-25 11:16

reporter   ~0009443

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

2018-03-25 11:50

manager   ~0009444

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

2018-03-26 19:30

reporter   ~0009446

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

2018-03-26 20:07

manager   ~0009447

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

2018-03-28 16:11

reporter   ~0009453

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

2018-03-28 16:28

manager   ~0009454

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

2018-04-04 07:18

reporter   ~0009468

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

2018-04-04 20:25

manager   ~0009469

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

2018-04-18 13:11

reporter  

compIntDyFoamSolverCheck.zip (3,988,006 bytes)

arohner

2018-04-18 13:11

reporter   ~0009503

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

2018-04-18 13:12

reporter  

compIntDyFoamSolverCheck-2.zip (3,988,006 bytes)

arohner

2018-04-18 13:12

reporter   ~0009504

an the files

compIntDyFoamSolverCheck-3.zip (3,988,006 bytes)

henry

2018-04-18 13:18

manager   ~0009505

Have you drawn any conclusions from these plots?

arohner

2018-04-20 13:16

reporter   ~0009507

Honestly, me not really a lot. Res are getting lower with correction than without at least for T. I think I would have to plot them for pimple sub steps as well to see the convergence there in the innner iterations. I migth do this over the weekend as I find time (the weather is too good). We still didn't resolve the problem with using pimple and a refined mesh. At a certain point, sometimes at the beginning of the run sometimes somewhere in between the solver blows up and divergece with a T getting negative. Do you have any idea what this could be in conjunction with mesh refinement?

henry

2018-04-20 17:19

manager   ~0009508

I believe this issue is now resolved.

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
2018-04-20 13:16 arohner Note Added: 0009507
2018-04-20 17:19 henry Assigned To => henry
2018-04-20 17:19 henry Status new => resolved
2018-04-20 17:19 henry Resolution open => fixed
2018-04-20 17:19 henry Fixed in Version => dev
2018-04-20 17:19 henry Note Added: 0009508