CFD Online Logo CFD Online URL
www.cfd-online.com
[Sponsors]
Home > Forums > OpenFOAM Programming & Development

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

Register Blogs Members List Search Today's Posts Mark Forums Read

Reply
 
LinkBack Thread Tools Display Modes
Old   February 25, 2014, 03:50
Default 2D AMR - matching faces that are not refined with refined faces
  #1
Member
 
Christian Butcher
Join Date: Jul 2013
Location: Japan
Posts: 84
Rep Power: 4
chrisb2244 is on a distinguished road
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

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
chrisb2244 is offline   Reply With Quote

Old   March 2, 2014, 14:43
Default
  #2
New Member
 
Tyler V
Join Date: Jul 2012
Posts: 24
Rep Power: 5
tgvosk is on a distinguished road
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.
tgvosk is offline   Reply With Quote

Old   March 3, 2014, 03:25
Default
  #3
Member
 
Christian Butcher
Join Date: Jul 2013
Location: Japan
Posts: 84
Rep Power: 4
chrisb2244 is on a distinguished road
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.
chrisb2244 is offline   Reply With Quote

Old   March 3, 2014, 08:13
Default
  #4
New Member
 
Tyler V
Join Date: Jul 2012
Posts: 24
Rep Power: 5
tgvosk is on a distinguished road
Good luck, it's no easy task. If you get it working, do you plan on sharing the resulting codes?
tgvosk is offline   Reply With Quote

Old   March 5, 2014, 00:57
Default
  #5
Member
 
Christian Butcher
Join Date: Jul 2013
Location: Japan
Posts: 84
Rep Power: 4
chrisb2244 is on a distinguished road
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
chrisb2244 is offline   Reply With Quote

Old   March 5, 2014, 07:56
Default
  #6
New Member
 
Tyler V
Join Date: Jul 2012
Posts: 24
Rep Power: 5
tgvosk is on a distinguished road
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.
tgvosk is offline   Reply With Quote

Old   April 7, 2014, 02:35
Default
  #7
Member
 
Christian Butcher
Join Date: Jul 2013
Location: Japan
Posts: 84
Rep Power: 4
chrisb2244 is on a distinguished road
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
chrisb2244 is offline   Reply With Quote

Reply

Tags
2d amr, cells, faces, neighbour, owner

Thread Tools
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are On


Similar Threads
Thread Thread Starter Forum Replies Last Post
Foam::error::PrintStack almir OpenFOAM Running, Solving & CFD 60 February 14, 2016 17:06
No layers in a small gap bobburnquist OpenFOAM Native Meshers: snappyHexMesh and Others 6 August 26, 2015 09:38
Add Mesh Layers doesnt work on the whole surface Kryo OpenFOAM Native Meshers: snappyHexMesh and Others 8 September 13, 2012 09:28
[Other] Mesh Importing Problem cuteapathy ANSYS Meshing & Geometry 1 June 7, 2012 13:39
external flow with snappyHexMesh chelvistero OpenFOAM 11 January 15, 2010 20:43


All times are GMT -4. The time now is 01:32.