View Issue Details

IDProjectCategoryView StatusLast Update
0003636OpenFOAMBugpublic2021-03-05 15:26
Reporterpeksa Assigned Tohenry  
PrioritylowSeveritytweakReproducibilityalways
Status resolvedResolutionfixed 
PlatformGNU/LinuxOSUbuntuOS Version15.04
Fixed in Versiondev 
Summary0003636: Use of mesh.dynamic() may return false even if mesh.moving() returns true
DescriptionDear 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
TagsNo tags attached.

Activities

henry

2021-03-05 08:22

manager   ~0011908

It is not clear what code you want changed.

peksa

2021-03-05 08:51

reporter   ~0011909

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()

henry

2021-03-05 09:06

manager   ~0011910

> 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.

peksa

2021-03-05 09:48

reporter   ~0011911

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.

henry

2021-03-05 10:00

manager   ~0011912

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()'.

peksa

2021-03-05 13:01

reporter   ~0011913

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.
freePiston_mod.tar.gz (270,347 bytes)

henry

2021-03-05 13:31

manager   ~0011914

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?

henry

2021-03-05 13:37

manager   ~0011915

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

peksa

2021-03-05 14:52

reporter   ~0011916

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.

Issue History

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