|
[Sponsors] |
[snappyHexMesh] refine from stl without creating a patch |
|
LinkBack | Thread Tools | Search this Thread | Display Modes |
July 18, 2019, 05:56 |
refine from stl without creating a patch
|
#1 |
Senior Member
|
Hi everyone,
I'm creating a mesh using snappyHexMesh and one of the stl files I use to define the refinement levels should not create a patch (but rather only be used to refine the region). Is that possible? I tried various approaches, and also stitchMesh/mergeMesh and deleting the patch from the boundary file, but nothing does it. At best my refinement region gets totally ignored. Regards, -Louis |
|
August 22, 2019, 08:09 |
|
#2 | |
Senior Member
|
Hello Louis,
There are couple of things you can do. It is strange that your refinement region gets ignored. Double check, the coordinates of your refinement region and also have a look on example tutorial to use refinement region correctly. I used it many time and I don't see any reason for it getting ignored. If you are using stl file to refine mesh, you can use createPatchDict to combine it with neighboring patch. Quote:
|
||
August 28, 2019, 06:39 |
|
#3 |
Senior Member
|
Hi Muhammad,
Thank you for your reply. I was not clear enough: my region gets refined without problem (with stl or boxes/cylinders/etc). My issue is that it always creates a patch in correspondence to the stl file's geometry and I don't want that patch! Kind regards, -Louis |
|
August 28, 2019, 07:18 |
|
#4 | |
Senior Member
|
Hello Loius,
I understood what your concern is. First of all, I never tried this approach (stl file only for refinement purpose without creating patch). You can try by using same name of two stl patches that you want to combine (I am not sure about it as I never tried this). It might work. Quote:
The best approach is to use single stl file for patches and use searchable region for refinement Regards |
||
November 7, 2019, 06:58 |
|
#5 |
New Member
Apostolos
Join Date: Apr 2019
Posts: 1
Rep Power: 0 |
you probably figured it out by now, but the answer is that you should only use your .stl at the refinementRegion entrance and ignore the refinementSurface one
|
|
November 9, 2019, 04:08 |
|
#6 |
Senior Member
|
thanks for the tip, but I am pretty certain that this method will only create a refinement region and no "snapped" surface. I wanted the snapped surface without a patch while I was comparing a case with AMI to one without.
|
|
February 10, 2020, 18:46 |
|
#7 |
Member
benoit paillard
Join Date: Mar 2010
Posts: 96
Rep Power: 16 |
Again, a little late to the party, but I'd say best practice in AMI case is to create two geometry files base on a common rotating boundary, then create two separate meshes, and eventually merge the two meshes into a single case.
I have never seen an AMI case where the meshing is done in a single step. |
|
October 12, 2021, 08:28 |
Using faceType internal
|
#8 |
Member
Wouter
Join Date: Aug 2013
Posts: 41
Rep Power: 12 |
We tried something similar and in the end it worked by doing this:
At the beginning, when declaring the geometry: object.stl { type triSurfaceMesh; object; } Under surface refinement: object faceType internal; faceZone object_zone; It creates 2 complementary patches, but they are not seen as a real wall. Not sure if the faces actually match. If that's required, you could consider using faceType baffle instead? Hope it helps! |
|
Thread Tools | Search this Thread |
Display Modes | |
|
|
Similar Threads | ||||
Thread | Thread Starter | Forum | Replies | Last Post |
[Commercial meshers] Fluent3DMeshToFoam | simvun | OpenFOAM Meshing & Mesh Conversion | 50 | January 19, 2020 16:33 |
steadyUniversalMRFFoam Tutorial fails in MixingPlane | HenrikJohansson | OpenFOAM Bugs | 0 | February 14, 2019 05:48 |
[OpenFOAM.org] Compile OF 2.3 on Mac OS X .... the patch | gschaider | OpenFOAM Installation | 225 | August 25, 2015 20:43 |
[Other] How to create an MRF zone ? | aminem | OpenFOAM Meshing & Mesh Conversion | 2 | December 8, 2014 11:45 |
mapFields : internal edges | Gearb0x | OpenFOAM Running, Solving & CFD | 3 | April 19, 2010 10:02 |