View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0002886 | OpenFOAM | Bug | public | 2018-03-24 14:59 | 2018-04-20 17:19 |
| Reporter | arohner | Assigned To | henry | ||
| Priority | high | Severity | major | Reproducibility | always |
| Status | resolved | Resolution | fixed | ||
| Platform | GNU/Linux | OS | Ubuntu | OS Version | 15.04 |
| Product Version | dev | ||||
| Fixed in Version | dev | ||||
| Summary | 0002886: bug in compressibleInterDyMFoam after removing ddtCorr from MRF | ||||
| Description | I 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 Reproduce | One might use the old validation case from bug report 0002824. | ||||
| Additional Information | If 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. | ||||
| Tags | compressibleInterDyMFoam | ||||
|
|
> 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. |
|
|
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. |
|
|
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. |
|
|
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. |
|
|
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. |
|
|
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. |
|
|
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 |
|
|
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. |
|
|
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? |
|
|
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 ) |
|
|
|
|
|
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. |
|
|
|
|
|
an the files |
|
|
Have you drawn any conclusions from these plots? |
|
|
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? |
|
|
I believe this issue is now resolved. |
| 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 |
