CFD Online Discussion Forums - [snappyHexMesh] SnappyHexMesh Internal Flow Example (Diesel Injector)

CFD Online Discussion Forums (https://www.cfd-online.com/Forums/)

- OpenFOAM Meshing & Mesh Conversion (https://www.cfd-online.com/Forums/openfoam-meshing/)

- - [snappyHexMesh] SnappyHexMesh Internal Flow Example (Diesel Injector) (https://www.cfd-online.com/Forums/openfoam-meshing/103513-snappyhexmesh-internal-flow-example-diesel-injector.html)

SnappyHexMesh Internal Flow Example (Diesel Injector)

Hello Foamers!

After working through this meshing process on the internal flow of a diesel injector I felt inclined to share my results as internal flow applications of SHM seem to inspire many questions on the forums.

!!Disclaimer, I am no SHM expert, so if anyone wants to elaborate on any of these issues please do!!

To begin with 2D slice of the 3D injector file I began with:
Attachment 13919

Due to the sharp angles that are present in the geometry as well as circular shapes I needed to use surfaceFeatureExtract twice:

Code:

surfaceFeatureExtract -includedAngle 180 -writeObj constant/triSurface/SprayA210675doublesmoothascii.stl outputfile

Code:

surfaceFeatureExtract -includedAngle 150  -writeObj constant/triSurface/SprayA210675doublesmoothascii2.stl  outputfile2

(Note SprayA210675doublesmoothascii.stl and SprayA210675doublesmoothascii2.stl are actually the same stl file, but if I didn't do it this way then the two surface extractions overwrote each other)

You can then check to see what surfaces were included in the output files you created. Looking at the file "filename_edgeMesh.obj" and taking a slice of the resulting image:

Attachment 13923

You can see that the horizontal lines were were not captured by the surface edge program. Looking at the second _edgeMesh.obj file:

Attachment 13924

The horizontal edges have now been captured. Note a few extra things have been captured that overlap with the first surface extraction, but that is fine.

Next make sure that your blockmeshdict creates a mesh of sufficient density, ie make sure that the interior of the geometry you want to capture has nodes in it.

There are a few things to make sure you edit before running a case like this. First make sure you load your geometry:

Code:

geometry

{

    SprayA210675doublesmoothascii.stl

    {

        type triSurfaceMesh;

        name nozzle;

    }

};

Then specify which edges are being refined, ie the .eMesh files you create (which should be located in the /constant/triSurface/ directory):

Code:

    // 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 "SprayA210675doublesmoothascii.eMesh";

            level 0;

        }

        {

            file "SprayA210675doublesmoothascii2.eMesh";

            level 0;

        }

    );

Note that the level for each of the .eMesh files is set to 0, which is counterintuitive based on the refinementSurfaces section. However, if a value >0 is chosen then the edges will not get snapped to correctly in my experience thus far.

Specify how much refinement you want to perform (Note SHM takes the name of the stl you provide, in this case nozzle, and adds an underscore. Since I want to refine all surfaces I can use the wildcard * to make sure all surfaces are refined):

Code:

    refinementSurfaces

    {

      "nozzle_*"

      {

          // Surface-wise min and max refinement level

          level (8 9);

      }



    }

Make sure the location in the mesh is defined to be within the geometry which you input:

Code:

locationInMesh (0.07 0.0 1.3);

Enable the edge snapping feature:

Code:

    //- Highly experimental and wip: number of feature edge snapping

    //  iterations. Leave out altogether to disable.

    nFeatureSnapIter 10;

Specify how many layers, if any, you want to create near the edges:

Code:

    layers

    {

        "nozzle_*"

        {

           nSurfaceLayers 4;

        }

    }

For completeness, the entire snappyHexMeshdict is incldued here:

Code:

/*--------------------------------*- C++ -*----------------------------------*\

| =========                 |                                                 |

| \\      /  F ield         | OpenFOAM: The Open Source CFD Toolbox           |

|  \\    /   O peration     | Version:  2.0.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

{

    SprayA210675doublesmoothascii.stl

    {

        type triSurfaceMesh;

        name nozzle;

    }

};



// 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 20;



    // 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 2;







    // 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 "SprayA210675doublesmoothascii.eMesh";

            level 0;

        }

        {

            file "SprayA210675doublesmoothascii2.eMesh";

            level 0;

        }

    );







    // 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

    {

      "nozzle_*"

      {

          // Surface-wise min and max refinement level

          level (8 9);

      }



    }



    // Resolve sharp angles

    resolveFeatureAngle 180;





    // 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

    {



    }





    // 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 (0.07 0.0 1.3);





    // 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 10;



    //- 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 10;



    //- Maximum number of snapping relaxation iterations. Should stop

    //  before upon reaching a correct mesh.

    nRelaxIter 10;



    //- Highly experimental and wip: number of feature edge snapping

    //  iterations. Leave out altogether to disable.

    //  Do not use here since mesh resolution too low and baffles present

    nFeatureSnapIter 10;

}







// 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

    {

        "nozzle_*"

        {

           nSurfaceLayers 4;

        }

    }



    // 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.

    //  Relative to undistorted size of cell outside layer.

    //  is the thickness of the layer furthest away from the wall.

    //  See relativeSizes parameter.

    finalLayerThickness 0.5;



    //- Minimum thickness of cell layer. If for any reason layer

    //  cannot be above minThickness do not add layer.

    //  Relative to undistorted size of cell outside layer.

    minThickness 0.1;



    //- 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

    //  make straight angle.

    featureAngle 90;



    //- 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 17x! 90 degrees corresponds to 130 in 17x.

    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;

}







// 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 3.5;

    maxInternalSkewness 2.5;



    //- 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-30;



    //- Minimum quality of the tet formed by the face-centre

    //  and variable base point minimum decomposition triangles and

    //  the cell centre. This has to be a positive number for tracking

    //  to work. 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.02;



    //- minimum normalised cell determinant

    //- 1 = hex, <= 0 = folded or flattened illegal cell

    minDeterminant 0.001;



    //- minFaceWeight (0 -> 0.5)

    minFaceWeight 0.02;



    //- minVolRatio (0 -> 1)

    minVolRatio 0.01;



    //must be >0 for Fluent compatibility

    minTriangleTwist -1;





    // Advanced



    //- Number of error distribution iterations

    nSmoothScale 4;

    //- amount to scale back displacement at error points

    errorReduction 0.75;

}





// Advanced



// Flags for optional output

// 0 : only write final meshes

// 1 : write intermediate meshes

// 2 : write volScalarField with cellLevel for postprocessing

// 4 : write current intersections as .obj files

debug 0;





// Merge tolerance. Is fraction of overall bounding box of initial mesh.

// Note: the write tolerance needs to be higher than this.

mergeTolerance 1e-6;





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

The resulting mesh:
Attachment 13921 Attachment 13922

It's not totally complete as I need to reduce the number of cells (currently 2.25 million), but this shows the overall process and what things to consider.

Some thoughts to consider if you may still be having problems:

1) Look at the bounding box you are using with your desired geometry. Could you make it smaller in order to reduce the initial mesh size?

2) Are you going to exceed the maxGlobalCells value? SHM will not abort if you exceed this value, but rather just stop creating new cells. By increasing the initial mesh density defined in the blockmeshdict you increase the chances of this value being exceeded.

3) If you increased the initial mesh density, how many refinement levels are you performing? By increasing the initial density of the mesh, the refinement levels do not need to be as large. Refinement levels dictate how many times each cell is split into smaller cells. So if you increase the density of the initial mesh and keep the refinement level at say 10 or 11, then you may be increasing the resulting mesh calculation much more than you may think.

4) All of these things could contribute to SHM eating up all of your memory and aborting the operation. If you are getting the memory error then try reducing the number of refinement levels, the initial mesh density, and even possibly the number of edge layers being created. Get it to a point where it will successfully run and then if necessary increase these values to get the desired mesh resolution.

5) If you are unsure if your memory is being completely utilized watch your SHM operation using the 'top' command. In my experience SHM aborted right when my memory maxed out.

Hej,

thanks for sharing this. I like the idea of the double feature edge extraction and your thoughts on the the snapping edge feature.

I have one more question, which of the .obj files do you usually inspect in order to see if you featureSurface extraction was good or not?

Quote:

Originally Posted by romant (Post 367382)

Roman,

I'm glad you find it useful, I had a hard time finding internal flows to base my mesh on so figured I would help provide one.

The .obj file from surfacefeatureextract that I have been using is the "filename_edgeMesh.obj", which paraview can open directly. Though I'm sure there are other options available, like just looking at the .eMesh file. I believe I have seen some discussion in the forums about trying to open an .eMesh in paraview, but I didn't investigate it much.

Greetings to all!

FYI: you can convert "eMesh" files to "obj" and vice-versa:

Code:

surfaceFeatureConvert relative/path/file.eMesh file.obj

Best regards,
Bruno

HI Everyone :)

I want to improve the cell density in certain regions of my mesh(created using SHM).
It would be great if anyone could help me understand how refinement levels work.:D

Thank You
Turbulence.

Hi Turbulence,

You should find answers here: http://openfoamwiki.net/index.php/Sn...als_and_Guides - read the tutorial "A Comprehensive Tour of snappyHexMesh".

Best regards,
Bruno

Irish 09-

Nice work and thank you! may i ask how you built your blockMeshDict file? how specific did you need to be with your original geometry for this to work?

Hello Dmoore,

I'm glad you found this helpful. The blockMeshDict is just made to be slightly larger than the STL geometry I wish to mesh. Deciding how large the cells of your blockMesh is a bit difficult to determine. You first need to make sure that there are enough cells that some nodes are interior to the STL geometry and some are exterior. Once you accomplish that, you technically don't need to have more cells present.

However, the more course your blockmesh starts, the more refinement will be necessary to get your desired mesh from SHM and therefore the longer SHM takes to complete.

To even further complicate it though, is that if you make your original blockmesh too refined, then you can potentially have too many cells and I have in the past run out of memory on my desktop with 8GB of RAM, in which case SHM will crash. The problem that is occurring is that the first thing SHM does is refine the original blockmesh and then cuts out the parts that do not touch the STL geometry. Therefore you could be spending a lot of memory refining parts of the blockmesh that will just be cut off later anyway.

So you need to balance how much to refine the original blockmesh and then add layers and refinementregions so that you do not just blindly refine the entire blockmesh domain before it conforms to the correct geometry.

-Irish09

ok. That makes sense. I think my blockMesh is sufficient and I have the privelege of 64GB of RAM, so SHM doesn't limit me too much. I can successfully run the mesh in parallel but then when it comes time to run simpleFoam, I recieve this error:

[1] --> FOAM FATAL IO ERROR:
[1] Cannot find patchField entry for contraction_contraction
[1]
[1] file: /home/teamsoh/OpenFOAM/teamsoh-2.2.0/run/sohWind/bigBlock/processor1/0/p.boundaryField from line 26 to line 45.
[1]
[1] From function GeometricField<Type, PatchField, GeoMesh>::GeometricBoundaryField::readField(const DimensionedField<Type, GeoMesh>&, const dictionary&)
[1] in file /home/opencfd/OpenFOAM/OpenFOAM-2.2.0/src/OpenFOAM/lnInclude/GeometricBoundaryField.C at line 154.
[1]
FOAM parallel run exiting

I can send you the casefile if you'd like? I noticed that the contraction_contraction line only shows up in the processor dict's.. any thoughts? Does this mean I have incorrectly set up my inlet/outlet/wall conditions?

thanks!
Dmoore

Dmoore,

It certainly looks like something is wrong with the boundary conditions. I could take a look at the case file if you would like.

Contraction casefile

I would be extremely grateful to have another set of eyes on it. I am attempting SHM for the first time this these past two weeks. In the past I have used PointWise to mesh. Thank you so much!:)

Hello Dmoore,

I've taken a look at your case file and I can see a potential problem, but you will have to let me know as it depends on what you are attempting to model. I am assuming, that you are wanting to model the flow in the interior of this contraction and don't care about the flow on the outside of the device. If I am assuming incorrectly let me know and I can re-evaluate.

Based on this assumption of internal flow only, then the current problem I can see has to do with the STL file itself. Since your STL file is not closed, SHM cannot distinguish between the interior and the exterior of the geometry as it can travel from any point A to any point B without traveling through a wall (or inlet/outlet). There are two ways to go about fixing this. The first is to just add a surface where the inlet and outlet are going to be defined in whatever CAD program and then it use that as the STL file. SHM will treat these surfaces as part of the geometry, but does not mean they have to be walls. The second option requires making the original blockmesh smaller than the geometry you wish to mesh, which will essentially clip the geometry at whatever point the blockmesh crosses it and treat that as a wall. I recommend the first option, as the second is a bit more hacking and you don't have as much direct control over the geometry and resulting patches.

Irish09

CAD file vs OpenFOAM

Yes, you are correct. I should have been more clear:). I am trying to simulate an internal flow within the geometry of the .stl file. I took your advice and closed off the two ends of the channel. I also reduced the volume of my blockMesh to fit within the channel so that it can snap to the inside walls of the channel.

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

Reading surfaceFeatureExtractDict

Surface : "contraction.3.stl"

Feature line extraction is only valid on closed manifold surfaces.
word::stripInvalid() called for word ��?
For debug level (= 2) > 1 this is considered fatal
Aborted (core dumped)

Unfortunately when I close the ends however, it claims to be an 'open' manifold surface and crashes. The CAD program I have been using, SolidWorks, says otherwise and that it is closed and fully defined. Maybe this is a CAD issue instead of OpenFOAM?

Dmoore

Hello Dmoore,

I fear I might have slightly led you astray ;). You have taken ideas from both suggestion 1 and 2, but as I stated before I don't think the second idea was a worthwhile one. From your post I am given the impression that the blockmesh, in its entirety, fits within the contraction. This will not work as it must have nodes on both sides of the geometry in order to find the surface to snap to it. What I was mentioning before could potentially be used so that 2 of the 6 sides of the geometry were not within the original blockmesh, thus creating a boundary that way. I don't recommend this approach though.

So I would revert back to the blockmesh file you had previously, in the case file you posted, and keep the geometry closed as you did here.

However, the error you are getting has nothing to do with your blockmesh file. As this error is occuring in the surfacefeatureextract function, the blockmesh is not being utilized yet. I went and looked at:

OpenFOAM/OpenFOAM-2.2.0/applications/utilities/surface/surfaceFeatureExtract

And found that it always prints out "Feature line extraction is only valid on closed manifold surfaces.", so that actually isn't the error, just a statement to remind you. I would think it is a problem with your STL file from your solidworks program. I am unsure if surfacefeatureextract can handle both binary and ASCII STL files, so I would make sure it is ASCII, since I know that works. Otherwise I am unsure of how to help. As the first geometry you provided works fine with the function I would suggest seeing how the two differ.

-Irish09

Irish 09-

thank you tremendously for your help. I did overlook writing to an ASCII format for the stl file, I think I was rushing :). Fixing that allowed me to extract surface geometry and run SHM but with the same original issue of nothing to snap to. It ran for about 20 minutes on 24 cores and returned an untouched blockMesh! haha bummer! I reverted the blockMesh as you sugguested, but for some reason something is still pretty funky :(. Thanks for the help though! I will post as soon as I am able to find my error!

Dmoore

Greetings to all!

@Dmoore:

Quote:

Originally Posted by Dmoore (Post 433819)

It ran for about 20 minutes on 24 cores and returned an untouched blockMesh!

How exactly did you run snappyHexMesh? Did you use the "-overwrite" option?
Because if you didn't use this option, then check the time folders "1", "2" and/or "3", where the intermediate and final mesh will be located.

Best regards,
Bruno

Wyldckat-

I ran the command line:

mpirun -np 24 snappyHexMesh -overwrite -parallel

Is there something missing from that sequence? I trying to run the following commands:
blockMesh
surfaceFeatureExtract (I am working with OpenFOAM v 2.2.0)
decomposePar
mpirun -np 24 snappyHexMesh -overwrite -parallel
mpirun -np 24 simpleFoam -parallel > log

thanks!
Danny

Hi Danny,

From the list of commands you've shown, the only problem I can see is that running simpleFoam right after snappyHexMesh might not work as expected.
I haven't tested the following cases on OpenFOAM 2.2, but the steps I usually follow are demonstrated on the example cases given here: http://code.google.com/p/bluecfd-sin...untimes202_211

Without looking at the "snappyHexMeshDict", it's hard to estimate what might be wrong, but the following come to mind:

"locationInMesh" might not be properly defined, leading to the mesh being generated on the wrong side. You can check this by using the "Slice" or "Clip" filter in ParaView and examine if the mesh/geometry is indeed there or not.
The bounding box created with blockMesh might not be in the same space as the geometry, leading to things not being in the same existential region... Load the STL file into the same ParaView window, to check if they are in the correct places.
snapping iterations might be turned off... I'm speaking/writing about the following keywords:

Code:

snap true;

And:

Code:

// Feature snapping // Number of feature edge snapping iterations. // Leave out altogether to disable. nFeatureSnapIter 10; // Detect (geometric only) features by sampling the surface // (default=false). implicitFeatureSnap false; // Use castellatedMeshControls::features (default = true) explicitFeatureSnap true; // Detect features between multiple surfaces // (only for explicitFeatureSnap, default = false) multiRegionFeatureSnap false;

For the complete example file I'm looking at: https://github.com/OpenFOAM/OpenFOAM...ppyHexMeshDict
Last but not least: there might be problems in snapping, if the geometry isn't all in the same STL file.

Best regards,
Bruno

Dear Bruno-

Thank you for the response (my apologies for the delay of mine!) I have already done the checks you suggested, as well as updated my snappyHexMeshDict to conform to O.F v2.2.0. I think I may revert back to OpenFOAM v 2.1 if i cannot seem to troubleshoot this mesh error by the end of the week. I will let you know if it runs on v2.1 instead of v2.2

thanks again
Dmoore

Ok so I have diagnosed my problem with SHM-

SolidWorks (a 3D modeling software) creates objects and saves as an stl format (for SHM to use) but fills the objects with zero volume. In fact, the only volume taken up is by the lines that define the edges. This results in what seems to be an 'Open' volume when in fact it does not exist in the first place. I would be curious to know if anyone has ever used SolidWorks to mesh with SnappyHex, and if they have successfully, they will be my hero :)