View Issue Details Jump to Notes ] Issue History ] Print ]
IDProjectCategoryView StatusDate SubmittedLast Update
0000572OpenFOAM[All Projects] Bugpublic2012-07-03 18:282014-02-18 09:05
Assigned Tomattijs 
PlatformLinuxOSOpenSuseOS Version11.4
Product Version2.1.x 
Target VersionFixed in Version2.3.x 
Summary0000572: polyTopoChanger doesn't properly update meshPhi on newly inserted faces
DescriptionIn polyTopoChangers where faces are inserted (eg attachDetach and layerAdditionRemoval), the values of the mesh motion fluxes mesh.phi are incorrectly set. This causes subsequent problems if fluxes are made absolute.
Steps To Reproduce1. Download the attached tarball into $FOAM_RUN
2. Execute the Allwmake script to compile the libraries that make corrections to the transport, turbulence and thermo models, rhoPimpleDyMFoam0 and rhoPimpleDyMFoam1 and adds a topoChangerFvMesh that uses the attachDetach polyTopoChanger. These do not overwrite or conflict with the standard installation.
3. Execute the RunAllCases script to run both incompressible and compressible cases of a Tjunction which is first open, then has a set of faces become internal so as to close one branch.
Additional InformationThe results for each case are summarized:

a) TJunctionOpenFirstIncomp: The incompressible one will run to completion but have unrealistically high values of U at the time of valve closure
b) TJunctionOpenFirstComp0 (uses rhoPimpleDyMFoam0): The first compressible case will crash at valve closure, due to an unrealistically high value of density. rhoPimpleDyMFoam0 uses the same reconstruction of flux as rhoPimpleFoam amd subtracts meshPhi every time. The output files are written after the flux correction, and the meshPhi field will have unphysical values on the boundaries called "top" and "bottom".
c) TJunctionOpenFirstComp1 (uses rhoPimpleDyMFoam1): The second compressible case will run to completion. rhoPimpleDyMFoam1 solver does not subtract the meshPhi contribution from the phi field, though the field will still be written and have the same non-physical values on the "top" and "bottom" boundaries.

Though this case only uses the attachDetach polyTopoChanger, similar behaviour has been seen for layerAdditionRemoval (but only when adding faces).
TagsNo tags attached.
Attached Filesgz file icon attachDetach.tar.gz [^] (41,337 bytes) 2012-07-03 18:28

- Relationships

-  Notes
mturcios (reporter)
2012-07-17 01:25

It seems as though the problem is somewhere in Foam::polyTopoChange::changeMesh OR Foam::polyTopoChanger::changeMesh. The latter calls the former, along with some update functions.
mturcios (reporter)
2012-07-19 01:07

Further inspection of other fields shows that the mapping of all kinds of fields (k, epsilon, nut) is failing on newly created faces. meshPhi was simple the one causing the crash due to major violations of continuity. It seems as if the mapPolyMesh being created and returned in polyTopoChange::changeMesh is not properly handinling newly created faces.
mturcios (reporter)
2012-08-18 00:35

One more interesting note: when calling the polyTopoChange::changeMesh, the behaviour of the mapping for faces that are inserted depends on the inflate argument. When inflate = true (keeping old mesh points), newly inserted faces have unphysical values, whereas when inflate = false, the faces that are deleted give problems.
mattijs (manager)
2012-08-20 08:43

There are two ways of handling inserted and deleted faces. The first one (inflate) adds any faces on top of other ones and is followed by a movePoints to 'sweep' the faces into position. (and vice versa for deletion only allows deletion of zero sized cells). This method is used in layer addition/removal. The second method is where the faces are introduced in the correct position and get explicitly assigned a value by e.g. interpolation (used in e.g. dynamicRefineFvMesh).
mturcios (reporter)
2012-08-20 18:36
edited on: 2012-08-20 20:44

So for the moment there is no way to assign values to the newly created faces via the generated mapping? The movingConeTopo has a call to movePoints and it doesn't get the interpolation on the new faces (unless I don't use inflation, which doesn't make much sense to me in light the new information).

It also occurred to me that the problem could be the insertion of faces from faceZones. Not that I have any evidence, its just that both attachDetach and layerAdditionRemoval do the insertion/deletion from previously defined faceZones.

mturcios (reporter)
2012-09-12 00:49

Wait, Mattijs, I think I misunderstood your answer. So with inflation, faces are not assigned a value, but without inflation faces are assigned a value? If so, then where does the assigning of value occur?

In both situations I've tried, its the updating of meshPhi that causes problems. All the other fields besides meshPhi are tied to fvMesh, whereas meshPhi is part of polyMesh and is the one that causes problems. Whether its the place where the field lives, pointers like with the pointMesh update problem you recently fixed, or even the fact its a surface<Type>Fields is beyond my ability to detect.
mattijs (manager)
2012-09-12 09:46

With inflation the topology change introduces the faces with 0 flux. Then the mesh motion will sweep the faces to the correct posisition, introducing a mesh flux. This mesh flux is used in all discretisation (grad, div etc).
mturcios (reporter)
2012-09-12 18:25
edited on: 2012-09-12 22:00

Thanks Mattijs. By adding the following in attachDetachFvMesh::update after the mesh map is created I can get the attachDetachFvMesh to function properly (the mesh flux on the inserted faces is set correctly to 0).

pointField newPoints = points();

I'm going to see if I can get movingConeTopo to work using this as well.

mturcios (reporter)
2012-09-18 22:58

This particular issue is can now be closed. There are still some issues with the layerAdditionRemoval polyTopoChange, but it'll have to wait while more pressing work occupies me.
mturcios (reporter)
2012-11-22 22:14

For some reason this this now works with fvMesh types, but not dynamicFvMesh types. I can get layers to work with a modified engineMesh class that includes a topoChanger, not a dynamicFvMesh with a topoChanger.

Does this still count as an open issue? I think its been mostly resolved by the fixes from report 653.
andy (manager)
2014-02-18 09:05

Updated in version 2.3.x

- Issue History
Date Modified Username Field Change
2012-07-03 18:28 mturcios New Issue
2012-07-03 18:28 mturcios File Added: attachDetach.tar.gz
2012-07-17 01:25 mturcios Note Added: 0001470
2012-07-19 01:07 mturcios Note Added: 0001474
2012-08-18 00:35 mturcios Note Added: 0001612
2012-08-20 08:43 mattijs Note Added: 0001613
2012-08-20 18:36 mturcios Note Added: 0001619
2012-08-20 18:44 mturcios Note Edited: 0001619 View Revisions
2012-08-20 20:44 mturcios Note Edited: 0001619 View Revisions
2012-09-12 00:49 mturcios Note Added: 0001684
2012-09-12 09:46 mattijs Note Added: 0001685
2012-09-12 18:25 mturcios Note Added: 0001686
2012-09-12 22:00 mturcios Note Edited: 0001686 View Revisions
2012-09-18 22:58 mturcios Note Added: 0001692
2012-11-22 22:14 mturcios Note Added: 0001789
2014-02-18 09:05 andy Note Added: 0002835
2014-02-18 09:05 andy Status new => resolved
2014-02-18 09:05 andy Fixed in Version => 2.3.x
2014-02-18 09:05 andy Resolution open => fixed
2014-02-18 09:05 andy Assigned To => mattijs