CFD Online Logo CFD Online URL
www.cfd-online.com
[Sponsors]
Home > Forums > Software User Forums > OpenFOAM > OpenFOAM Meshing & Mesh Conversion

[snappyHexMesh] some bad cells after snappyHexMesh

Register Blogs Community New Posts Updated Threads Search

Like Tree1Likes
  • 1 Post By alfa.fauzi

Reply
 
LinkBack Thread Tools Search this Thread Display Modes
Old   April 29, 2020, 23:11
Default some bad cells after snappyHexMesh
  #1
New Member
 
MASc Student
Join Date: Sep 2016
Posts: 25
Rep Power: 10
New-to-CFD is on a distinguished road
hello everyone,

will try to frame this question as best as possible but I am relatively new to openfoam so please excuse me if I word things in correctly.

Long story short - I have an stl of an object I am using to snap the mesh to, after completion, I end up with all these really weird very bad quality cells surrounding the object and don't know how to prevent these or fix them.

See attached zip of my case folder.

I am currently just running the following commands, trying to get a nice mesh before moving on.

Code:
blockMesh
topoSet -dict system/topoSetDict1
refineMesh -dict system/refineMeshDict1
topoSet -dict system/topoSetDict2
refineMesh -dict system/refineMeshDict2
surfaceFeatureExtract
snappyHexMesh
I am going the route of manually refining areas because I couldn't quite get it to work using snappy refinementRegions. Any suggestions on that would be appreciated too.

Please see the images showing the mesh after the second refinement, after snappy, and what the object looks like. I realize I could get better snapping to the unit but wanted to keep the mesh relatively coarse for now for testing. If I can get better snapping to the object without increase resolution/number of levels, please let me know how.

Could someone please take a look and see if they can manage to fix the weirdness around my object?

At first glance, I know my snapControls may be set excessively high, that was me just trying some stuff, but didn't seem to change the results.

Using OFv1912.

Any help is appreciated!!

Thanks

Screenshot from 2020-04-29 22-04-04.png

Screenshot from 2020-04-29 22-05-49.png

Screenshot from 2020-04-29 22-06-17.png

Screenshot from 2020-04-29 22-06-51.png

FlumeTesting.zip
New-to-CFD is offline   Reply With Quote

Old   April 30, 2020, 03:44
Default
  #2
Senior Member
 
Yann
Join Date: Apr 2012
Location: France
Posts: 1,200
Rep Power: 28
Yann will become famous soon enough
Hi,


When visualizing the mesh in ParaView, have you tried checking the "crinkle clip" option ? (or crinkle slice if you're using the slice filter)


Yann
Yann is offline   Reply With Quote

Old   April 30, 2020, 18:21
Default
  #3
New Member
 
MASc Student
Join Date: Sep 2016
Posts: 25
Rep Power: 10
New-to-CFD is on a distinguished road
Quote:
Originally Posted by Yann View Post
Hi,


When visualizing the mesh in ParaView, have you tried checking the "crinkle clip" option ? (or crinkle slice if you're using the slice filter)


Yann
bonehead mistake... thanks, this fixed it..turns out the mesh was actually fine, spent hours chasing a problem that didn't exist

are you able to suggest what parameters in the sHMdict I can vary to make the mesh snap better to the edges extracted during the surfaceFeatureExtract step?? Without having to increase mesh resolution or number of levels in sHM? I feel like there' s a way to make it snap perfectly but I'm just missing it....?
New-to-CFD is offline   Reply With Quote

Old   May 2, 2020, 18:10
Default
  #4
Senior Member
 
Claudio Boezio
Join Date: May 2020
Location: Europe
Posts: 137
Rep Power: 7
Ship Designer is on a distinguished road
Hi,

I've experienced similar issues when I started using OpenFOAM and snappyHexMesh. It seemed that no matter how much I refined the mesh, its snapping quality didn't seem to improve, just the amount of cells increased.

What I found out was that the input geometry (*.stl file) didn't had sufficient resolution. snappyHexMesh can only snap conforming to the input geometry, but not better. If you have a curved surface which is subdivided by trinagles or quadrilaterals, the snapped mesh also won't have a nice curvature. My suggestion to improve this, is to use input geometry with a mesh that is at least as fine as the intended mesh for the solution. Don't save on the *.stl or *.obj file size. Instead make it as fine as if you had to use it for producing a quality rendering. Hope this helps.



Cheers
Ship Designer is offline   Reply With Quote

Old   May 7, 2020, 18:26
Default
  #5
New Member
 
MASc Student
Join Date: Sep 2016
Posts: 25
Rep Power: 10
New-to-CFD is on a distinguished road
Quote:
Originally Posted by Ship Designer View Post
Hi,

I've experienced similar issues when I started using OpenFOAM and snappyHexMesh. It seemed that no matter how much I refined the mesh, its snapping quality didn't seem to improve, just the amount of cells increased.

What I found out was that the input geometry (*.stl file) didn't had sufficient resolution. snappyHexMesh can only snap conforming to the input geometry, but not better. If you have a curved surface which is subdivided by trinagles or quadrilaterals, the snapped mesh also won't have a nice curvature. My suggestion to improve this, is to use input geometry with a mesh that is at least as fine as the intended mesh for the solution. Don't save on the *.stl or *.obj file size. Instead make it as fine as if you had to use it for producing a quality rendering. Hope this helps.



Cheers
thanks, I will give this a try. The mesh of the stl is already pretty fine.

I am able to get better snapping by increasing the levels for the feature edge refinement, using the eMesh file output from SurfaceFeatureExtract, but then the cells get so small it's not even worth the tiny bit of snapping improvement.

I'll try playing with the actual stl mesh to see if I can get some improvement without having to refine the cells too much.
New-to-CFD is offline   Reply With Quote

Old   May 7, 2020, 19:57
Default SHM problem
  #6
New Member
 
nicolas martinez poulsen
Join Date: May 2020
Posts: 2
Rep Power: 0
nico_martinez_p is on a distinguished road
Hi everyone. I'm traying to modelate generate a "simple" canal with some blocks inside.

First generated the domain (canal) with blockMesh (no problem). After that i'm traying to incorporated the blocks inside using snappyHexMesh. I generate my .stl file with blocks, and previewd on para view.


I serch in google and here, but I cant find anything, so i have to ask if someone can tell me that im doing wrong.


My snapp file is this:
Code:
/*--------------------------------*- C++ -*----------------------------------*\
  =========                 |
  \\      /  F ield         | OpenFOAM: The Open Source CFD Toolbox
   \\    /   O peration     | Website:  https://openfoam.org
    \\  /    A nd           | Version:  7
     \\/     M anipulation  |
\*---------------------------------------------------------------------------*/
FoamFile
{
    version     2.0;
    format      ascii;
    class       dictionary;
    object      snappyHexMeshDict;
}
// * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * //

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

// * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * //
geometry
{
    Dientes.stl
    {
        type triSurfaceMesh;
    file "Dientes.stl"
    name Dientes;    
    //patchInfo
    //{
    //   type walls;
        //}
    }

};

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 3;



    // 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 "Dientes.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
    {
        Dientes
        {
            // Surface-wise min and max refinement level
            level (2 2);

            // Optional specification of patch type (default is wall). No
            // constraint types (cyclic, symmetry) etc. are allowed.
            //patchInfo
            //{
            //    type wall;
            //   inGroups (walls);
            //}
        }
    }

    // Resolve sharp angles
    resolveFeatureAngle 0;


    // 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
    {
        //refinementBox
       // {
        //    mode inside;
       //     levels ((1E15 4));
        //}
    }


    // 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 (1 1 80);


    // 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 false;
}



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

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

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

    // 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 points on multiple surfaces (only for explicitFeatureSnap)
        multiRegionFeatureSnap false;
}



// 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 false;  // prueba si es que con esto hacemos aparecer los dientes que estan sobre el punto de contacto con un mesh

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

    // 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.
    // See relativeSizes parameter.
    finalLayerThickness 0.3;

    // 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
    // are perpendicular
    featureAngle 60;

    // At non-patched sides allow mesh to slip if extrusion direction makes
    // angle larger than slipFeatureAngle.
    slipFeatureAngle 30;

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

    // 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
    nBufferCellsNoExtrudegeometry
{
    Dientes.stl
    {
        type triSurfaceMesh;
    file "Dientes.stl"
    name Dientes;   
    //patchInfo
    //{
    //   type walls;
        //}
    }

};

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 3;



    // 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 "Dientes.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
    {
        Dientes
        {
            // Surface-wise min and max refinement level
            level (2 2);

            // Optional specification of patch type (default is wall). No
            // constraint types (cyclic, symmetry) etc. are allowed.
            //patchInfo
            //{
            //    type wall;
            //   inGroups (walls);
            //}
        }
    }

    // Resolve sharp angles
    resolveFeatureAngle 0;


    // 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
    {
        //refinementBox
       // {
        //    mode inside;
       //     levels ((1E15 4));
        //}
    }


    // 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 (1 1 80);


    // 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 false;
}



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

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

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

    // 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 points on multiple surfaces (only for explicitFeatureSnap)
        multiRegionFeatureSnap false;
}
 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
{
    #include "meshQualityDict"
}


// Advanced

// Write flags
writeFlags
(
    scalarLevels
    layerSets
    layerFields     // write volScalarField for layer coverage
);


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


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

Regards
Attached Images
File Type: jpg Canal_BlockMesh.jpg (23.0 KB, 75 views)
File Type: jpg Canal_with_stl_block.jpg (21.7 KB, 65 views)
File Type: jpg Snappy_Resault.jpg (160.2 KB, 79 views)
nico_martinez_p is offline   Reply With Quote

Old   May 7, 2020, 20:39
Default
  #7
New Member
 
nicolas martinez poulsen
Join Date: May 2020
Posts: 2
Rep Power: 0
nico_martinez_p is on a distinguished road
Complementing the above, the end of the SHM process shows the following message:
"

Checking final mesh ...
Checking faces in error :
non-orthogonality > 65 degrees : 700
faces with face pyramid volume < 1e-13 : 0
faces with face-decomposition tet quality < 1e-15 : 0
faces with concavity > 80 degrees : 0
faces with skewness > 4 (internal) or 20 (boundary) : 0
faces with interpolation weights (0..1) < 0.05 : 68
faces with volume ratio of neighbour cells < 0.01 : 0
faces with face twist < 0.02 : 0
faces on cells with determinant < 0.001 : 0
Finished meshing with 768 illegal faces (concave, zero area or negative cell pyramid volume)
Finished meshing in = 27.58 s.
End

"
nico_martinez_p is offline   Reply With Quote

Old   May 8, 2020, 16:20
Default
  #8
New Member
 
MASc Student
Join Date: Sep 2016
Posts: 25
Rep Power: 10
New-to-CFD is on a distinguished road
Quote:
Originally Posted by nico_martinez_p View Post
Complementing the above, the end of the SHM process shows the following message:
"

Checking final mesh ...
Checking faces in error :
non-orthogonality > 65 degrees : 700
faces with face pyramid volume < 1e-13 : 0
faces with face-decomposition tet quality < 1e-15 : 0
faces with concavity > 80 degrees : 0
faces with skewness > 4 (internal) or 20 (boundary) : 0
faces with interpolation weights (0..1) < 0.05 : 68
faces with volume ratio of neighbour cells < 0.01 : 0
faces with face twist < 0.02 : 0
faces on cells with determinant < 0.001 : 0
Finished meshing with 768 illegal faces (concave, zero area or negative cell pyramid volume)
Finished meshing in = 27.58 s.
End

"
run checkMesh to get more information on the mesh.

definitely increase resolveFeatureAngle to something higher...something like 30 typically works well for me but will depend on your geometry

also, when in paraview after loading the case..scroll down in the properties tab until you see Mesh Regions and just show the ones pertaining to your objects. This will give you a better depiction as to whether they've meshed satisfactorily or not.
New-to-CFD is offline   Reply With Quote

Old   April 19, 2021, 08:56
Default some bad cells after snappyHexMesh(2)
  #9
New Member
 
Alfa
Join Date: Apr 2021
Location: Germany
Posts: 3
Rep Power: 5
alfa.fauzi is on a distinguished road
Hi everyone!

I'm new to OpenFOAM and currently deepening more about snappyHexMesh. I have several questions regarding some bad cells after snappyHexMesh similar to what has been posted here by @New-to-CFD and would like to make sure if everything works accordingly. I'm also very sorry if I don't put all the details related to my case now. However, if more detail is needed then I'll provide the best I could. My case is a 3D flow around some obstacles with dimension 100x100x10 m with max expected final cell no. of 25-30 Mio.

1. I have completed the castellating and snapping phase (and will do the layer addition later). However some bad-looking cells look to appear similar to that posted by @New-to-CFD. Attached is the snapshot BEFORE and AFTER "crinkle clip" such as suggested by @Yann. Can someoene please confirm if my cells are visually OK? Attached is the snapshots.

2. I have checked on my snappyHexMesh log that all of the iteration successfully leads to "0" of "mesh in errors" e.g. tet quality, concaveness, skewness, etc. However, the final check mesh still shows "Failed 3 mesh checks" which are skewness (1 highly skew faces of 4.10024, I think it's fine since it's only one cell and the value is near the skewness threshold of 4 CMIIW), 273 face tets, and concave cells where the latter can be ignored according to some discussions in CFD community. Can someone advise what should be done or is it okay to have those? The checkMesh and snappyHexMesh log file as well as my snappyHexMeshDict are attached.

3. I have made sure that my geometry is fine. I used Autodesk Inventor and have checked it for an error with no error result. I exported STL with the high resolution. I also did surfaceCheck in OpenFOAM where everything is fine. Attached is the log files of surfaceCheck. Regarding to this, can someone also confirm if my STL is fine and no further checking is necessary? Am I missing something in order to provide good STL or should I perform another checking method?

Thank you!

Regards,
Alfa
Attached Images
File Type: jpg 1. Fig1_BEFORE crinkle clip.jpg (95.2 KB, 66 views)
File Type: jpg 2. Fig1_AFTER crinkle clip.jpg (99.0 KB, 56 views)
File Type: jpg 3. Fig2_BEFORE crinkle clip.jpg (168.5 KB, 46 views)
File Type: jpg 4. Fig2_AFTER crinkle clip.jpg (165.3 KB, 45 views)
Attached Files
File Type: zip logs.zip (84.3 KB, 3 views)
Hip2BL7 likes this.
alfa.fauzi is offline   Reply With Quote

Reply

Tags
mesh, openfoam, refinemesh, snappyhexmesh


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
[blockMesh] Create internal faces as patch in blockMesh m.delta68 OpenFOAM Meshing & Mesh Conversion 14 July 12, 2018 15:43
[snappyHexMesh] snappyHexMesh does not remove internal cells Manyway OpenFOAM Meshing & Mesh Conversion 1 December 14, 2016 19:57
[snappyHexMesh] snappyHexMesh uses tet cells for internal mesh! sasanghomi OpenFOAM Meshing & Mesh Conversion 2 March 16, 2014 06:41
[ICEM] error analysis despaired student ANSYS Meshing & Geometry 7 June 27, 2012 12:57
Problems of Duns Codes! Martin J Main CFD Forum 8 August 15, 2003 00:19


All times are GMT -4. The time now is 18:27.