CFD Online Logo CFD Online URL
www.cfd-online.com
[Sponsors]
Home > Forums > Software User Forums > OpenFOAM > OpenFOAM Running, Solving & CFD

Problem using AMI

Register Blogs Members List Search Today's Posts Mark Forums Read

Like Tree52Likes

Reply
 
LinkBack Thread Tools Search this Thread Display Modes
Old   January 26, 2015, 15:35
Default
  #221
Retired Super Moderator
 
Bruno Santos
Join Date: Mar 2009
Location: Lisbon, Portugal
Posts: 10,969
Blog Entries: 45
Rep Power: 127
wyldckat is a name known to allwyldckat is a name known to allwyldckat is a name known to allwyldckat is a name known to allwyldckat is a name known to allwyldckat is a name known to all
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
wyldckat is offline   Reply With Quote

Old   January 27, 2015, 03:44
Default
  #222
Member
 
vincent
Join Date: Apr 2011
Posts: 45
Rep Power: 14
vince_44 is on a distinguished road
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
Attached Files
File Type: txt controlDict.txt (1.8 KB, 27 views)
File Type: txt p.txt (1.3 KB, 20 views)
File Type: txt U.txt (1.5 KB, 22 views)
vince_44 is offline   Reply With Quote

Old   January 27, 2015, 14:43
Default
  #223
Retired Super Moderator
 
Bruno Santos
Join Date: Mar 2009
Location: Lisbon, Portugal
Posts: 10,969
Blog Entries: 45
Rep Power: 127
wyldckat is a name known to allwyldckat is a name known to allwyldckat is a name known to allwyldckat is a name known to allwyldckat is a name known to allwyldckat is a name known to all
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
wyldckat is offline   Reply With Quote

Old   February 3, 2015, 10:46
Default
  #224
Member
 
vincent
Join Date: Apr 2011
Posts: 45
Rep Power: 14
vince_44 is on a distinguished road
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
Attached Files
File Type: txt transportProperties.txt (989 Bytes, 21 views)
vince_44 is offline   Reply With Quote

Old   February 7, 2015, 06:45
Default
  #225
Retired Super Moderator
 
Bruno Santos
Join Date: Mar 2009
Location: Lisbon, Portugal
Posts: 10,969
Blog Entries: 45
Rep Power: 127
wyldckat is a name known to allwyldckat is a name known to allwyldckat is a name known to allwyldckat is a name known to allwyldckat is a name known to allwyldckat is a name known to all
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
wyldckat is offline   Reply With Quote

Old   February 13, 2015, 06:06
Default Problems with AMI and non-planar surfaces
  #226
New Member
 
Stefano Gaggero
Join Date: Mar 2013
Posts: 23
Rep Power: 12
Mashiro5 is on a distinguished road
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
Attached Images
File Type: jpg Domain.jpg (15.1 KB, 98 views)
File Type: jpg Domain_1.jpg (96.2 KB, 113 views)
Mashiro5 is offline   Reply With Quote

Old   February 14, 2015, 11:34
Default
  #227
Retired Super Moderator
 
Bruno Santos
Join Date: Mar 2009
Location: Lisbon, Portugal
Posts: 10,969
Blog Entries: 45
Rep Power: 127
wyldckat is a name known to allwyldckat is a name known to allwyldckat is a name known to allwyldckat is a name known to allwyldckat is a name known to allwyldckat is a name known to all
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 is offline   Reply With Quote

Old   February 14, 2015, 12:24
Default
  #228
New Member
 
Stefano Gaggero
Join Date: Mar 2013
Posts: 23
Rep Power: 12
Mashiro5 is on a distinguished road
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 View Post
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 is offline   Reply With Quote

Old   February 14, 2015, 14:44
Default
  #229
Retired Super Moderator
 
Bruno Santos
Join Date: Mar 2009
Location: Lisbon, Portugal
Posts: 10,969
Blog Entries: 45
Rep Power: 127
wyldckat is a name known to allwyldckat is a name known to allwyldckat is a name known to allwyldckat is a name known to allwyldckat is a name known to allwyldckat is a name known to all
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
Attached Images
File Type: jpg Screenshot from 2015-02-14 19:40:54.jpg (81.8 KB, 167 views)
wyldckat is offline   Reply With Quote

Old   February 14, 2015, 20:29
Default
  #230
New Member
 
Stefano Gaggero
Join Date: Mar 2013
Posts: 23
Rep Power: 12
Mashiro5 is on a distinguished road
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 View Post
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 is offline   Reply With Quote

Old   February 15, 2015, 07:35
Default
  #231
Retired Super Moderator
 
Bruno Santos
Join Date: Mar 2009
Location: Lisbon, Portugal
Posts: 10,969
Blog Entries: 45
Rep Power: 127
wyldckat is a name known to allwyldckat is a name known to allwyldckat is a name known to allwyldckat is a name known to allwyldckat is a name known to allwyldckat is a name known to all
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:
  1. 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:
  2. 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.
  3. 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
  4. 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
wyldckat is offline   Reply With Quote

Old   February 18, 2015, 15:15
Default
  #232
New Member
 
Stefano Gaggero
Join Date: Mar 2013
Posts: 23
Rep Power: 12
Mashiro5 is on a distinguished road
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 View Post
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:
  1. 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:
  2. 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.
  3. 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
  4. Have a look at the "extBlockMesh" contribution... and other contributions as well: http://openfoamwiki.net/index.php/BlockMesh
Best regards,
Bruno
Mashiro5 is offline   Reply With Quote

Old   February 22, 2015, 05:57
Default
  #233
Senior Member
 
Artur's Avatar
 
Artur
Join Date: May 2013
Location: Southampton, UK
Posts: 372
Rep Power: 19
Artur will become famous soon enough
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
Attached Images
File Type: jpg tooMuchForTheAMI.jpg (61.3 KB, 104 views)
Artur is offline   Reply With Quote

Old   March 15, 2015, 15:18
Default
  #234
New Member
 
Stefano Gaggero
Join Date: Mar 2013
Posts: 23
Rep Power: 12
Mashiro5 is on a distinguished road
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!
Attached Images
File Type: jpg Dominio.jpg (83.7 KB, 137 views)
Mashiro5 is offline   Reply With Quote

Old   March 15, 2015, 16:33
Default
  #235
Senior Member
 
Artur's Avatar
 
Artur
Join Date: May 2013
Location: Southampton, UK
Posts: 372
Rep Power: 19
Artur will become famous soon enough
Hi,

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

Quote:
Originally Posted by Mashiro5 View Post
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
Artur is offline   Reply With Quote

Old   March 16, 2015, 07:20
Default
  #236
New Member
 
Stefano Gaggero
Join Date: Mar 2013
Posts: 23
Rep Power: 12
Mashiro5 is on a distinguished road
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...
Mashiro5 is offline   Reply With Quote

Old   March 16, 2015, 08:17
Default
  #237
Senior Member
 
Artur's Avatar
 
Artur
Join Date: May 2013
Location: Southampton, UK
Posts: 372
Rep Power: 19
Artur will become famous soon enough
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
Artur is offline   Reply With Quote

Old   March 16, 2015, 17:34
Default
  #238
New Member
 
Stefano Gaggero
Join Date: Mar 2013
Posts: 23
Rep Power: 12
Mashiro5 is on a distinguished road
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
Mashiro5 is offline   Reply With Quote

Old   March 17, 2015, 04:01
Default
  #239
Senior Member
 
Artur's Avatar
 
Artur
Join Date: May 2013
Location: Southampton, UK
Posts: 372
Rep Power: 19
Artur will become famous soon enough
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
Artur is offline   Reply With Quote

Old   March 17, 2015, 05:49
Default
  #240
New Member
 
Stefano Gaggero
Join Date: Mar 2013
Posts: 23
Rep Power: 12
Mashiro5 is on a distinguished road
definitely not easy...

I hope extBlockMesh may help, but till now no success...!
Mashiro5 is offline   Reply With Quote

Reply

Thread Tools Search this Thread
Search this Thread:

Advanced Search
Display Modes

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


All times are GMT -4. The time now is 19:49.