CFD Online Discussion Forums

CFD Online Discussion Forums (https://www.cfd-online.com/Forums/)
-   OpenFOAM Meshing & Mesh Conversion (https://www.cfd-online.com/Forums/openfoam-meshing/)
-   -   [snappyHexMesh] snappyHexMesh doesnt snap (https://www.cfd-online.com/Forums/openfoam-meshing/104855-snappyhexmesh-doesnt-snap.html)

Turbulence July 29, 2012 09:47

Hi Bruno :)

Thanks for the link. I tried various geometries and tried to vary the wall thickness and all, but found that the problem is geometry independent.
I resolved this problem by altering the grading of background mesh. :D
I made sure that the background mesh of big cylinder doesnot intersect my inlet pipe. Please look at the images attached.:)

Thank You everyone for your valuable suggestions :D
Turbulence.

Turbulence July 29, 2012 09:51

2 Attachment(s)
Thank YOU :)

hfs October 31, 2012 03:35

3 Attachment(s)
Quote:

Originally Posted by wyldckat (Post 373530)
Hi Turbulence,

I won't be able to look at this anytime soon... maybe this weekend. But in the meantime, I've picked up on this post:

The full link to where the tutorial is: http://www.openfoamworkshop.org/2012...enedeVilliers/

Best regards,
Bruno


Hello Bruno,

I am trying to get SHM snapping to my STL surface (see attachments). I have tried a lot and read a lot of solutions..
I have tried to play around with snapping parameters ... I increased snapping iterations (5000 iterations) ... I have disabled all snapping controls ... tried feature edge handling ... createBuffles command ... etc.

I have learn from this thread (http://www.cfd-online.com/Forums/ope...tml#post383012)... and it improved a bit (see attached photo) .. but still poor snapping

Same message: Did not successfully snap mesh. Giving up...

It would be really nice if you took a look and give me your advice

Attached are Photo of STL, photo of the snapped mesh, and the triSurface folder.
from here you can download the case:
http://dl.dropbox.com/u/32336583/Case.zip

Really appreciate your guidance!

Kind Regards,

hfs October 31, 2012 05:37

a little detail on how Umb patch is generated in my case

I got Umb patch from an STL file... this is what I did

1-Extracted the geometry from the STL and convert it to emesh using the command: surfaceFeatureExtract -includedAngle 150 -writeObj constant/triSurface/Umb.stl Umb

2-Duplicated edges in emesh (simply by copy-pasting) as recommended here (http://www.cfd-online.com/Forums/ope...rane-edge.html)

3-Converted this emesh file to faceZones by adding faceZone Umb; cellZone Umb; cellZoneInside inside; to snappyHexMeshDict as follows:

refinementSurfaces
{
Umb
{
// Surface-wise min and max refinement level
level (2 2);
faceZone Umb;
cellZone Umb;
cellZoneInside inside;
}
}


4- After the SHM, I converted this faceZones into Patches using the command: createBaffles Umb '(Umb Umb)'


Thanks in advance for your advice

hfs October 31, 2012 07:41

Quote:

Originally Posted by hfs (Post 389413)
Hello Bruno,

I am trying to get SHM snapping to my STL surface (see attachments). I have tried a lot and read a lot of solutions..
I have tried to play around with snapping parameters ... I increased snapping iterations (5000 iterations) ... I have disabled all snapping controls ... tried feature edge handling ... createBuffles command ... etc.

I have learn from this thread (http://www.cfd-online.com/Forums/ope...tml#post383012)... and it improved a bit (see attached photo) .. but still poor snapping

Same message: Did not successfully snap mesh. Giving up...

It would be really nice if you took a look and give me your advice

Attached are Photo of STL, photo of the snapped mesh, and the triSurface folder.
from here you can download the case:
http://dl.dropbox.com/u/32336583/Case.zip

Really appreciate your guidance!

Kind Regards,



I got an answer here:
http://www.cfd-online.com/Forums/ope...e-failure.html

Thanks Forum! :)

holodeck10 November 9, 2012 07:17

snappy doesnt snap
 
4 Attachment(s)
Hello!
I am having a problem with the snapping of nodes onto a cylinder surface when using snappyHexMesh. I tried all the hints in this threat, which do not help in my case. I further tried closed cylinders in a fully surrounding blockMesh, from which I cut the part I am interested in: Nothing works. I am really frustrated. can someone help me, please?

I attach the case including bash script, which​ should illustrate the method I am trying to apply. I further attach some mesh scenes:
- refined blockMesh with cylinder surface (stl file),
- the castellated mesh with cylinder surface and
- the snapped mesh with cylinder surface.
I tried to modify any of the parameters. So far it seems to me, that using explicit feature edge refinement does not help and regionwise refinement eitern. Further, increasing iterations in the snapControls section and decreasing tolerance does not improve the result eiter. I have no idea what to try. Any advice is highly appreciated!
Best regards
Stefan

David* November 9, 2012 08:23

Hi Stefan,

try it again using feature edge refinement and check the .eMesh-File with paraview beforehands. Increase the level of feature refinement. I had a similar problem but fixed it with this. The main difference is that I use the edge of a closing area on top of the cylinder, not of the cylinder itself, maybe it's important.
I guess it's on purpose that feature edge is commented and the .eMesh is zipped in your uploaded files?

Regards,
David

holodeck10 November 11, 2012 05:29

2 Attachment(s)
Hi David,

thank you very much for your reply. I tried to follow your recommendations. First I must admit, that I could not load constant/trisurface/cylinder.emesh (not the packed and neither the unpacked one). At least I dont know, which filter to use. I could load cylinder_edgeMesh.obj, cylinder_openEdges.obj and cylinder_regionEdges.obj. I further extracted the coordinates from the eMesh file. All looks good to me (see 20121111_4cylinder.eMesh_points.png). The points lie on the edges and their number corresponds to the blockMesh resolution (see 20121111_4.png). I refined the blockMesh a little further. I think it is ok to be able to represent the geometry (it is actually a bit finer than in the flange case, mentioned previously in this threat).

The *.eMesh file has been gzipped because I set writeCompression compressed in the system/controlDict.

As recommended in several tutorials, I extended the cylinder length so that it pierces out of the blockMesh in order to improve the upper and lower edges. That's why, I don't have closing areas for the cylinder. Following your recommendation, I tried to use a cylinders which has been closed with new geometry at teh top and at the bottom. The grid looks a bit different there, but it does not solve the problem (I don't attach the figure).

:-(

Best regards
Stefan

David* November 13, 2012 11:08

Hi Stefan,

you're right, the .eMesh cant be opened, but the .obj-Files should do as well to check whether the creation of the edges was successful.

I really don't know why it doesnt work for you, sorry. Last thing you could try is

Quote:

I use the edge of a closing area on top of the cylinder, not of the cylinder itself
They should be identical, but you never know ;)

Regards,
David

holodeck10 November 15, 2012 22:22

1 Attachment(s)
I found a solution, finally. Two things should be changed in my case:

1) The stl surface should surround the numerical domain instead of the cylinder to cut out.
2) Unfortunatelly, refineMesh cannot be applied in zones where it touches the stl file (see attached figure). This would lead to an error message.

I try to find a workaround for beeing still able to apply refineMesh in order to change the aspect ratio of cells, e.g. by generating a larger mesh and cutting the interesting part out afterwards.

Hope this is of use for you as well. Thanks to all who dedicated their time to my problem!

Cheers
Stefan

Claudio87 August 14, 2013 11:32

similar problem
 
Dear Foamers,

I opened a new thread about a similar problem with snappy, here:

http://www.cfd-online.com/Forums/ope...tml#post445745

As you can read, I tried many kind of combinations (in the blockMeshDict and in the sHMDict, expecially in refinementSurface and snapControls), but it seems that I'm not able to do the snap stage :( .
So, if someone of you could help me (here or on my new thread) I would be very happy. I looked around in the forum, for a solution, but till now nothing seems working!

Many thanks in advance!

Best regards,
Claudio

chery1986 March 18, 2014 03:41

3 Attachment(s)
I have similar problem, snap doesn't work. The attachment shows the mesh generated by sHM (first figure) and stl file (second). There is step mesh on one cylinder, but there is no problem with another. Anyone got idea to fix the problem? Case folder and Allrun script is also attached. I'm using OF2.1.1

sHM Attachment 29428

stl Attachment 29429

Attachment 29430

problem solved now, mistakes in blockMeshDict where boundary should not be empty in one direction. Otherwise, snappyHexMesh will treat it as a 2D case. Also see this post http://www.cfd-online.com/Forums/ope...ped-cells.html

Quote:

Originally Posted by holodeck10 (Post 391239)
Hello!
I am having a problem with the snapping of nodes onto a cylinder surface when using snappyHexMesh. I tried all the hints in this threat, which do not help in my case. I further tried closed cylinders in a fully surrounding blockMesh, from which I cut the part I am interested in: Nothing works. I am really frustrated. can someone help me, please?

I attach the case including bash script, which​ should illustrate the method I am trying to apply. I further attach some mesh scenes:
- refined blockMesh with cylinder surface (stl file),
- the castellated mesh with cylinder surface and
- the snapped mesh with cylinder surface.
I tried to modify any of the parameters. So far it seems to me, that using explicit feature edge refinement does not help and regionwise refinement eitern. Further, increasing iterations in the snapControls section and decreasing tolerance does not improve the result eiter. I have no idea what to try. Any advice is highly appreciated!
Best regards
Stefan


aldo.iannetti August 8, 2014 19:59

snappyHexMesh failure
 
1 Attachment(s)
Hi guys
Please see the attached picture.
Could you please tell me why on earth in my simple geometry I have good quality surfaces along with surfaces where the snap clearly fails?
Any suggestion on which parameter in snappyHexMeshDict to adjust to fix the problem?
Cheers

wyldckat August 11, 2014 10:29

Greetings Aldo,

:eek: With the amount of information you've provided, you're certainly asking for a solution that can only be deduced with the assistance of a magic crystal ball :rolleyes: ;).

Since I have to guess, I would say that the maximum local and global number of cells are not making sense, which leads snappyHexMesh to stop attempting at refining and cutting cells, which would increase the cell count, therefore it stops with the last known sane-looking mesh for the requested maximum cell count.

Best regards,
Bruno

mark_CFD_wind June 8, 2015 10:03

Hi All,

New to OpenFoam!

Ive been trying to run the turbineSiting scenario on different locaiton. I managed to include a separate STL file for the terrain and this looks well mashed.

However I am finding it nearly impossible to enter a searchable box.

codes are:

Quote:

/*--------------------------------*- C++ -*----------------------------------*\
| ========= | |
| \\ / F ield | OpenFOAM: The Open Source CFD Toolbox |
| \\ / O peration | Version: 2.3.0 |
| \\ / A nd | Web: www.OpenFOAM.org |
| \\/ M anipulation | |
\*---------------------------------------------------------------------------*/
FoamFile
{
version 2.0;
format ascii;
class dictionary;
object blockMeshDict;
}
// * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * //

convertToMeters 1;

vertices
(
(205500 666800 0)
(218800 666800 0)
(218800 679800 0)
(205500 679800 0)
(205500 666800 800)
(218800 666800 800)
(218800 679800 800)
(205500 679800 800)
);

blocks
(
hex (0 1 2 3 4 5 6 7) (50 50 30) simpleGrading (1 1 1)
);

edges
(
);

boundary
(
outlet
{
type patch;
faces
(
(1 2 6 5)
);
}
sides
{
type patch;
faces
(
(1 5 4 0)
(3 7 6 2)
);
}
inlet
{
type patch;
faces
(
(0 4 7 3)
);
}
ground
{
type wall;
faces
(
(0 3 2 1)
);
}
top
{
type patch;
faces
(
(4 5 6 7)
);
}
);

mergePatchPairs
(
);


// ************************************************** *********************** //
Quote:

/*--------------------------------*- C++ -*----------------------------------*\
| ========= | |
| \\ / F ield | OpenFOAM: The Open Source CFD Toolbox |
| \\ / O peration | Version: 2.3.0 |
| \\ / A nd | Web: www.OpenFOAM.org |
| \\/ M anipulation | |
\*---------------------------------------------------------------------------*/
FoamFile
{
version 2.0;
format ascii;
class dictionary;
object snappyHexMeshDict;
}

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

// Which of the steps to run
castellatedMesh true;
snap true;
addLayers true;


// Geometry. Definition of all surfaces. All surfaces are of class
// searchableSurface.
// Surfaces are used
// - to specify refinement for any mesh cell intersecting it
// - to specify refinement for any mesh cell inside/outside/near
// - to 'snap' the mesh boundary to the surface
geometry
{
windTurbine1
{
type searchableBox;
min (214660 673283 385);
max (214670 673293 395);
}

windTurbine2
{
type searchableBox;
min (214330 673033 385);
max (214340 673043 395);
}

use2.stl
{
type triSurfaceMesh;
name terrain;
}
};



// Settings for the castellatedMesh generation.
castellatedMeshControls
{

// Refinement parameters
// ~~~~~~~~~~~~~~~~~~~~~

// If local number of cells is >= maxLocalCells on any processor
// switches from from refinement followed by balancing
// (current method) to (weighted) balancing before refinement.
maxLocalCells 100000;

// Overall cell limit (approximately). Refinement will stop immediately
// upon reaching this number so a refinement level might not complete.
// Note that this is the number of cells before removing the part which
// is not 'visible' from the keepPoint. The final number of cells might
// actually be a lot less.
maxGlobalCells 2000000;

// The surface refinement loop might spend lots of iterations
// refining just a few cells. This setting will cause refinement
// to stop if <= minimumRefine are selected for refinement. Note:
// it will at least do one iteration (unless the number of cells
// to refine is 0)
minRefinementCells 0;

// Allow a certain level of imbalance during refining
// (since balancing is quite expensive)
// Expressed as fraction of perfect balance (= overall number of cells /
// nProcs). 0=balance always.
maxLoadUnbalance 0.10;


// Number of buffer layers between different levels.
// 1 means normal 2:1 refinement restriction, larger means slower
// refinement.
nCellsBetweenLevels 1;



// Explicit feature edge refinement
// ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

// Specifies a level for any cell intersected by its edges.
// This is a featureEdgeMesh, read from constant/triSurface for now.
features
(
//{
// file "someLine.eMesh";
// level 2;
//}
);



// Surface based refinement
// ~~~~~~~~~~~~~~~~~~~~~~~~

// Specifies two levels for every surface. The first is the minimum level,
// every cell intersecting a surface gets refined up to the minimum level.
// The second level is the maximum level. Cells that 'see' multiple
// intersections where the intersections make an
// angle > resolveFeatureAngle get refined up to the maximum level.

refinementSurfaces
{
terrain
{
// Surface-wise min and max refinement level
level (2 2);

// Optional region-wise level specification
/*
regions
{
windTurbine
{
level (3 3);
}
}
*/
//- Optional angle to detect small-large cell situation
// perpendicular to the surface. Is the angle of face w.r.t.
// the local surface normal. Use on flat(ish) surfaces only.
// Otherwise leave out or set to negative number.
//perpendicularAngle 10;


//- Optional faceZone and (for closed surface) cellZone with
// how to select the cells that are in the cellZone
// (inside / outside / specified insidePoint)
//faceZone sphere;
//cellZone sphere;
//cellZoneInside inside; //outside/insidePoint
}
}

resolveFeatureAngle 30;


// Region-wise refinement
// ~~~~~~~~~~~~~~~~~~~~~~

// Specifies refinement level for cells in relation to a surface. One of
// three modes
// - distance. 'levels' specifies per distance to the surface the
// wanted refinement level. The distances need to be specified in
// descending order.
// - inside. 'levels' is only one entry and only the level is used. All
// cells inside the surface get refined up to the level. The surface
// needs to be closed for this to be possible.
// - outside. Same but cells outside.

refinementRegions
{

windTurbine1
{
mode inside;
levels ((6 20));
}

windTurbine2
{
mode inside;
levels ((6 20));
}
//sphere.stl
//{
// mode distance;
// levels ((1.0 5) (2.0 3));
//}
}


// Mesh selection
// ~~~~~~~~~~~~~~

// After refinement patches get added for all refinementSurfaces and
// all cells intersecting the surfaces get put into these patches. The
// section reachable from the locationInMesh is kept.
// NOTE: This point should never be on a face, always inside a cell, even
// after refinement.
locationInMesh (212717.04546875 672091.054545 499.00052454);



// Whether any faceZones (as specified in the refinementSurfaces)
// are only on the boundary of corresponding cellZones or also allow
// free-standing zone faces. Not used if there are no faceZones.
allowFreeStandingZoneFaces true;
}



// Settings for the snapping.
snapControls
{
//- Number of patch smoothing iterations before finding correspondence
// to surface
nSmoothPatch 3;

//- Relative distance for points to be attracted by surface feature point
// or edge. True distance is this factor times local
// maximum edge length.
tolerance 4.0;

//- Number of mesh displacement relaxation iterations.
nSolveIter 30;

//- Maximum number of snapping relaxation iterations. Should stop
// before upon reaching a correct mesh.
nRelaxIter 5;
}



// Settings for the layer addition.
addLayersControls
{
// Are the thickness parameters below relative to the undistorted
// size of the refined cell outside layer (true) or absolute sizes (false).
relativeSizes true;

// Per final patch (so not geometry!) the layer information
layers
{
}

// Expansion factor for layer mesh
expansionRatio 1.0;


// Wanted thickness of final added cell layer. If multiple layers
// is the thickness of the layer furthest away from the wall.
// See relativeSizes parameter.
finalLayerThickness 0.3;

// Minimum thickness of cell layer. If for any reason layer
// cannot be above minThickness do not add layer.
// See relativeSizes parameter.
minThickness 0.25;

// If points get not extruded do nGrow layers of connected faces that are
// also not grown. This helps convergence of the layer addition process
// close to features.
// Note: changed(corrected) w.r.t 17x! (didn't do anything in 17x)
nGrow 0;


// Advanced settings

// When not to extrude surface. 0 is flat surface, 90 is when two faces
// are perpendicular
featureAngle 60;

// Maximum number of snapping relaxation iterations. Should stop
// before upon reaching a correct mesh.
nRelaxIter 5;

// Number of smoothing iterations of surface normals
nSmoothSurfaceNormals 1;

// Number of smoothing iterations of interior mesh movement direction
nSmoothNormals 3;

// Smooth layer thickness over surface patches
nSmoothThickness 10;

// Stop layer growth on highly warped cells
maxFaceThicknessRatio 0.5;

// Reduce layer growth where ratio thickness to medial
// distance is large
maxThicknessToMedialRatio 0.3;

// Angle used to pick up medial axis points
// Note: changed(corrected) w.r.t 16x! 90 degrees corresponds to 130 in 16x.
minMedianAxisAngle 90;

// Create buffer region for new layer terminations
nBufferCellsNoExtrude 0;


// Overall max number of layer addition iterations. The mesher will exit
// if it reaches this number of iterations; possibly with an illegal
// mesh.
nLayerIter 50;

// Max number of iterations after which relaxed meshQuality controls
// get used. Up to nRelaxIter it uses the settings in meshQualityControls,
// after nRelaxIter it uses the values in meshQualityControls::relaxed.
nRelaxedIter 20;
}



// Generic mesh quality settings. At any undoable phase these determine
// where to undo.
meshQualityControls
{
//- Maximum non-orthogonality allowed. Set to 180 to disable.
maxNonOrtho 65;

//- Max skewness allowed. Set to <0 to disable.
maxBoundarySkewness 20;
maxInternalSkewness 4;

//- Max concaveness allowed. Is angle (in degrees) below which concavity
// is allowed. 0 is straight face, <0 would be convex face.
// Set to 180 to disable.
maxConcave 80;

//- Minimum pyramid volume. Is absolute volume of cell pyramid.
// Set to a sensible fraction of the smallest cell volume expected.
// Set to very negative number (e.g. -1E30) to disable.
minVol 1e-13;

//- Minimum quality of the tet formed by the face-centre
// and variable base point minimum decomposition triangles and
// the cell centre. Set to very negative number (e.g. -1E30) to
// disable.
// <0 = inside out tet,
// 0 = flat tet
// 1 = regular tet
minTetQuality 1e-30;

//- Minimum face area. Set to <0 to disable.
minArea -1;

//- Minimum face twist. Set to <-1 to disable. dot product of face normal
//- and face centre triangles normal
minTwist 0.05;

//- minimum normalised cell determinant
//- 1 = hex, <= 0 = folded or flattened illegal cell
minDeterminant 0.001;

//- minFaceWeight (0 -> 0.5)
minFaceWeight 0.05;

//- minVolRatio (0 -> 1)
minVolRatio 0.01;

//must be >0 for Fluent compatibility
minTriangleTwist -1;

//- if >0 : preserve single cells with all points on the surface if the
// resulting volume after snapping (by approximation) is larger than
// minVolCollapseRatio times old volume (i.e. not collapsed to flat cell).
// If <0 : delete always.
//minVolCollapseRatio 0.5;


// Advanced

//- Number of error distribution iterations
nSmoothScale 4;
//- amount to scale back displacement at error points
errorReduction 0.75;



// Optional : some meshing phases allow usage of relaxed rules.
// See e.g. addLayersControls::nRelaxedIter.
relaxed
{
//- Maximum non-orthogonality allowed. Set to 180 to disable.
maxNonOrtho 75;
}
}


// Advanced

// Merge tolerance. Is fraction of overall bounding box of initial mesh.
// Note: the write tolerance needs to be higher than this.
mergeTolerance 1e-6;


// ************************************************** *********************** //
I hope this code might help somebody point out my error!

Saideep June 8, 2015 14:16

Hi Mark;

Welcome to the forum.

As I read your mesh is generate well. Then as you use the snappyHexMesh utility you generate a new time step. Else if you use command snappyHexMesh -overwrite you generate your required shape in the same 0 time step.

Now as I see your code you are interested in looking for a searchableBox which is the name of your .stl file for openFoam to know.

So, once you open paraFoam and apply your case, you get all the available boundaries as mentioned in your blockMeshDict file along with the name of the boundary given for your .stl file.

Hope this helps;
Saideep

mark_CFD_wind June 9, 2015 05:14

hi Saideep,

The mesh is indeed generating around my terrain STL. However no mesh is being drawn around my refinement area.

Any ideas? Ive attatched a screen shot of the mesh in the middle of the refinement box.

Thansk,

Mark

I also get this error in the log.topoSet:

Quote:

/*---------------------------------------------------------------------------*\
| ========= | |
| \\ / F ield | OpenFOAM: The Open Source CFD Toolbox |
| \\ / O peration | Version: 2.3.x |
| \\ / A nd | Web: www.OpenFOAM.org |
| \\/ M anipulation | |
\*---------------------------------------------------------------------------*/
/* Windows port by CFD support (www.cfdsupport.com) [based on Symscape] *\
\*---------------------------------------------------------------------------*/
Build : 2.3.x-819030ed51bd
Exec : topoSet -parallel
Date : Jun 09 2015
Time : 09:48:43
Host : "PNE04"
PID : 5892
Case : C:/OpenFOAM/cygwin64/home/mark.wyper/OpenFOAM/mark.wyper-2.3.x/Bachan_Burn
nProcs : 4
Slaves :
3
(
"PNE04.1232"
"PNE04.5468"
"PNE04.5796"
)

Pstream initialized with:
floatTransfer : 0
nProcsSimpleSum : 0
commsType : nonBlocking
polling iterations : 0
fileModificationChecking : Monitoring run-time modified files using timeStampMaster
allowSystemOperations : Disallowing user-supplied system call operations

// * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * //
Create time

Create polyMesh for time = 0

Reading topoSetDict

Time = 0
mesh not changed.
Created cellSet actuationDisk1
Applying source boxToCell
Adding cells with center within boxes 1((581850.5 4785805 1061) (581850.8 4785815 1071))
cellSet actuationDisk1 now size 0
Created cellZoneSet actuationDisk1
Applying source setToCellZone
Adding all cells from cellSet actuationDisk1 ...
cellZoneSet actuationDisk1 now size 0
Created cellSet actuationDisk2
Applying source boxToCell
Adding cells with center within boxes 1((581754 4785658 1065) (581754.4 4785668 1075))
cellSet actuationDisk2 now size 0
Created cellZoneSet actuationDisk2
Applying source setToCellZone
Adding all cells from cellSet actuationDisk2 ...
cellZoneSet actuationDisk2 now size 0

End

Finalising parallel run
I can package the project up and send it over if this would be of help instead of large code dumps!

Thanks,

Mark

Saideep June 9, 2015 05:44

Hi mark;

Well I see no attachment but,
I suspect two reasons for that!!

1. Your locationInMesh value along (x y z) position. So, you generally specify the co-ordinate that you want to retain in this function.
And one more thing, when you specify your locationInMesh values, you should be careful that the co-ordinate that you mention has some connection with the other region of the .stl. Else(if you have a closed portion and you mention a co-ordinate that is within the close portion of .stl) only certain portion of the point specified characteristic region is obtained.

2. If that is fine, the second reason could be that your grid refinement is not fine enough to remove or separate your hexahedral polymesh from your .stl image.

Saideep

mark_CFD_wind June 9, 2015 06:37

Thanks again Saideep,

After changing the locationinmesh value, I am almost tertian that the problem is with the grid refinement.

Which values would you recommend altering?

Something like the expansionRatio or finalLaterThickness or minThickness?

Thanks,

Mark

Saideep June 9, 2015 06:46

Hi there;

Good to hear that your getting close to what you need.

Well what I basically do is to just change in the blockMeshDict file. Just increase the number of cells along the domain. May be double it or so....

Saideep


All times are GMT -4. The time now is 22:23.