|
[Sponsors] |
MultiDirRefinement class Bug on mapping fields |
|
LinkBack | Thread Tools | Search this Thread | Display Modes |
May 29, 2007, 07:59 |
I used the class MultiDirRefin
|
#1 |
Guest
Posts: n/a
|
I used the class MultiDirRefinement in order to refine in 2D a given labelList of cells inside the loop in the main of the solver.
The mesh is refined but it seems that MultiDirRefinement is not capable of mapping the fields to the new mesh? And the mapping failed on the PvPatch.....C for different numbers of points or cells. In the MeshModifiers this is done callinf mesh.update(PolyMorpChange) , but MultiDirRefinement has not got the member to do this. I am using the wrong class? Please I would welcome any advice on this iseus as I have been weeks dealing with this. Thanks Sergio |
|
May 29, 2007, 18:24 |
multiDirRefinement actually lo
|
#2 |
Senior Member
Mattijs Janssens
Join Date: Mar 2009
Posts: 1,419
Rep Power: 26 |
multiDirRefinement actually loops to do multiple cuts (to e.g. do 2x2x2 refinement) and this might not work (multiple refinements in the same time step).
Attached a meshModifier which does errorEstimation and single-cut cell splitting. Untested. Might be a better place to start from. errorDrivenRefinement.C errorDrivenRefinement.H |
|
June 4, 2007, 05:41 |
Dear Mattijs,
In facts multiD
|
#3 |
Guest
Posts: n/a
|
Dear Mattijs,
In facts multiDirRefinement does not work in a single time step, which is a pity. I've tried with errorDrivenRefinement but at first it looked not updated and indeed it was not built in the libraries. You version (thanks) compiled OK and I could introduce into the libraries and as an mesh modifier, which in the original version of Open FOAM is not. I created a new class at the level of the MovinCone....which handles multiDirRefinement class. The result is encouraging, it performs one iteration, refine (even when it does it partitioning the cell in diagonal and not in four (2D)) and it appears to map. But something goes wrong with the pressure and T at one outlet. nan values appeared and the next time step the sover break. Indeed I believe that the solver break in the first iteration after the refinement. I Dont know if I am forgetting to do something after the multiDirRefinement.setRefinement but, in principle it should as it is self-sufficient class.? I can undersand the general dynamic of the refinement but when problems arises is a different story, dont have a clue what some bit of the code does. thanks for your advises Sergio |
|
June 4, 2007, 16:41 |
Hello,
A quick question reg
|
#4 |
Senior Member
Philippose Rajan
Join Date: Mar 2009
Location: Germany
Posts: 552
Rep Power: 25 |
Hello,
A quick question regarding error driven mesh refinement and multi directional mesh refining..... Are these functions implemented particularly for hexahedral meshes, or will they also for example, work on pure tetrahedral meshes? Can I for example split tets, add / remove tets based on cell quality or some specified error during a simulation run? I am very interested in this concept, since I am working with mesh motion, but currently my motion is limited by degrading mesh quality caused by increased skew as the mesh deforms. I use meshes generated by Netgen, which are pure tetrahedral meshes. Have a nice day! Philippose |
|
June 5, 2007, 05:23 |
Hi,
I dont think MultiDirRef
|
#5 |
Guest
Posts: n/a
|
Hi,
I dont think MultiDirRefMesh work straight away inside a time loop to refine on each time step. I tried it given a list of cells to refine and even when the refine is done the mapping is not. I created a new class on the same level as MovingCone to set up DrivenRefError (which is not compiled in v 1.3) and it seems to work but there is another error which I can not identify yet. Apparently, the issue of refinement is not totally solved in Open FOAM. Or at least you have to try hard to get it. |
|
June 5, 2007, 16:28 |
The refinement done is just ce
|
#6 |
Senior Member
Mattijs Janssens
Join Date: Mar 2009
Posts: 1,419
Rep Power: 26 |
The refinement done is just cell splitting with a a plane through the cell centre. This will split e.g. a tet into a triangular-base prism and another tet. Next iteration the cell split might be in another direction and produce even more complex cells.
tet refinement and keeping tets is different. You do not want to introduce a cell centre and decompose a tet into sub tets since this will decrease the tet quality very rapidly. You will have to do refinement based on a set of tets probably. None of this has been coded. The current refinement probably only works well with a rectangular block of hexes since it uses a geometric cut. If you can send me a simple testcase (e.g. the lid-driven cavity) with the errorDrivenRefinment I can have a look at it. |
|
November 19, 2007, 06:19 |
Hi Mattijs,
After a while I a
|
#7 |
New Member
Sergio Ferraris
Join Date: Mar 2009
Posts: 17
Rep Power: 17 |
Hi Mattijs,
After a while I am trying to get back to the refinement/coarsening of dynamical mesh and resumed my crusade for refinement/coarsen. So far, I have the refinement bit working well by an scalar. Now, the coarsening is not working. I am using all the proper classes (Modifiers, etc). At the end I could isolate the problem to this for coarsening: undoableMeshCutter::removeSplitFaces, which uses the class removeFaces. This is done inside the errorDrivenRefinement class and evaluateError class. I can not find any example for removeSplitFaces or removeFaces in the tutorials and/or applications I use the cavity example and the error appears when coarsening happens: --> FOAM FATAL ERROR : Face 589contains vertex labels out of range: 4(-1 105 1 1143 -1) Max point index = 1250 From function polyMesh::polyMesh::resetPrimitives ( const label nUsedFaces, const pointField& points, const faceList& faces, const labelList& owner, const labelList& neighbour, const labelList& patchSizes, const labelList& patchStarts ) in file meshes/polyMesh/polyMesh.C at line 464. It looks as -1 is not proper vertex numbering. I am pretty sure it has to do with removeSplitFaces. Do you have any example for coarsening mesh?. I will open a threat on the forum for more help. Other tip, In ErrorDrivenRefinement I found this and commented for not repacking. ( as a test) It turns out to work OK for refinement/coarsening till a given point where the problem of vertex labelling appears as before (This code was sent by you months ago) // Repack list of cells to refine. List<refinecell> refCells = refPattern.refCells(); label newRefCellI = 0; forAll(refCells, refCellI) { label cellI = refCells[refCellI].cellNo(); //Sergio commented // if (!markedCell[cellI] && (newRefCellI != refCellI)) // { refCells[newRefCellI++] = refCells[refCellI]; // } } Anyway, I have the problem of vertex labels equal -1 after nine iterations with refinement/coarsening. Here it is removing faces but then stops with the same error. Then, I saw this in: void Foam::undoableMeshCutter::updateMesh(const mapPolyMesh& morphMap) { // Update mesh cutter for new labels. meshCutter::updateMesh(morphMap); // No need to update cell walker for new labels since does not store any. // Update faceRemover for new labels faceRemover_.updateMesh(morphMap); if (undoable_) { // Update all live split cells for mesh mapper. updateLabels(morphMap.reverseCellMap(), liveSplitCells_); } } faceRemover_.updateMesh(morphMap) is not implemented and the error I sent you before is related to labelling. Do you think this might be the cause. Honestly, I think this is out of my reach to solve as the internal structure of the mesh and its refinement is a kind of misttery for the end-user even when I tried for a long time. I know it is topic of interest for many users I am willing to produce a tutorial and the code so far implemented by me. Thanks. Regards Sergio |
|
November 20, 2007, 14:28 |
Hi Sergio,
I haven't touche
|
#8 |
Senior Member
Mattijs Janssens
Join Date: Mar 2009
Posts: 1,419
Rep Power: 26 |
Hi Sergio,
I haven't touched that code for ages. The 2x2x2 hex refinement will go out in the next release so been concentrating on that. Can you send code (OF 1.4.1) + simple testcase that fails? |
|
November 21, 2007, 07:00 |
Hi Mattijs,
I've been using
|
#9 |
New Member
Sergio Ferraris
Join Date: Mar 2009
Posts: 17
Rep Power: 17 |
Hi Mattijs,
I've been using v. 1.3 as H.J. told me. ( the latest version). I checked the source in 1.4.1 and it has not changed. These are the files. I introduced a class called ScalarfieldrefFvMesh to handle the refinement and the errorDrivenRefinement modifier. I had to make mesh().moving() = false, because there was an error and doing just refinement set moving()=true. file:///home/sergio/OpenFOAM/OpenFOAM-1.3/applications/solvers/incompressible/ic oFoam2/icoFoam2.tar file:///home/sergio/OpenFOAM/sergio-1.3/run/tutorials/icoFoam/cavity.tar.gz Have a look and tell me what you think. The previous message details what it is happening. |
|
November 21, 2007, 07:16 |
hi,
Sorry, How do you uploa
|
#10 |
New Member
Sergio Ferraris
Join Date: Mar 2009
Posts: 17
Rep Power: 17 |
hi,
Sorry, How do you upload a file? Thanks. Sergio |
|
November 21, 2007, 17:41 |
See http://www.cfd-online.com/
|
#11 |
Senior Member
Srinath Madhavan (a.k.a pUl|)
Join Date: Mar 2009
Location: Edmonton, AB, Canada
Posts: 703
Rep Power: 21 |
See http://www.cfd-online.com/cgi-bin/Op...?pg=formatting for instructions on how to upload a file.
|
|
November 27, 2007, 05:44 |
Dear Matjjis,
I hope this tim
|
#12 |
New Member
Sergio Ferraris
Join Date: Mar 2009
Posts: 17
Rep Power: 17 |
Dear Matjjis,
I hope this time the attached files stay there.! OK. Here we go with my explanation regarding mesh refinement/coarsening: 1) I created a class (ScalarFieldrefFvMesh) which creates the modifier. It is actually an copy from Movingcone (with the necessary changes).it does update and the rest. 2) Following ScalarFieldrefFvMesh adds errorDrivenRefinement as modifier. 3) So, errorDrivenRefinement drives the show. This uses evaluateError and finally the actual cut is done by undoableMeshCutter::removeSplitFaces and the refine method. I believe the error is in removeSplitFaces as I could manage the refine without coarsening without a problem using ani scalar fiels. But when I want to coarse the mesh I got something like this: -> FOAM FATAL ERROR : Face 589contains vertex labels out of range: 4(-1 105 1 1143 -1) Max point index = 1250 From function polyMesh::polyMesh::resetPrimitives ( const label nUsedFaces, const pointField& points, const faceList& faces, const labelList& owner, const labelList& neighbour, const labelList& patchSizes, const labelList& patchStarts ) in file meshes/polyMesh/polyMesh.C at line 464. The error is not always the same and it depends on the number of points in the initial mesh. errorDriventRefinement.tar.gz ScalarFieldrefFvMesh.tar.gz cavity.tar.gz icoFoam2.tar.gz |
|
December 17, 2007, 05:54 |
Hi Markus,
Welcome aboard.
|
#13 |
New Member
Sergio Ferraris
Join Date: Mar 2009
Posts: 17
Rep Power: 17 |
Hi Markus,
Welcome aboard. I've been working on this on and off for the last 5 or 6 months. It is an investment of time and I am pretty on my own as it involves getting deep into the code. Not much help from the forum in this regard. I attended the conference in Zagrev and many people were interested but at the time of coding, again, not much help. How long have you been working with OF? I am working with v. 1.3 from Dr Hazaf repository : http://powerlab.fsb.hr/ped/kturbo/OpenFOAM/ I welcome any sort of help. The version I have working refines the mesh consistently, but it does not coarse the mesh. The files you get are most of the modifications. There is a bug : if you check mesh.move is true when you refines and in the time step this produces and error. I forces mesh.move=false. You have to recompile errorDrivenRefinemt, and add ScalarFieldrefMesh. I could refined the cavity case by the error in the numerical equations. Hope this helps alittle. I copy this to the forum as well. Regards Sergio |
|
|
|
Similar Threads | ||||
Thread | Thread Starter | Forum | Replies | Last Post |
Mapping fields from fvMesh to tetPolyMesh | hannes | OpenFOAM Running, Solving & CFD | 2 | August 28, 2008 06:42 |
How to access solver fields from fvPatchField%2360Type derived class that defines BC | kar | OpenFOAM Running, Solving & CFD | 0 | February 29, 2008 13:41 |
Mapping volsurface symmTensor fields after a topological change | jcmasters | OpenFOAM Bugs | 1 | September 4, 2007 14:48 |
Error after mapping fields | alberto | OpenFOAM Pre-Processing | 0 | November 2, 2006 19:47 |
Mapping fields | hsieh | OpenFOAM Pre-Processing | 3 | September 14, 2005 20:56 |