2D AMR - matching faces that are not refined with refined faces
 

As the title suggests, I'm having difficulties matching up the faces of refined cells with those faces on adjacent cells which are not refined in a given step.

In 3D, this results in 4 faces in the refined cell being in the same place as one face for the non-refined (as opposed to unrefined, which might imply something else in this context) cell. This satisfies the 2-1 requirement.

In 2D, I have 2 faces in the refined cell which I'm trying to match up to one face in my non-refined cell.

I attach two screenshots generated with paraview, showing a 'surface with edges' image, and a 'wireframe' image. They are from a mesh which was initially 5x12x1, and has been refined to (5x4 + 10x8 + 5x4)x1, that is, the central 4 rows have been refined to a 10x8 region.

http://s12.postimg.org/f9n3y2max/Wireframe.png
http://s12.postimg.org/87p6bvip5/Surface_With_Edges.png

http://s12.postimg.org/f9n3y2max/Wireframe.png
http://s12.postimg.org/87p6bvip5/Surface_With_Edges.png

Does anyone know how to match these up in a way that they don't create these strange edges across the faces?

Currently I'm adding the midpoint (a fifth vertex) to the faces on the top and bottom, and I have two faces (each with 4 points, two of which are shared) on the refined cell's face towards the non-refined cell.

Any help or thoughts would be much appreciated

If you are referring to the diagonal lines across your cell faces in the images you shared, those are purely a post-processing/visualization artifact of paraview, not actual edges in your mesh. If you run a 3D case with dynamicRefineFvMesh you will see the same things.

How much did you have to redefine to get 2D refinement to work? I have considered trying to define a "template<int D> class hexRefD" so 2D refinement would work more seamlessly (hexRefD<2> or hexRefD<3>), but haven't put any work into it.

I'm just ironing out some problems I'm having with the renumbering and organising of cells into the second timestep at the moment - Learning about the refinementHistory class is interesting although mostly not that important to the cutting of the mesh, it seems.

In my first attempt (which worked for the first iteration, but not for the second) I had a switch (case 0-3) for each face which was not a front or back face, to cut for internal faces. I have now found that just creating a vector from cellCentres()[cellI] and faceCentres()[faceI] is significantly easier and also fortunately more portable. Boundary cells also seem to need some swapping of vertices since they appear in a different order to internal cells.

Essentially, my problems lie in taking the points using the available functions and organising them in the correct order, whilst trying to minimise the number of exceptions I have to handle.

The two main sections of code I've written were a new createInternalFaces function, and a near duplicate section 2 (as labelled in hexRef8.C), "faces that do not get split but use edges that get split". There, whilst the front and back faces behave in the same was as in 3D (since they have 4 faces from 1, and go to one face as 2-1 refinement), the side faces are different entirely.

I've written two functions to handle the pair of faces created, each taking a DynamicList<label> of points that the new (half area) face should be bounded by. For half of these (the first function), getFaceNeighbours(..) is fairly accurate, for the other function lots of changes need to be made since the new owner and neighbour cells don't exist in the time step that the mesh_ holds. (This isn't necessary for 3D, since there faces are either split 4 ways by section 1, or the faces are internal (section 4). Normally section 2 just handles the boundaries where refinement changes, afaict, but I needed something for faces external to individual cells, but internal to the mesh.)

Boundaries are easier, since nei = -1 and own can be set using cellAddedCells and a direction of the faceNormal.

Good luck, it's no easy task. If you get it working, do you plan on sharing the resulting codes?

It seems like my setRefinement and accompanying functions now work properly - got to cells with cellLevel of 5 with no problems and the solver continued to run happily.

Now going to work on the unrefinement, which currently just selects faces to unrefine, then prints out the size of the list, but does nothing (I have commented out the call to the equivalent of dynamicRefineFvMesh::unrefine)

I'll also go back through my refinement code, clear up comments, remove error messages to the effect of "Pout<< "wtf?" << endl;" and replace them with more informative errors, etc, then I can zip it up and upload it here?

I don't know how long the unrefinement changes will take (I'm optimistic, but I was optimistic about the refinement too...) but I can either upload the library with commented out unrefinement, or wait until I finish - let me know.

Here's a picture of the mesh as a surface with edges:


Best wishes

Great! Does it work in parallel too?

As far as sharing the codes once the unrefinement part is done, you can upload a zip file here but I have not done so. I usually just use Github so I can make updates as-needed.

So, it's taken some time - I've been working on some pipe flows, but it seems like I'm not getting any further with the problems here quickly.

As such, I've uploaded the source files (including a class to regenerate the alpha1 file used to refine the mesh before the time step starts) to github, but I expect it may be some (hopefully short, but clearly it hasn't been so far!) time before I have it working nicely.

The code is now written for OF-2.3.0 but I think for 2.2.2 the only change is in the naming of the alpha files (alpha1 in OF-2.2.2, alpha.PHASENAME in OF-2.3.0, alpha.water here) and the use of fvc::ddtCorr instead of fvc::ddtPhiCorr (taking the same arguments iirc).

Repository is at https://github.com/chrisb2244/2D-AMR-OFlib - feel free to take a look if you're interested, or to wait on updates here suggesting it might work better :)

Current problems seem to involve nan values appearing (the number being proportional to number of cells refined) within the internal fields for surfaceVectorFields used correcting the interface by interDyMFoam (and myInterDyMFoam) in particular `gradAlphaf'

Best wishes, and I will improve this asap.
Christian

Hi Foamers,

I found this great contribution to dynamicRefineFvMesh in 2D instead of 3D.

Although, I am not sure if Chris was able to complete the code at https://github.com/chrisb2244

I am having this error message with the code and would really appreciate it if you can assist:-

/************************************************** ***********/
Checking internal orientation
cell: 1024
old face: 2080
newFace: 4(2181 2261 2626 2530)
compactFace: 4(0 1 2 3)
coords: 4((-0.0625 -0.078125 -0.01) (-0.0625 -0.078125 0.01) (-0.0703125 -0.078125 0.01) (-0.0703125 -0.078125 -0.01))
ownPt: (-0.0644531 -0.0917969 5.0822e-19)
neiPt: (-0.0644531 -0.0644531 5.06902e-19)
n: (0 -0.00015625 0)
dir: (0 0.0273438 -1.31761e-21)
dir&n: -4.27246e-06


--> FOAM FATAL ERROR:
cell:1024 old face:2080 newFace:4(2181 2261 2626 2530)
coords:4((-0.0625 -0.078125 -0.01) (-0.0625 -0.078125 0.01) (-0.0703125 -0.078125 0.01) (-0.0703125 -0.078125 -0.01)) ownPt:(-0.0644531 -0.0917969 5.0822e-19) neiPt:(-0.0644531 -0.0644531 5.06902e-19) dir:(0 0.0273438 -1.31761e-21) n:(0 -0.00015625 0)
Direction from ownPt to neiPt was opposite to face normal

From function checkInternalOrientation(..)
in file hexRef4/hexRef4Include/checkInternalOrientation at line 30.



/************************************************** ************/

How can I correct the faceNormal n and direction of the onwer and neighbour cells ???

Hi,

Glad you're finding this (partly?) useful. Sadly, I haven't done anything with it for a long time and it has quite a few problems (see the readme for a ToDo list, probably none of which has been done since).

Regarding the ownPt -> neiPt issue, there's a file labelled 'toggle_Explanation.txt' or similar, which describes the issue you're facing. I don't know what causes it, but switching the value of 'toggle' in your dynamicMeshDict should fix it (i.e., if it currently is set to "toggle = 1", change it to "toggle = 0", or vice-versa)

Best wishes and if it works for you, great!

Christian

Hi Chris,

Thanks for your response.

Switching on the toggle actually worked. Meanwhile I ran into another problem after 24 iterations:-

--> FOAM FATAL ERROR:
The list of paired faces does not have the same number of entries as the value of numPairedFaces.
numPairedFaces = 8
pairedFaces = 24.

I noticed that this was from your myCombineFaces function. When I re-coded your myCombineFaces() function, the problem vanished and I got proper pairing but still failed due to Segmentation fault (core dumped).

I think you have really gone far on this code but don't just know why it originally constrained to 3D simulation by Openfoam. I think they should try to work release another version of dynamiRefineFvMesh with the option of 2D or 3D selection in hexRef.

I will really appreciate any guidance from you Chris.

Rgds,