View Issue Details

Jump to NotesJump to History
IDProjectCategoryView StatusDate SubmittedLast Update
0000572OpenFOAMBugpublic2012-07-03 18:282014-02-18 09:05
Reporteruser331Assigned Touser4 
PriorityhighSeveritymajorReproducibilityalways
Status resolvedResolutionfixed 
PlatformLinuxOSOpenSuseOS Version11.4
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.

Activities

user331

2012-07-03 18:28

 

attachDetach.tar.gz (41,337 bytes)

user331

2012-07-17 01:25

  ~0001470

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.

user331

2012-07-19 01:07

  ~0001474

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.

user331

2012-08-18 00:35

  ~0001612

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.

user4

2012-08-20 08:43

  ~0001613

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

user331

2012-08-20 18:36

  ~0001619

Last edited: 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.

user331

2012-09-12 00:49

  ~0001684

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.

user4

2012-09-12 09:46

  ~0001685

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

user331

2012-09-12 18:25

  ~0001686

Last edited: 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();
movePoints(newPoints);

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

user331

2012-09-18 22:58

  ~0001692

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.

user331

2012-11-22 22:14

  ~0001789

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.

user2

2014-02-18 09:05

  ~0002835

Updated in version 2.3.x

Issue History

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