Mapping of pointFields with topology changes
Hello all,
This question is related to the thread http://www.cfd-online.com/Forums/ope...ent-2-1-x.html, but since this is more general it might not be found later on by interested parties. When a mesh undergoes a topology change, the updateFields() function is called for the mesh classes in a way that should map all fields in the object registry. In testing combinations of mesh topology/movement operations, I've found that only volume and surface fields are mapped by default. The following code calls the functions that should do the mapping: Code:
pointMesh motionUpdate(*this); Code:
Not mapping point<Type>Field <fieldName> since originating mesh differs from that of mapper. Thanks! |
You shouldn't have to worry about this. Point fields should be mapped automatically in the polyMesh::updateMesh(const mapPolyMesh& mpm) member function. Take a look at polyMeshUpdate.C. The pointMesh should automatically map all related pointFields (see pointMesh.C and the pointMeshMapper for details).
|
3 Attachment(s)
Thanks for the reply Sandeep; I assume you are referring to this code snippet:
Code:
// pointMesh I've added the files required to run the case I've been testing it against (I hadn't included a solver; my bad), as well as commented the lines in dynamicMotionSolverRefineFvMesh::refine and unrefine that try to do the mapping. Thanks for the help! |
It appears that MapGeometricFields does a pointer comparison of the mesh returned by the mapper and the mesh defined for the field. Perhaps you could check through gdb to see which one of the two is inconsistent?
Print out the addresses of both the polyMesh and pointMesh objects, and it should become clear. If there's an inconsistency somewhere, then this is surely a bug - possibly due to a polyMesh reference being returned instead of a pointMesh, or something similar. |
Ah.. I get what might be wrong.. You're instantiating a pointMesh within the updateMesh member function within dynamicRefineFvMesh, which destroys itself when the function goes out of scope.
Obviously, any pointField instantiated prior to this call is using a pointMesh registered elsewhere, which is why it doesn't get mapped. You _have_ to use the polyMesh update functionality - there's simple no other way. Hope this helps. |
That makes sense; I was attempting the manual method to provide what is seemingly missing from the code. What is odd is that right after the refinement there is a call to updateMesh(map), which following the chain up should end up in the pointField mapping and execute, even if it only returns that "unable to map" message. I think this may be a bug: will post a report with the relevant files and see what happens.
EDIT: Here is the bug report, if anyone finds anything relevant be sure to share it with the developers: http://www.openfoam.org/mantisbt/view.php?id=638 |
Dear Marco and Sandeep
I am trying to add Mesh refinment to my code using multiDirRefinement. The code is doing the refinment on newMesh which is at the begining the same as mesh . then with changemesh the mesh is changed according to newMesh. Code:
multiDirRefinement multiRef(newMesh, refCells, refineDict); Best Mahdi |
Hello Mahdi,
After calling changemesh, you are returned a mapPolyMesh that needs to be applied to the fields. There should be a member function for your mesh called "updateMesh" that takes as its argument the mapPolyMesh. Have a look at the post earlier up where there is a code snippet for updating the pointmesh. Most meshes that hold data have this member function. |
Dear Marco
Thanks for your answer. I have tried your suggestion. Code:
multiDirRefinement multiRef(newMesh, refCells, refineDict); Code:
#0 Foam::error::printStack(Foam::Ostream&) in "/home/mahdi/OpenFOAM/OpenFOAM-1.7.1/lib/linux64GccDPOpt/libOpenFOAM.so" Mahdi |
Does this happen at the solver step? Check to make sure the fields were actually mapped and then we can see what the problem may be.
|
Dear Marco
Thanks for the reply. Yes its exactly happening at the solver step . field are not mapped as you guessed. but the mesh is refined. Best Mahdi |
Quote:
Dear Marco I have changed the position of the refinement and mapping to after the solution of equations. The data are now mapped. but still there is a problem. I have checked the values for p. some of them are almost NAN and some of them zero. the mapping of the data has problem. and because of that I am receiving the following error. Code:
#0 Foam::error::printStack(Foam::Ostream&) in "/home/mahdi/OpenFOAM/OpenFOAM-1.7.1/lib/linux64GccDPOpt/libOpenFOAM.so" Mahdi |
If p is nan/0 in locations then there is something wrong with the mapPolyMesh that was created. I seem to recall that when using refinement that some of the fields are reconstructed (like flux and such). Have a look at dynamicRefineFvMesh.C (particularly the refine/unrefine functions) to see what else needs to be done to properly map all the fields.
On that subject, is it only p that is mapped improperly, or are other fields still problematic? Good luck, Marco UPDATE: Its been a while, but the bug reported above has been fixed. Coupled with some changes to the pEqn in the engine solvers, layerAdditionRemoval can now be used! You will need to make a new engineMesh class that has the polyTopoChangers included. This is truly awesome! Still trying to get it to work with dynamicFvMeshes, but there appears to be an issue with the thermophysical properties coupling. More updates on other threads as we go. |
Dear Marco
I have checked that the problem is somehow both at p and U. I have doubt as you mention that my map maybe wrong. the mesh modifer that i am using is multiDirRefinment which is using the undoablemeshcutter when doing the refinment on specified direction. the thing is that when doing the refinment with dynamicRefineFvMesh it is using the hexRef8 meshcutter. the diffrence is that the hexRef8 meshcutter will use the poloytopochange (meshmod) as input for mesh refinment. but in the multiDirRefinment it uses the mesh. because of that i use to equal mesh at the beginging to generate the map. doing the refinment on one and the changing the the other according to poloytopochange of the other and creating the map. Code:
multiDirRefinement multiRef(newMesh, refCells, refineDict); ///////////////// MyIcoFoam Code:
interpolating from mesh to meshNew Code:
interpolating from meshNew to mesh Code:
meshToMesh meshToMeshInterpb(newMesh, mesh); Error Code:
#0 Foam::error::printStack(Foam::Ostream&) in "/home/mahdi/OpenFOAM/OpenFOAM-1.7.1/lib/linux64GccDPOpt/libOpenFOAM.so" Code:
I will be thankful if i have your help. Best Mahdi |
1 Attachment(s)
Dear Marco
I have also added #include "CorrectFluxinterpolated.H" to my code according to dynamicRefineFvMesh.C . this code is supposed to check and correct the phi while it is mapped.!!!!? But now just it is correcting the boundary condition and make the value of phi zero. moreover there is still a NAN in one cell surface in phi. Best Mahdi |
Dear Mahdi
I've got the same error info as you said when foam does flux update if my guess is correct after UpdateMesh(map). May I know whether you have fixed the problem or not and how? thanks in advance! Best Regards sxh |
Dear Foamers,
I am struggling with a similar problem for the past few days. My aim is to implement a dynamic mesh into the dsmc Solver, which is able to adapt the mesh to the current flow. Here it is necessary to refine the mesh in specified areas. I have chosen a similar procedure like it is described above. My code looks like: Code:
Then I use the mapPolyMesh to do the mapping. The first part of the function autoMap() looks like: Code:
typedef typename ParcelType::trackingData tdType; Code:
--> FOAM FATAL ERROR: Am I missing some steps? I am happy for any suggestions. Best regards |
All times are GMT -4. The time now is 03:06. |