Problem using AMI

wyldckat · January 26, 2015, 15:35

Greetings Vincent,

261 rad/s is in fact 2492.37 RPM... but still, this isn't the problem.
The sign for "omega" seems correct as well.

This is still a lot of guessing work you're asking from us here. My guess is that you've only let the propeller run for something like 0.5 or 2 seconds, which is far from enough to allow for the fluid flow to be fully developed and that would explain why you're seeing around 4 times as much force needed to displace the fluid.

If you can at least provide the files "controlDict", "U" and "p" (or "p_rgh", I'm not sure), it might make our lives easier in helping you diagnosing this problem.

Best regards,
Bruno

vince_44 · January 27, 2015, 03:44

Hey Bruno

Thanks for reply. I join the "p", "U" and "controlDict" file. Indeed, I perform my case during only 0.2s and may be it's not enough.

I'm going to perform a new calculation.

Best regards.

Vincent

wyldckat · January 27, 2015, 14:43

Hi Vincent,

In 0.2s at 2500RPM your propeller would do: 2500 / 60 * 0.2 = 8.3(3) rotations. I can understand why you would think this is enough for incompressible flow, but my guess is that at least a run of 2-5 seconds might be necessary.

But there is something that makes me more concerned about, in the "controlDict" file:

Code:

maxCo           2;

This is a very high number. "0.5" is the usual maximum value suggested for correct use of transient solvers. Anything above this value should be done with extreme caution and should be first tested by comparing with a case that used a smaller maximum number, before you can start pushing the limits on the solver capabilities.

Last but not least: what values did you define in the "constant/transportProperties" dictionary file?

Best regards,
Bruno

vince_44 · February 3, 2015, 10:46

Hi Bruno

Many thanks for your help and sorry for my late answer.

I'm beginner with pimpleDyMFoam and propeller case. I was too optimistic and I believed 0.2s was enough.

For the maxCo, I just take the same than in propeller tutorial.

I join my transportProperties file.

But now, I reduced this and perform a new calculation with 2s.

Best regards

wyldckat · February 7, 2015, 06:45

Hi Vincent,

Thanks for providing the "transportProperties" file.
Notes:

The "rho" entry will not be used by pimpleDyMFoam directly. Although it might be usable for some other post-processing utility.
Only the "nu" entry will be used and it does seem to be properly set to a value for water's kinematic viscosity.

Please let us know how it goes with the new settings. Hopefully you'll get better results at the end of this run.

Best regards,
Bruno

Mashiro5 · February 13, 2015, 06:06

Dears,

even if in a previous post I suggested the use of cyclicAMI, I had some problems especially when I tried to use them in the case of non planar patches. Generally, in order to model the steady state performances of propellers, I used to model only a "triangular slice" of the computational domain and apply, with success, periodic boundary conditions with AMI. This is a rather straightforward way to reduce the computational effort but especially in the case of very skewed propellers (it means propeller blades with an exagerated "babana" shape) it is possible that the triangular slice of the domain cuts two subsequent blades, causing some problems in the develpment of the boundary layers (if the mesh is calculated using snappyHexMesh) in correspondence of the intersection of the blade with the periodic patch. So I try to use "curved domains" (I used this kind of shapes routinely with StarCCM+, for instance) as that proposed in the figure. Unfortunately, even if the mesh generated with snappy is apparently ok, when I try to create the cyclicAMI (forcin rotationAxis and center of rotation) I had this error:

Code:

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

Create polyMesh for time = 2

Reading createPatchDict

Adding new patch Int_1_AMI as patch 9 from 
{
    type            cyclicAMI;
    matchTolerance  0.5;
    neighbourPatch  Int_2_AMI;
    transform       rotational;
    rotationAxis    ( 1 0 0 );
    rotationCentre  ( 0 0 0 );
}

Adding new patch Int_2_AMI as patch 10 from 
{
    type            cyclicAMI;
    neighbourPatch  Int_1_AMI;
    transform       rotational;
    rotationAxis    ( 1 0 0 );
    rotationCentre  ( 0 0 0 );
}


Moving faces from patch Int_1 to patch 9
Moving faces from patch Int_2 to patch 10

Doing topology modification to order faces.

AMI: Creating addressing and weights between 50109 source faces and 52528 target faces
--> FOAM Warning : 
    From function AMIMethod<SourcePatch, TargetPatch>::checkPatches()
    in file lnInclude/AMIMethod.C at line 57
    Source and target patch bounding boxes are not similar
    source box span     : (1.35892951488 0.602100236305 0.705581247807)
    target box span     : (1.35892951488 0.553761429124 0.717576680629)
    source box          : (-0.534949064255 -0.601774871349 -1.41759434052e-16) (0.82398045063 0.000325364955484 0.705581247807)
    target box          : (-0.534949064255 -0.136404545852 -1.1056390847e-16) (0.82398045063 0.417356883273 0.717576680629)
    inflated target box : (-0.616623072351 -0.218078553948 -0.0816740080961) (0.905654458726 0.499030891369 0.799250688725)


--> FOAM FATAL ERROR: 
Unable to set source and target faces

    From function void Foam::faceAreaWeightAMI<SourcePatch, TargetPatch>::setNextFaces(label&, label&, label&, const boolList&, labelList&, const DynamicList<label>&, bool) const
    in file lnInclude/faceAreaWeightAMI.C at line 300.

FOAM aborting

#0  Foam::error::printStack(Foam::Ostream&) in "/opt/openfoam230/platforms/linux64GccDPOpt/lib/libOpenFOAM.so"
#1  Foam::error::abort() in "/opt/openfoam230/platforms/linux64GccDPOpt/lib/libOpenFOAM.so"
#2  Foam::faceAreaWeightAMI<Foam::PrimitivePatch<Foam::face, Foam::SubList, Foam::Field<Foam::Vector<double> > const&, Foam::Vector<double> >, Foam::PrimitivePatch<Foam::face, Foam::SubList, Foam::Field<Foam::Vector<double> > const&, Foam::Vector<double> > >::calcAddressing(Foam::List<Foam::DynamicList<int, 0u, 2u, 1u> >&, Foam::List<Foam::DynamicList<double, 0u, 2u, 1u> >&, Foam::List<Foam::DynamicList<int, 0u, 2u, 1u> >&, Foam::List<Foam::DynamicList<double, 0u, 2u, 1u> >&, int, int) in "/opt/openfoam230/platforms/linux64GccDPOpt/lib/libmeshTools.so"
#3  Foam::faceAreaWeightAMI<Foam::PrimitivePatch<Foam::face, Foam::SubList, Foam::Field<Foam::Vector<double> > const&, Foam::Vector<double> >, Foam::PrimitivePatch<Foam::face, Foam::SubList, Foam::Field<Foam::Vector<double> > const&, Foam::Vector<double> > >::calculate(Foam::List<Foam::List<int> >&, Foam::List<Foam::List<double> >&, Foam::List<Foam::List<int> >&, Foam::List<Foam::List<double> >&, int, int) in "/opt/openfoam230/platforms/linux64GccDPOpt/lib/libmeshTools.so"
#4  Foam::AMIInterpolation<Foam::PrimitivePatch<Foam::face, Foam::SubList, Foam::Field<Foam::Vector<double> > const&, Foam::Vector<double> >, Foam::PrimitivePatch<Foam::face, Foam::SubList, Foam::Field<Foam::Vector<double> > const&, Foam::Vector<double> > >::update(Foam::PrimitivePatch<Foam::face, Foam::SubList, Foam::Field<Foam::Vector<double> > const&, Foam::Vector<double> > const&, Foam::PrimitivePatch<Foam::face, Foam::SubList, Foam::Field<Foam::Vector<double> > const&, Foam::Vector<double> > const&) in "/opt/openfoam230/platforms/linux64GccDPOpt/lib/libmeshTools.so"
#5  Foam::AMIInterpolation<Foam::PrimitivePatch<Foam::face, Foam::SubList, Foam::Field<Foam::Vector<double> > const&, Foam::Vector<double> >, Foam::PrimitivePatch<Foam::face, Foam::SubList, Foam::Field<Foam::Vector<double> > const&, Foam::Vector<double> > >::AMIInterpolation(Foam::PrimitivePatch<Foam::face, Foam::SubList, Foam::Field<Foam::Vector<double> > const&, Foam::Vector<double> > const&, Foam::PrimitivePatch<Foam::face, Foam::SubList, Foam::Field<Foam::Vector<double> > const&, Foam::Vector<double> > const&, Foam::autoPtr<Foam::searchableSurface> const&, Foam::faceAreaIntersect::triangulationMode const&, Foam::AMIInterpolation<Foam::PrimitivePatch<Foam::face, Foam::SubList, Foam::Field<Foam::Vector<double> > const&, Foam::Vector<double> >, Foam::PrimitivePatch<Foam::face, Foam::SubList, Foam::Field<Foam::Vector<double> > const&, Foam::Vector<double> > >::interpolationMethod const&, double, bool) in "/opt/openfoam230/platforms/linux64GccDPOpt/lib/libmeshTools.so"
#6  Foam::cyclicAMIPolyPatch::resetAMI(Foam::AMIInterpolation<Foam::PrimitivePatch<Foam::face, Foam::SubList, Foam::Field<Foam::Vector<double> > const&, Foam::Vector<double> >, Foam::PrimitivePatch<Foam::face, Foam::SubList, Foam::Field<Foam::Vector<double> > const&, Foam::Vector<double> > >::interpolationMethod const&) const in "/opt/openfoam230/platforms/linux64GccDPOpt/lib/libmeshTools.so"
#7  Foam::cyclicAMIPolyPatch::movePoints(Foam::PstreamBuffers&, Foam::Field<Foam::Vector<double> > const&) in "/opt/openfoam230/platforms/linux64GccDPOpt/lib/libmeshTools.so"
#8  Foam::polyBoundaryMesh::movePoints(Foam::Field<Foam::Vector<double> > const&) in "/opt/openfoam230/platforms/linux64GccDPOpt/lib/libOpenFOAM.so"
#9  Foam::polyMesh::movePoints(Foam::Field<Foam::Vector<double> > const&) in "/opt/openfoam230/platforms/linux64GccDPOpt/lib/libOpenFOAM.so"
#10  
 in "/opt/openfoam230/platforms/linux64GccDPOpt/bin/createPatch"
#11  __libc_start_main in "/lib/x86_64-linux-gnu/libc.so.6"
#12  
 in "/opt/openfoam230/platforms/linux64GccDPOpt/bin/createPatch"
Annullato (core dump creato)
stefano@stefano:~/OpenFOAM/stefano-2.3.0/KCS/KP505_snappy$ ^C
stefano@stefano:~/OpenFOAM/stefano-2.3.0/KCS/KP505_snappy$

As you can see I tried very high tolerances without success. I also force an highre writePrecision in the controlDict, as suggested in other posts (I do not rembember ehich :-( ) in order to try to avoid the warning "Source and target patch bounding boxes are not similar" but nothing changed.

I moved to cfMesh with exactly the same kind of problem.

On the other hand, if as suggested for rotational interfaces, I include also the rotationAngle option in the createPatch dict the error is:

Code:

stefano@stefano:~/OpenFOAM/stefano-2.3.0/KCS/KP505_snappy$ createPatch 
/*---------------------------------------------------------------------------*\
| =========                 |                                                 |
| \\      /  F ield         | OpenFOAM: The Open Source CFD Toolbox           |
|  \\    /   O peration     | Version:  2.3.0                                 |
|   \\  /    A nd           | Web:      www.OpenFOAM.org                      |
|    \\/     M anipulation  |                                                 |
\*---------------------------------------------------------------------------*/
Build  : 2.3.0-f5222ca19ce6
Exec   : createPatch
Date   : Feb 12 2015
Time   : 22:43:48
Host   : "stefano"
PID    : 4077
Case   : /home/stefano/OpenFOAM/stefano-2.3.0/KCS/KP505_snappy
nProcs : 1
sigFpe : Enabling floating point exception trapping (FOAM_SIGFPE).
fileModificationChecking : Monitoring run-time modified files using timeStampMaster
allowSystemOperations : Disallowing user-supplied system call operations

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

Create polyMesh for time = 2

Reading createPatchDict

Adding new patch Int_1_AMI as patch 9 from 
{
    type            cyclicAMI;
    matchTolerance  0.5;
    neighbourPatch  Int_2_AMI;
    transform       rotational;
    rotationAxis    ( 1 0 0 );
    rotationCentre  ( 0 0 0 );
    rotationAngle   72;
}

Adding new patch Int_2_AMI as patch 10 from 
{
    type            cyclicAMI;
    neighbourPatch  Int_1_AMI;
    transform       rotational;
    rotationAxis    ( 1 0 0 );
    rotationCentre  ( 0 0 0 );
}


Moving faces from patch Int_1 to patch 9
Moving faces from patch Int_2 to patch 10

Doing topology modification to order faces.

--> FOAM Warning : 
    From function void Foam::cyclicAMIPolyPatch::calcTransforms(const primitivePatch&, const pointField&, const vectorField&, const pointField&, const vectorField&)
    in file AMIInterpolation/patches/cyclicAMI/cyclicAMIPolyPatch/cyclicAMIPolyPatch.C at line 204
    Patch areas are not consistent within 50 % indicating a possible error in the specified angle of rotation
    owner patch     : Int_1_AMI
    neighbour patch : Int_2_AMI
    angle           : -72 deg
    area error      : 84.6769396127 %    match tolerance : 0.5
--> FOAM Warning : 
    From function void Foam::cyclicAMIPolyPatch::calcTransforms(const primitivePatch&, const pointField&, const vectorField&, const pointField&, const vectorField&)
    in file AMIInterpolation/patches/cyclicAMI/cyclicAMIPolyPatch/cyclicAMIPolyPatch.C at line 204
    Patch areas are not consistent within 50 % indicating a possible error in the specified angle of rotation
    owner patch     : Int_1_AMI
    neighbour patch : Int_2_AMI
    angle           : -72 deg
    area error      : 84.6769396127 %    match tolerance : 0.5
AMI: Creating addressing and weights between 50109 source faces and 52528 target faces


--> FOAM FATAL ERROR: 
Unable to set source and target faces

    From function void Foam::faceAreaWeightAMI<SourcePatch, TargetPatch>::setNextFaces(label&, label&, label&, const boolList&, labelList&, const DynamicList<label>&, bool) const
    in file lnInclude/faceAreaWeightAMI.C at line 300.

FOAM aborting

#0  Foam::error::printStack(Foam::Ostream&) in "/opt/openfoam230/platforms/linux64GccDPOpt/lib/libOpenFOAM.so"
#1  Foam::error::abort() in "/opt/openfoam230/platforms/linux64GccDPOpt/lib/libOpenFOAM.so"
#2  Foam::faceAreaWeightAMI<Foam::PrimitivePatch<Foam::face, Foam::SubList, Foam::Field<Foam::Vector<double> > const&, Foam::Vector<double> >, Foam::PrimitivePatch<Foam::face, Foam::SubList, Foam::Field<Foam::Vector<double> > const&, Foam::Vector<double> > >::calcAddressing(Foam::List<Foam::DynamicList<int, 0u, 2u, 1u> >&, Foam::List<Foam::DynamicList<double, 0u, 2u, 1u> >&, Foam::List<Foam::DynamicList<int, 0u, 2u, 1u> >&, Foam::List<Foam::DynamicList<double, 0u, 2u, 1u> >&, int, int) in "/opt/openfoam230/platforms/linux64GccDPOpt/lib/libmeshTools.so"
#3  Foam::faceAreaWeightAMI<Foam::PrimitivePatch<Foam::face, Foam::SubList, Foam::Field<Foam::Vector<double> > const&, Foam::Vector<double> >, Foam::PrimitivePatch<Foam::face, Foam::SubList, Foam::Field<Foam::Vector<double> > const&, Foam::Vector<double> > >::calculate(Foam::List<Foam::List<int> >&, Foam::List<Foam::List<double> >&, Foam::List<Foam::List<int> >&, Foam::List<Foam::List<double> >&, int, int) in "/opt/openfoam230/platforms/linux64GccDPOpt/lib/libmeshTools.so"
#4  Foam::AMIInterpolation<Foam::PrimitivePatch<Foam::face, Foam::SubList, Foam::Field<Foam::Vector<double> > const&, Foam::Vector<double> >, Foam::PrimitivePatch<Foam::face, Foam::SubList, Foam::Field<Foam::Vector<double> > const&, Foam::Vector<double> > >::update(Foam::PrimitivePatch<Foam::face, Foam::SubList, Foam::Field<Foam::Vector<double> > const&, Foam::Vector<double> > const&, Foam::PrimitivePatch<Foam::face, Foam::SubList, Foam::Field<Foam::Vector<double> > const&, Foam::Vector<double> > const&) in "/opt/openfoam230/platforms/linux64GccDPOpt/lib/libmeshTools.so"
#5  Foam::AMIInterpolation<Foam::PrimitivePatch<Foam::face, Foam::SubList, Foam::Field<Foam::Vector<double> > const&, Foam::Vector<double> >, Foam::PrimitivePatch<Foam::face, Foam::SubList, Foam::Field<Foam::Vector<double> > const&, Foam::Vector<double> > >::AMIInterpolation(Foam::PrimitivePatch<Foam::face, Foam::SubList, Foam::Field<Foam::Vector<double> > const&, Foam::Vector<double> > const&, Foam::PrimitivePatch<Foam::face, Foam::SubList, Foam::Field<Foam::Vector<double> > const&, Foam::Vector<double> > const&, Foam::autoPtr<Foam::searchableSurface> const&, Foam::faceAreaIntersect::triangulationMode const&, Foam::AMIInterpolation<Foam::PrimitivePatch<Foam::face, Foam::SubList, Foam::Field<Foam::Vector<double> > const&, Foam::Vector<double> >, Foam::PrimitivePatch<Foam::face, Foam::SubList, Foam::Field<Foam::Vector<double> > const&, Foam::Vector<double> > >::interpolationMethod const&, double, bool) in "/opt/openfoam230/platforms/linux64GccDPOpt/lib/libmeshTools.so"
#6  Foam::cyclicAMIPolyPatch::resetAMI(Foam::AMIInterpolation<Foam::PrimitivePatch<Foam::face, Foam::SubList, Foam::Field<Foam::Vector<double> > const&, Foam::Vector<double> >, Foam::PrimitivePatch<Foam::face, Foam::SubList, Foam::Field<Foam::Vector<double> > const&, Foam::Vector<double> > >::interpolationMethod const&) const in "/opt/openfoam230/platforms/linux64GccDPOpt/lib/libmeshTools.so"
#7  Foam::cyclicAMIPolyPatch::movePoints(Foam::PstreamBuffers&, Foam::Field<Foam::Vector<double> > const&) in "/opt/openfoam230/platforms/linux64GccDPOpt/lib/libmeshTools.so"
#8  Foam::polyBoundaryMesh::movePoints(Foam::Field<Foam::Vector<double> > const&) in "/opt/openfoam230/platforms/linux64GccDPOpt/lib/libOpenFOAM.so"
#9  Foam::polyMesh::movePoints(Foam::Field<Foam::Vector<double> > const&) in "/opt/openfoam230/platforms/linux64GccDPOpt/lib/libOpenFOAM.so"
#10  
 in "/opt/openfoam230/platforms/linux64GccDPOpt/bin/createPatch"
#11  __libc_start_main in "/lib/x86_64-linux-gnu/libc.so.6"
#12  
 in "/opt/openfoam230/platforms/linux64GccDPOpt/bin/createPatch"

that is quite strange due to the fact that interfaces are exactly spaced by 72°.

I' pretty sure the problem is in the mesh. When I import exactly the same domain but meshed with StarCCM+ for instance, AMI works perfectly with uniform min, max and average weights equal to 1, due to the fact that StarCCM+ is able to produce conformal matching interfaces.

Do you have any suggestion in order to use snappy of cfMesh with this kind of computational domains/curved interfaces?

Many thanks,
Stefano

wyldckat · February 14, 2015, 11:34

Quick answer - @Stefano: I strongly suggest that you upgrade to OpenFOAM 2.3.1 or 2.3.x, because that crash looks like a familiar bug to me...
If you had provided a test case, I could have tested this just now with the various versions of OpenFOAM I have installed.

Mashiro5 · February 14, 2015, 12:24

Dear Bruno, thank you for your quick suggestion. I will try as soon as possible to upgrade to OF2.3.1 and test my geometry.

For those who would like to test it by their own (Bruno, you are welcome

!), you can find the complete test case (for naval architects it is the well-known case of the KCS ship) following this dropbox link:

https://dl.dropboxusercontent.com/u/..._curved.tar.gz

thank you again for any suggestion!
Stefano

Quote:

Originally Posted by wyldckat

Quick answer - @Stefano: I strongly suggest that you upgrade to OpenFOAM 2.3.1 or 2.3.x, because that crash looks like a familiar bug to me...
If you had provided a test case, I could have tested this just now with the various versions of OpenFOAM I have installed.

wyldckat · February 14, 2015, 14:44

Hi Stefano,

The case you had provided had a damaged "createPatchDict".

I've looked at your case, by running with OpenFOAM 2.3.x. And after finishing meshing it, I think you're asking too much from OpenFOAM's "cyclicAMI" matching algorithm. As far as I can figure out, the curves you have between each level are extremely hard to match to each other.

Attached is an image that overlaps the result from the "Int_1" patch over the "Int_2" patch, done by applying the Transform filter to one of them with 72 degree rotation over X. As you can see in the image, you're asking for too much from the matching algorithm for those particular large radius curves, which got meshed a bit poorly

Best regards,
Bruno

Mashiro5 · February 14, 2015, 20:29

Dear Bruno, thank you again for your extermely rapid answer and the effort you put to solve my case.. and sorry for the damaged file

Me too I believe that the mesh on the interfaces is too coarse. The snappyhexmesh dict is one of those I used in order to understand the reasons of the problem. Among them I have solutions with very very fine meshes on th einterfaces and I checked, only qualitatively, in paraview the matching between the interfaces. In any case I never had AMI. I also used differnt cuurved domains withouth success. I can understand the difficulties in the matching algorithm: sometimes I had "bad point" errors, also in the case of planar interfaces (it happens when the propeller blade, due to skew, is cut by the interface and I have portion of differnt blades in the domain, feature curves are not properly treated or the boundary layer not correctly extruded). These are the reasons to use a curved domain, to completely include one single blade in the computational domain. What sounds strange to me is the warning and the subsequent error of "different bounding box". Do snappy alters so much the original patches to avoid any matching?
The same kind of errors happens when I completely change the meshing approche and I use cfMesh. In this case, with very coarse meshes (not useful for computations :-(), the matching is succesfull but with weights very very low.

Thank you again,
Have a nice (half)weekend,
Bests,
Stefano

Quote:

Originally Posted by wyldckat

Hi Stefano,

The case you had provided had a damaged "createPatchDict".

I've looked at your case, by running with OpenFOAM 2.3.x. And after finishing meshing it, I think you're asking too much from OpenFOAM's "cyclicAMI" matching algorithm. As far as I can figure out, the curves you have between each level are extremely hard to match to each other.

Attached is an image that overlaps the result from the "Int_1" patch over the "Int_2" patch, done by applying the Transform filter to one of them with 72 degree rotation over X. As you can see in the image, you're asking for too much from the matching algorithm for those particular large radius curves, which got meshed a bit poorly

Best regards,
Bruno

wyldckat · February 15, 2015, 07:35

Hi Stefano,

I believe that the big differences in the bounding boxes is actually due to the algorithm not being able to properly ascertain how the patch was rotated.

There are a few details that come to mind:

The base mesh is what gives us the optimum control over what can be meshed. If you use SwiftBlock ( http://openfoamwiki.net/index.php/Contrib/SwiftBlock ) it might be a lot easier to design the base mesh to fit the special design you need in the first place. For example:
- It might make a lot of sense to use something like makeAxialMesh: http://openfoamwiki.net/index.php/Contrib/MakeAxialMesh
- And don't disregard the possibility to use blockMesh's "polyLine" feature... although you'll have to be careful not to overlap two "dual/multiple oriented curved edges": http://www.openfoam.org/mantisbt/view.php?id=1396
Only one patch for each side is asking too much from the matching algorithm. Dividing each side into at least 3 parts should make things easier.
Sometimes we can't do the mesh in a single step. Actually, snappyHexMesh already hints at us with its 1+3 steps it uses (base mesh + castellation + snapping + layer adding). Have a look at the tutorial case "mesh/moveDynamicMesh/SnakeRiverCanyon/" and you'll see that you can morph meshes dynamically . You could do that either before or after adding the blade
Have a look at the "extBlockMesh" contribution... and other contributions as well: http://openfoamwiki.net/index.php/BlockMesh

Best regards,
Bruno

Mashiro5 · February 18, 2015, 15:15

Dear Bruno,

thank you again for your quick and always exaustive answer.. I will try blockMesh with polyline and extBlockMesh in order to try to cope the problems with the interface.

I already tested something similar to "MakeAxialMesh" buut i encountered lot of problems with very "non-cubic" cells to be snapped on STLs.

Bests,

Stefano

Quote:

Originally Posted by wyldckat

Hi Stefano,

I believe that the big differences in the bounding boxes is actually due to the algorithm not being able to properly ascertain how the patch was rotated.

There are a few details that come to mind:

The base mesh is what gives us the optimum control over what can be meshed. If you use SwiftBlock ( http://openfoamwiki.net/index.php/Contrib/SwiftBlock ) it might be a lot easier to design the base mesh to fit the special design you need in the first place. For example:
- It might make a lot of sense to use something like makeAxialMesh: http://openfoamwiki.net/index.php/Contrib/MakeAxialMesh
- And don't disregard the possibility to use blockMesh's "polyLine" feature... although you'll have to be careful not to overlap two "dual/multiple oriented curved edges": http://www.openfoam.org/mantisbt/view.php?id=1396
Only one patch for each side is asking too much from the matching algorithm. Dividing each side into at least 3 parts should make things easier.
Sometimes we can't do the mesh in a single step. Actually, snappyHexMesh already hints at us with its 1+3 steps it uses (base mesh + castellation + snapping + layer adding). Have a look at the tutorial case "mesh/moveDynamicMesh/SnakeRiverCanyon/" and you'll see that you can morph meshes dynamically . You could do that either before or after adding the blade
Have a look at the "extBlockMesh" contribution... and other contributions as well: http://openfoamwiki.net/index.php/BlockMesh

Best regards,
Bruno

Artur · February 22, 2015, 05:57

Hi All,

Stefano, I am currently in a pretty much identical situation - I'm creating a wedge grid for a marine propeller with AMI cyclic conditions. I've encountered (unsurprisingly) the same problem as you, except I am using structured grids. I've ran a few tests on a simple setup and arrived at the conclusion Bruno has given - I was trying to exploit the flexibility of the AMI too much with my patches being too different, see attached picture.

I have previously tried to use snappy for something similar but found the meshes it gave me of very poor quality when the underlying blockMesh grid had high aspect ratios (which are inevitable in this context I think). If you can't get snappy to work then perhaps tetrahedrals will do the job for you? (e.g. http://engits.eu/en/engrid )

Best of luck anyhow (to you and to me

),

A

Mashiro5 · March 15, 2015, 15:18

Dear Bruno, dear Artur,

Finally I have time to answer and show my succesfull results!
Following the suggestions by Bruno, I've found that the only way to work with "curved" domain is to have the domain and "high quality" boundaries by blockMesh, that is the only way to avoid snappy change their shape (excpet by increasing the number of cells) ... modifications by snappy are the cause of the warnings, the "sorce and target" error and so on...

Unfortunately I was not lucky with extBlockMesh (for my geometry the smoothing stops at the first iiteration.. on the forum also other users had this problem but a clear solution has not yet been poste) and I have to built entirely the domain using block, polilines and splines.

In this way interfaces match correctly (with all weights close to 1) but cells are a bit to non-orthogonal (and non cubic) especially (but fortunately) far from the place where the propeller has to be snapped.

I tried to use extBlock only as a smoother to improve the quality of the cells.. also in this case without success...

So the only drawbak of this procedure is the quality of lots of cells far from the propeller, that require loosening of the quality factor for snappyHexMesh.
However results, also in terms of predicted forces, are satisfactory, as you can see from the figure.

So, thank you to all who contributes to these successfull results.. of course any suggetsion to improve the quality of the base mesh is welcome!

Artur · March 15, 2015, 16:33

Hi,

Great to see you've made progress, the mesh looks really good I must say.

Quote:

Originally Posted by Mashiro5

Following the suggestions by Bruno, I've found that the only way to work with "curved" domain is to have the domain and "high quality" boundaries by blockMesh, that is the only way to avoid snappy change their shape (excpet by increasing the number of cells)

By this do you mean you need a very refined background block mesh region?

A

Mashiro5 · March 16, 2015, 07:20

I mean that I have to built the entire curved domain including the interfaces directly using blockmesh. My previous tentatives were to build a regular block with blockmesh and then to snap the curved interfaces using snappy.
Actually I use snappy only to snap the blade and the hub. Inlet,outlet, interfaces and so on are previously defined with blockMesh...

Artur · March 16, 2015, 08:17

OK, I see. That makes sense since like this you have nearly perfectly matching cyclics, so you could probably get away even with the cyclic and not even amiCyclic type.

Thanks a lot for sharing this, I definitely have to try your method this week

All the best,

A

Mashiro5 · March 16, 2015, 17:34

Dear Artur,

unfortunately in my case I have to use AMI due to the fact that the blade is non symmetric, so snappyHexMesh refinements act differently on the two interfaces (for instance the blade leading edge is closer to the right interface than the blade trailing edge to the left interface). However until you work only with refinements (no prism layer i tersecting the interfaces) AMI weight are close to 1 anyway.
The only issue is the higher non-ortogonality of the cells far from the axis of the domain...

Bests,
Stefano

Artur · March 17, 2015, 04:01

Hi,

I see, well at least AMI works for you

I've found the same problem with highly non-orthogonal cells far away from the axis of rotation. Since that's a constraint on the domain shape rather than a mesh generation issue I personally don't think much can be done about it. Maybe you could deform the mesh there somehow using blockMesh to get something like this:

deformedOuterDomains.jpg

I don't think this will be easy to do though.

A

Mashiro5 · March 17, 2015, 05:49

definitely not easy...

I hope extBlockMesh may help, but till now no success...!

January 27, 2015, 14:43		#223
wyldckat Retired Super Moderator Bruno Santos Join Date: Mar 2009 Location: Lisbon, Portugal Posts: 10,975 Blog Entries: 45 Rep Power: 128	Hi Vincent, In 0.2s at 2500RPM your propeller would do: 2500 / 60 * 0.2 = 8.3(3) rotations. I can understand why you would think this is enough for incompressible flow, but my guess is that at least a run of 2-5 seconds might be necessary. But there is something that makes me more concerned about, in the "controlDict" file: Code: maxCo 2; This is a very high number. "0.5" is the usual maximum value suggested for correct use of transient solvers. Anything above this value should be done with extreme caution and should be first tested by comparing with a case that used a smaller maximum number, before you can start pushing the limits on the solver capabilities. Last but not least: what values did you define in the "constant/transportProperties" dictionary file? Best regards, Bruno

February 7, 2015, 06:45		#225
wyldckat Retired Super Moderator Bruno Santos Join Date: Mar 2009 Location: Lisbon, Portugal Posts: 10,975 Blog Entries: 45 Rep Power: 128	Hi Vincent, Thanks for providing the "transportProperties" file. Notes: The "rho" entry will not be used by pimpleDyMFoam directly. Although it might be usable for some other post-processing utility. Only the "nu" entry will be used and it does seem to be properly set to a value for water's kinematic viscosity. Please let us know how it goes with the new settings. Hopefully you'll get better results at the end of this run. Best regards, Bruno

February 14, 2015, 11:34		#227
wyldckat Retired Super Moderator Bruno Santos Join Date: Mar 2009 Location: Lisbon, Portugal Posts: 10,975 Blog Entries: 45 Rep Power: 128	Quick answer - @Stefano: I strongly suggest that you upgrade to OpenFOAM 2.3.1 or 2.3.x, because that crash looks like a familiar bug to me... If you had provided a test case, I could have tested this just now with the various versions of OpenFOAM I have installed. __________________ OpenFOAM: FAQ \| Getting started Forum: How to get help, to post code/output and forum guide Read this before sending me PM

February 15, 2015, 07:35		#231
wyldckat Retired Super Moderator Bruno Santos Join Date: Mar 2009 Location: Lisbon, Portugal Posts: 10,975 Blog Entries: 45 Rep Power: 128	Hi Stefano, I believe that the big differences in the bounding boxes is actually due to the algorithm not being able to properly ascertain how the patch was rotated. There are a few details that come to mind: The base mesh is what gives us the optimum control over what can be meshed. If you use SwiftBlock ( http://openfoamwiki.net/index.php/Contrib/SwiftBlock ) it might be a lot easier to design the base mesh to fit the special design you need in the first place. For example: It might make a lot of sense to use something like makeAxialMesh: http://openfoamwiki.net/index.php/Contrib/MakeAxialMesh And don't disregard the possibility to use blockMesh's "polyLine" feature... although you'll have to be careful not to overlap two "dual/multiple oriented curved edges": http://www.openfoam.org/mantisbt/view.php?id=1396 Only one patch for each side is asking too much from the matching algorithm. Dividing each side into at least 3 parts should make things easier. Sometimes we can't do the mesh in a single step. Actually, snappyHexMesh already hints at us with its 1+3 steps it uses (base mesh + castellation + snapping + layer adding). Have a look at the tutorial case "mesh/moveDynamicMesh/SnakeRiverCanyon/" and you'll see that you can morph meshes dynamically . You could do that either before or after adding the blade Have a look at the "extBlockMesh" contribution... and other contributions as well: http://openfoamwiki.net/index.php/BlockMesh Best regards, Bruno Mashiro5 likes this. Last edited by wyldckat; February 15, 2015 at 15:53. Reason: fixed typos

Similar Threads
Thread	Thread Starter	Forum	Replies	Last Post
UDF compiling problem	Wouter	Fluent UDF and Scheme Programming	6	June 6, 2012 04:43
Gambit - meshing over airfoil wrapping (?) problem	JFDC	FLUENT	1	July 11, 2011 05:59
natural convection problem for a CHT problem	Se-Hee	CFX	2	June 10, 2007 06:29
Adiabatic and Rotating wall (Convection problem)	ParodDav	CFX	5	April 29, 2007 19:13
Is this problem well posed?	Thomas P. Abraham	Main CFD Forum	5	September 8, 1999 14:52

January 26, 2015, 15:35		#221
wyldckat Retired Super Moderator Bruno Santos Join Date: Mar 2009 Location: Lisbon, Portugal Posts: 10,975 Blog Entries: 45 Rep Power: 128	Greetings Vincent, 261 rad/s is in fact 2492.37 RPM... but still, this isn't the problem. The sign for "omega" seems correct as well. This is still a lot of guessing work you're asking from us here. My guess is that you've only let the propeller run for something like 0.5 or 2 seconds, which is far from enough to allow for the fluid flow to be fully developed and that would explain why you're seeing around 4 times as much force needed to displace the fluid. If you can at least provide the files "controlDict", "U" and "p" (or "p_rgh", I'm not sure), it might make our lives easier in helping you diagnosing this problem. Best regards, Bruno

March 16, 2015, 07:20		#236
Mashiro5 New Member Stefano Gaggero Join Date: Mar 2013 Posts: 23 Rep Power: 13	I mean that I have to built the entire curved domain including the interfaces directly using blockmesh. My previous tentatives were to build a regular block with blockmesh and then to snap the curved interfaces using snappy. Actually I use snappy only to snap the blade and the hub. Inlet,outlet, interfaces and so on are previously defined with blockMesh...

March 16, 2015, 08:17		#237
Artur Senior Member Artur Join Date: May 2013 Location: Southampton, UK Posts: 372 Rep Power: 19	OK, I see. That makes sense since like this you have nearly perfectly matching cyclics, so you could probably get away even with the cyclic and not even amiCyclic type. Thanks a lot for sharing this, I definitely have to try your method this week All the best, A

March 16, 2015, 17:34		#238
Mashiro5 New Member Stefano Gaggero Join Date: Mar 2013 Posts: 23 Rep Power: 13	Dear Artur, unfortunately in my case I have to use AMI due to the fact that the blade is non symmetric, so snappyHexMesh refinements act differently on the two interfaces (for instance the blade leading edge is closer to the right interface than the blade trailing edge to the left interface). However until you work only with refinements (no prism layer i tersecting the interfaces) AMI weight are close to 1 anyway. The only issue is the higher non-ortogonality of the cells far from the axis of the domain... Bests, Stefano

March 17, 2015, 04:01		#239
Artur Senior Member Artur Join Date: May 2013 Location: Southampton, UK Posts: 372 Rep Power: 19	Hi, I see, well at least AMI works for you I've found the same problem with highly non-orthogonal cells far away from the axis of rotation. Since that's a constraint on the domain shape rather than a mesh generation issue I personally don't think much can be done about it. Maybe you could deform the mesh there somehow using blockMesh to get something like this: deformedOuterDomains.jpg I don't think this will be easy to do though. A

March 17, 2015, 05:49		#240
Mashiro5 New Member Stefano Gaggero Join Date: Mar 2013 Posts: 23 Rep Power: 13	definitely not easy... I hope extBlockMesh may help, but till now no success...!