View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0003636 | OpenFOAM | Bug | public | 2021-03-05 08:09 | 2021-03-05 15:26 |
| Reporter | peksa | Assigned To | henry | ||
| Priority | low | Severity | tweak | Reproducibility | always |
| Status | resolved | Resolution | fixed | ||
| Platform | GNU/Linux | OS | Ubuntu | OS Version | 15.04 |
| Fixed in Version | dev | ||||
| Summary | 0003636: Use of mesh.dynamic() may return false even if mesh.moving() returns true | ||||
| Description | Dear developers, First, this is not a bug as such, but I'm reporting the finding to prevent future bugs in mesh motion context. I have been developing a rather specific solver which has actually a similar layout to engineMesh class and incorporates a simple mesh motion step, similar to 'layered' method in engine class. In other words, no dynamicMesh class is generated but movePoints() is called for the original mesh. When such an approach is used together with e.g. recent pressure equation formulation where "fvc::correctRhoUf" is called, one finds that the correction is never reached because it is guarded by a if(mesh.dynamic()) condition which does not hold true in this rather specific case. In order to reach better consistency and to avoid potential bugs related to e.g. engineFoam, one should incorporate mesh.moving() as a condition to such mesh motion checks. Best regards, -peksa | ||||
| Tags | No tags attached. | ||||
|
|
It is not clear what code you want changed. |
|
|
fvc::correctRhoUf() function was the one from which I realised this discrepancy but probably it appears elsewhere as well. In other words, because mesh.dynamic() returns false, that rhoUf correction may not be executed even though mesh has actually moved by explicit movePoints() command outside dynamicMesh class. Particular action: change mesh.dynamic() --> mesh.moving() in fvc::correctRhoUf() |
|
|
> Particular action: change mesh.dynamic() --> mesh.moving() in fvc::correctRhoUf() It is necessary to know that the mesh will move rather than it has moved which is why "mesh.dynamic() " is used here rather than "mesh.moving()" which is not true until the motion has occurred. |
|
|
That's a good point! Perhaps a combination (mesh.dynamic() || mesh.moving()) would be relevant? In the end this is a problem only if there is any implementation deforming the mesh outside dynamicMesh class. At the moment I don't see anything else than the engine class doing that so we're safe in that regard. |
|
|
The purpose of the 'mesh.dynamic()' method is to declare that the mesh might change. Can you please provide a simple test-case which demonstrates the problem? Without it I cannot work on this any further as we have no cases showing any problem with 'mesh.dynamic()'. |
|
|
Ok, I came up with somewhat an example case by combining freePiston and aachenBomb tutorials. Case is attached. The idea is that if you run this with coldEngineFoam, the solver will consider the "rhoUf" correction and its found from the results folders. However, if you run the case with "engineFoam" which utilises "createRhoUfIfPresent.H" and pEqn.H from sprayFoam solver, this correction is NOT carried out and you can't find the rhoUf field either because mesh.dynamic() guard prevents its creation and usage in the corresponding "createRhoUfIfPresent.H" and "pEqn.H" files. In this particular case, both solutions run without crash but this just highlights the inconsistent behaviour. |
|
|
I have just downloaded the case and run it and I see no problem, what do I need to do to is to see a problem? |
|
|
Try with commit d4d21c9c04958b373904f1363770cab5b4386219 (HEAD -> master, origin/master, origin/HEAD) Author: Henry Weller <http://cfd.direct> Date: Fri Mar 5 13:36:06 2021 +0000 engineMesh: Added dynamic() member function |
|
|
Hey, Yes, there was not supposed to be any "problems" but the case was just to indicate the missing rhoUf, which may lead into severe problems in certain cases as I myself experienced lately in a more complicated case. Regarding the commit, yes, it fixes the issue with the engineMesh class and I'm satisfied with it. Now this discussion and that commit serves as an example for other users/developers that dynamic() virtual function should be implemented whenever you deal with mesh motion outside dynamicMesh class. Have a nice weekend. |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2021-03-05 08:09 | peksa | New Issue | |
| 2021-03-05 08:22 | henry | Note Added: 0011908 | |
| 2021-03-05 08:51 | peksa | Note Added: 0011909 | |
| 2021-03-05 09:06 | henry | Note Added: 0011910 | |
| 2021-03-05 09:48 | peksa | Note Added: 0011911 | |
| 2021-03-05 10:00 | henry | Note Added: 0011912 | |
| 2021-03-05 13:01 | peksa | File Added: freePiston_mod.tar.gz | |
| 2021-03-05 13:01 | peksa | Note Added: 0011913 | |
| 2021-03-05 13:31 | henry | Note Added: 0011914 | |
| 2021-03-05 13:37 | henry | Note Added: 0011915 | |
| 2021-03-05 14:52 | peksa | Note Added: 0011916 | |
| 2021-03-05 15:26 | henry | Assigned To | => henry |
| 2021-03-05 15:26 | henry | Status | new => resolved |
| 2021-03-05 15:26 | henry | Resolution | open => fixed |
| 2021-03-05 15:26 | henry | Fixed in Version | => dev |
