[wyldckat]

Greetings to all!

I took another look at the latest posts here (starting from #233 and onward) and I remembered another discussion related to this issue, where there were high frequency pressure variations when using AMI, due to the weighted calculations... and there is this post there: http://www.cfd-online.com/Forums/ope...tml#post513605 - posts #7 and #8, which has a neat trick for hacking into the meshed points, in order to enforce the points to be coincident on each side of the AMI. Problem is that your geometries are a lot more complex than the cylinder example they have on the other thread.

There is also the tutorial case "mesh/moveDynamicMesh/SnakeRiverCanyon", which demonstrates a way of displacing the points on a patch by using dynamic meshing.

If anyone of you can provide a simple test case with the more complex surfaces you two have got, I (or anyone else) should be able to create a point displacement boundary condition that can displace points in a way that can grant a better correlation between the two sides of the AMI.

Best regards,
Bruno

[Artur]

Hello Bruno,

As always I admire your drive to help others out

As for test cases, here's a simple case with a mesh created using Pointwise I showed a few posts ago. In the current state it runs but gives very high/low AMI weightings so should be just fine to test your approach.

https://www.dropbox.com/s/a6v8e7c25w...se.tar.gz?dl=0

Not sure if you have access to a Pointwise licence, I'm happy to share or modify the original file myself if needed.

All the best,

A

[louisgag]

Dear Bruno, Artur, and Stefano,

I have been looking over the forums and the tutorials but haven't found the answer to my AMI problem. Maybe one of you could point me to the right direction ?

I have a good looking mesh that I use with the AMI and get the weight=0 for a large portion of the rotation and even starting at t=0 ! The mesh looks relatively well represented and the surface normals seem to match as they should.

Is there a way by which I could identify the faulty cells ? How can I improve the quality of my interface ? I tried to use "facetypes baffles" in snappyHexMesh but it only seems to cause me more issues (snappyHexMesh no longer creates two patches and thus the mesh deforms instead of sliding along the interface)

I'm attaching a few screenshots.

I'm using a very recent build of OF-2.3.x and snappyHexMesh.

Regards,

-Louis

[louisgag]

Hello again everyone,

Just a small update, I'm currently using the lowWeightCorrection keyword in my createPatchDict file, which from what I understand blocks any flow movement through the cells with weights below the threshold I specify and thus allow the simulation to pursue at the cost of loosing precision.

The solution is a bit dirty and I'd still prefer if I could avoid these low weight situations..

-Louis

[Artur]

Hi,

Thanks for sharing that workaround, I wasn't aware of it. Does it seem to affect your solution a lot or just marginally? I noticed your grid is very fine around the cylinder edges. I have found that refining the snappy meshes actually tends to make the AMI more prone to the zero-weighting issue, perhaps would be worth trying making the interface itself a bit coarser?

Otherwise, I think the best solution to identify exactly where the problem lies would be to visualise the AMI weighting and see where it is zero. I am not a ware of a ready utility which would do that so it would have to be written from scratch...

A

[louisgag]

Hi Artur,

I haven't run enough simulations to answer your question about how much it affects the solution. I also tried coarser interfaces and sometimes it helps sometimes not, seems like an almost random result.

The lowWeightCorrection keyword is documented here: http://www.openfoam.org/version2.3.0/ami.php

Are you using snappyHexMesh as well ? If so, have you noticed better performance using the old (explicit) snapping or the new (implicit) snapping ?

I played with the snapping parameters a lot and the following would be my gut feeling about some of the snappyHexMesh parameters that influence the AMI interface, if anyone wants to correct me or comment please do !


faceType boundary|baffle; // using baffle doesn't improve the quality of the snapping

snapControls
{
//- Number of patch smoothing iterations before finding correspondence to surface
nSmoothPatch 3; // this will smooth the surface I'm feeding and thus make it further away from the original cylinder, thus I should keep it small

//- Relative distance for points to be attracted by surface feature point
// or edge. True distance is this factor times local
// maximum edge length.
tolerance 1.0; // I keep it that small to avoid attracting points from another AMI interface or from a nearby wall

//- Number of mesh displacement relaxation iterations.
nSolveIter 300; // the more the better, but also the slower

//- Maximum number of snapping relaxation iterations. Should stop
// before upon reaching a correct mesh.
nRelaxIter 5; // more = decreases the quality of the AMI cyclinder

// Feature snapping

// Number of feature edge snapping iterations.
// Leave out altogether to disable.
nFeatureSnapIter 10; // more = increases the quality of the AMI cyclinder

// Detect (geometric only) features by sampling the surface
// (default=false).
implicitFeatureSnap true; // new method

// Use castellatedMeshControls::features (default = true)
explicitFeatureSnap false; // old method

// Detect features between multiple surfaces
// (only for explicitFeatureSnap, default = false)
multiRegionFeatureSnap false; not clear

// snapping now uses ray tracing near the surfaces of thin structures in order to ensure that points are attracted only to sections of surface that are directly visible. This modification significantly reduces the problem in which a mesh boundary can jump between two surfaces of a thin structure.
detectNearSurfacesSnap true; // see description above, not sure it helps AMI
}

addLayersControls {} // doesn't help

meshQualityControls {} // could help but would take some days of guessing around

Regards,

-Louis

[Artur]

Thanks for the link. At work I am still working with OpenFOAM 2.2.2 (not enough time to upgrade all my code and cases!) and so I can't really comment on whether the new release does a better job.

As for explicit vs implicit snapping I seem to be using the former. I never tried the other one for AMIs, as you can tell from the fact that I actually had to check my dict files to verify which one I actually use.

I completely agree with the comments in your snappyHexMeshDict. Only small tweaks I could suggest are reducing the nSmoothPatch to 1 or 2 and pushing the nFeatureSnapIter to a very high number like 30. It's VERY expensive, I know, but I've found it makes a massive difference too. I also seem to keep the nRelaxIter lower, around 3, to have tighter convergence criteria on the mesh displacements etc.

Here are the quality criteria I use:

meshQualityControls
{
    //- Maximum non-orthogonality allowed. Set to 180 to disable.
    maxNonOrtho 65;//90;//65;

    //- Max skewness allowed. Set to <0 to disable.
    maxBoundarySkewness 20;//25;//20;
    maxInternalSkewness 4;//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 70;//100//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-16;//1e-15;       // 1e-13

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

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

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

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

    //- minFaceWeight (0 -> 0.5)
    minFaceWeight 0.02;//0.01;

    //- minVolRatio (0 -> 1)
    minVolRatio 0.01;//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;

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

Maybe try putting them in and see if it makes any difference. I've also attached an example dict file I used quite successfully, maybe there's something there I'm not seeing at the moment. Sorry I can't help more,

A

[louisgag]

Hi Artur,
Thanks for sharing your expertise. I'm curious to know why you chose
a) minRefinementCells 100;
and
b) maxNonOrtho 95;
was it a trade off between a good snap and a good quality mesh ?
Regards,
-Louis

Hi again Artur,
I am also curious to know whether you run snappy in parallel ?
-Louis

[Artur]

Hi,

a) I use minRefinementCells to prevent snappy from spending lots of iterations splitting just a hand-full of cells; it's somewhat arbitrary and doesn't help much with AMI or general mesh quality, will probably make it worse in fact; on final meshes I use for CFD I set it to a much smaller number to make sure they are properly resolved

b) maxNonOrtho 95 is used only in the relaxed iterations at the beginning; I guess sometimes it gives the mesh solver some time to deform the grid before it gets restrained by the quality criteria. I did some sensitivity on it some time ago and it seemed to help a bit, but I don't have any solid examples to support that; so use at your own risk

c) yes, I ran snappy in parallel in most cases; very seldom, for small grids, I just use one processor

A

[louisgag]

Just a quick update for those reading on,

I've ran into further problems when I was meshing a case where the spacing between the AMI interface and some of the surrounding walls is really small. I am in a situation where I have an inner wing, enclosed by an AMI interface, and then closed by a larger AMI interface which also contains fixed parts and which is really close to another wall.

I've tried many methods for meshing such a case with snappyHexMesh, and the only one I've found to work is the following:

Give an as uniform as possible refinement level to your AMI zones (min and max levels equal and no refinement near walls) and using something such as lowWeightCorrection 0.2;

• set faceType Baffle in snappyHexMesh -overwrite
• after snappyHexMesh first run createPatch -overwrite

• then run mergeOrSplitBaffles -split -overwrite
• then follow the usual procedure...

It gives me an excessively refined mesh but it's the only way that with a really small space available for the AMI interfaces I manage to avoid error messages such as,

Number of duplicate (not baffle) faces found: 4. This might indicate a problem.
Number of faces with non-consecutive shared points: 5. This might indicate a problem.
which deteriorate the mesh over the rotation.

Hope this can be useful for someone,

-Louis

[vinz]

I come back to this thread after a while since I am currently running some wind turbine cases with pimpleDyMFoam.

I completely gave up on using SHM for cyclicAMI patch a while ago, and apparently things are not so easy.
For my wind turbine case I use GridPro, and I have no problem with the cyclicAMI patches. The source and target weights are very close to 1 (between 0.999989 and 1.00004 with an average of 1.00012).

In the end, I think we gain some time making the mesh with a tool which is maybe a bit more complex but at least makes the computation run without problem.

[Artur]

Thank you Louis for posting the update, I'm sure it will save somebody's day one day!

As for using other tools, I've recently been using Pointwise a lot myself and found it to work quite well, it also has a ready OpenFOAM export function which saves a lot of frustrating conversions. I'm still a bit worried though that none of these tools are free, let alone open source, and so may not be available to everybody...

All the best,

A

[louisgag]

Thanks to both of you for the feedback.

You mention GridPro and Pointwise and I'm curious to know whether you work directly with the generated mesh or manually edit it after generation ?

Also, while we're at it, is anyone using Gmsh? It is free and opensource and I've used it when I was doing 2D AMI. I left it for snappyHexMesh when I started doing 3D because I think snappy is more straightforward, example cases for OpenFOAM exist, and it is, I think, better than Gmsh at generating 3D fluid meshes.

Gmsh has the advantage of giving you much more control over the mesh.

Regards,


-Louis

[Artur]

Hi,

I don't do any editing of the mesh after exporting from Pointiwse, all I have to do is adjust the patch types to AMI using changeDictionary.

I tried GMsh once and I wasn't too pleased to be honest, maybe now after having worked with a few alternatives I should give it a second go. Anyhow, I feel that Engrid (http://engits.eu/en/engrid) is slightly more user friendly, although takes a while to get used to. I never tried doing AMI grids with it though.

A

[vinz]

Originally Posted by louisgag

Thanks to both of you for the feedback.

You mention GridPro and Pointwise and I'm curious to know whether you work directly with the generated mesh or manually edit it after generation ?

-Louis

I don't do manual editing either. On this case I do use some openfoam tools in order to make rotate only one part of the mesh instead of a larger part as it was foreseen by the person who did the mesh (who doesn't know how openfoam is working with rotating meshes).

The tools are createBaffles, mergeOrSplitBaffles, and mergeMeshes.

If I had done the mesh from the beginning myself I wouldn't need those tools but it was a good exercice in the end.

I will present this work next week at SOWE 2015 in Milan.

[louisgag]

Originally Posted by vinz

I will present this work next week at SOWE 2015 in Milan.

Wow, that's right across the street from my office !
I'll see if I can drop in for your presentation.

-Louis

[coolcrasher]

Hi Stephanie

I have to work on simulating the 3D centrifugal pump in Openfoam 2.3 as part of Master Thesis. I have gone through tutorials in openfoam in simpleFoam and pimpleDymFoam to work with steady state and transient state.

I have seen that they use AMI between unconnected meshes to interpolate variables. However I am unable to implement it in my model. I have seen your post in CFD-online, you have worked on AMI ( http://www.cfse.ch/cfse/site/openfoam.php )
Any information or any help would be appreciated. Following is the description of my case.

I have generated the hexamesh using ANSYS-ICEM and exported in fluent format. After that I have converted to fluent format and using it in openfoam. I am currently using simpleFoam to simulate the steady case using kOmegaSST turbulence modelling. However I have following problems

1) There is no flow happening between rotor and stator. I have two seperate cell zones for rotor and stator and are not connected. Should I use AMI to connect both of them ?? I have seen in mixerVessel2D they have not used any AMI between stator and rotor. Also they have only cellzone for rotor.

2) How the AMI patches should be created ? Can you help me with writting down steps involved in brief ? Also for two interacting AMI patches is it necessary that number of faces should be same ??

Please guide me in this regard am new to OpenFoam.

[Tellur]

Hello everyone.

As many before me I have been dealing with the issue of 0 weight AMIs for the past 8 hours. Thankfully, all of you have shared experiences, troubles and success stories that made everything much easier.

I would like to share something of my own, given that my case is currently running with all your help.

No matter the choices I implemented with SHM, the error seemed to be there. My solution was fairly simple, abandoning SHM.

Using cfMesh, with a simple cartesianMesh, solved the problem (at least so far, simulation still running but weighted stable at 0.99). The AMIs still don't have exact cell counts (I'm guessing that's close to impossible) but the cartesian mesher is creating a much better mesh.

I should not that I am currently following linnemann's approach of creating separate meshes, joining them with mergeMesh, and splitting surfaces to create cellZones. My simple meshDicts can be found below.

For the fan region:

 /*--------------------------------*- C++ -*----------------------------------*\
| =========                 |                                                |
| \\      /  F ield         | cfMesh: A library for mesh generation          | 
|  \\    /   O peration     |                                                |
|   \\  /    A nd           | Author: Franjo Juretic                         | 
|    \\/     M anipulation  | E-mail: franjo.juretic@c-fields.com            |
\*---------------------------------------------------------------------------*/

FoamFile
{
    version   2.0;
    format    ascii;
    class     dictionary;
    location  "system";
    object    meshDict;
}

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

surfaceFile "Fan.stl";

maxCellSize 0.05;

localRefinement
{
    "Blades"
    {
    cellSize  0.01;
    }

    "FanRegion"
    {
    cellSize  0.01;
    }
}

boundaryLayers
{
    patchBoundaryLayers
    {
        Blades
        {
            nLayers 2;
            thicknessRatio 1.1;
        }
    }
    
    optimiseLayer 1;

    optimisationParameters
    {
        nSmoothNormals 3;
        maxNumIterations 2;
        featureSizeFactor 0.4;
        reCalculateNormals 1;
        relThicknessTol 0.1;
    }
}

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

For the rest of the room:

 /*--------------------------------*- C++ -*----------------------------------*\
| =========                 |                                                |
| \\      /  F ield         | cfMesh: A library for mesh generation          | 
|  \\    /   O peration     |                                                |
|   \\  /    A nd           | Author: Franjo Juretic                         | 
|    \\/     M anipulation  | E-mail: franjo.juretic@c-fields.com            |
\*---------------------------------------------------------------------------*/FoamFile
{
    version   2.0;
    format    ascii;
    class     dictionary;
    location  "system";
    object    meshDict;
}

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

surfaceFile "Room.stl";

maxCellSize 0.05;

localRefinement
{
    "Inlet"
    {
    cellSize  0.02;
    }

    "Outlet"
    {
    cellSize  0.02;
    }

    "FanRegion"
    {
    cellSize  0.01;
    }
}

boundaryLayers
{

    nLayers 1;
    thicknessRatio 1.1;

/*    patchBoundaryLayers
    {
        Blades
        {
            nLayers 1;
            thicknessRatio 1.1;
        }
    }
  */  
    optimiseLayer 1;

    optimisationParameters
    {
        nSmoothNormals 3;
        maxNumIterations 2;
        featureSizeFactor 0.4;
        reCalculateNormals 1;
        relThicknessTol 0.1;
    }
}

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

Hope this helps! There are better parameters for cfMesh but it's too late and I'm too tired to do it right. The above seem to work, feel free to offer improvements if you know!

Kind regards,
Theodore.

[Tellur]

Hello everyone,

Hope this isn't too far out of context here.

As a continuation of my previous post I was wondering if anyone has encountered problems with fan direction and flow direction in his/hers simulations.

It seems that I cannot create a downward flow no matter how the fan rotation is set. Is there a standard link between rotation direction and flow direction in openfoam? (e.g. general convention is ccw downwards, but in reality this depends on fan geometry). Or is it the actual fan geometry influencing the flow direction, as in reality?

P.S.: I have an inlet (window) near the fan, wondering if that is a problem.

Thanks in advance for any thoughts.

Kind regards,
T.

[louisgag]

Hi Theodore,

If you change the direction of rotation of your fan, the flow direction should change. If it doesn't you might have boundary conditions that are too strong and impede proper flow recirculation or that prevent flow from exiting where it should...

Can you give more details about the exact issue and your setup ?

Regards,


-Louis