CFD Online Logo CFD Online URL
www.cfd-online.com
[Sponsors]
Home > Forums > Software User Forums > OpenFOAM > 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

Like Tree1Likes
  • 1 Post By chrisb2244

Reply
 
LinkBack Thread Tools Search this Thread Display Modes
Old   February 25, 2014, 02:50
Default 2D AMR - matching faces that are not refined with refined faces
  #1
Member
 
Christian Butcher
Join Date: Jul 2013
Location: Japan
Posts: 85
Rep Power: 13
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, 13:43
Default
  #2
New Member
 
Tyler V
Join Date: Jul 2012
Posts: 24
Rep Power: 14
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, 02:25
Default
  #3
Member
 
Christian Butcher
Join Date: Jul 2013
Location: Japan
Posts: 85
Rep Power: 13
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, 07:13
Default
  #4
New Member
 
Tyler V
Join Date: Jul 2012
Posts: 24
Rep Power: 14
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 4, 2014, 23:57
Default
  #5
Member
 
Christian Butcher
Join Date: Jul 2013
Location: Japan
Posts: 85
Rep Power: 13
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, 06:56
Default
  #6
New Member
 
Tyler V
Join Date: Jul 2012
Posts: 24
Rep Power: 14
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: 85
Rep Power: 13
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
afrotimy likes this.
chrisb2244 is offline   Reply With Quote

Old   June 14, 2016, 23:29
Default
  #8
Member
 
Francis
Join Date: Jan 2014
Location: Toronto
Posts: 50
Rep Power: 12
afrotimy is on a distinguished road
Quote:
Originally Posted by chrisb2244 View Post
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) dir0 0.0273438 -1.31761e-21) n0 -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 ???
afrotimy is offline   Reply With Quote

Old   June 19, 2016, 22:47
Default
  #9
Member
 
Christian Butcher
Join Date: Jul 2013
Location: Japan
Posts: 85
Rep Power: 13
chrisb2244 is on a distinguished road
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
chrisb2244 is offline   Reply With Quote

Old   June 22, 2016, 00:56
Default
  #10
Member
 
Francis
Join Date: Jan 2014
Location: Toronto
Posts: 50
Rep Power: 12
afrotimy is on a distinguished road
Quote:
Originally Posted by chrisb2244 View Post
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,
afrotimy is offline   Reply With Quote

Reply

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

Thread Tools Search this Thread
Search this Thread:

Advanced Search
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 Off
Pingbacks are On
Refbacks are On


Similar Threads
Thread Thread Starter Forum Replies Last Post
Foam::error::PrintStack almir OpenFOAM Running, Solving & CFD 92 May 21, 2024 07:56
[snappyHexMesh] Add Mesh Layers doesnt work on the whole surface Kryo OpenFOAM Meshing & Mesh Conversion 13 February 17, 2022 07:34
[Other] Mesh Importing Problem cuteapathy ANSYS Meshing & Geometry 2 June 24, 2017 05:29
[snappyHexMesh] No layers in a small gap bobburnquist OpenFOAM Meshing & Mesh Conversion 6 August 26, 2015 09:38
[snappyHexMesh] external flow with snappyHexMesh chelvistero OpenFOAM Meshing & Mesh Conversion 11 January 15, 2010 19:43


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