[muhammss]

Hey,

I am running a wind turbine simulation based on the propeller tutorial in openFoam. However, my solution run's fine for a while but after sometime the minimum value of target patch value goes to zero due to which the simulation crash.
AMI: Patch target sum(weights) min/max/average = 0, 1.31696, 1.00247
Can somebody please help me what i need to do to avoid such weights in the patch? Do i need to again do all the meshing again? I really want to avoid it since it was very hectic altogether.
below is the simulation history just before it crashed.

solidBodyMotionFunctions::rotatingMotion::transfor mation(): Time = 0.0278994 transformation: ((0 0 0) (0.999976 (0.00697478 0 0)))
AMI: Creating addressing and weights between 23859 source faces and 24266 target faces
AMI: Patch source sum(weights) min/max/average = 0.986984, 1.3968, 1.00588
AMI: Patch target sum(weights) min/max/average = 0.927878, 1.22905, 1.00257
PIMPLE: iteration 1
smoothSolver: Solving for Ux, Initial residual = 3.06059e-05, Final residual = 8.07053e-11, No Iterations 1
smoothSolver: Solving for Uy, Initial residual = 0.000213831, Final residual = 3.97398e-10, No Iterations 1
smoothSolver: Solving for Uz, Initial residual = 0.000488367, Final residual = 8.27354e-10, No Iterations 1
GAMG: Solving for p, Initial residual = 0.000873145, Final residual = 7.57972e-06, No Iterations 1
time step continuity errors : sum local = 1.99807e-12, global = 1.33977e-14, cumulative = -2.69842e-12
PIMPLE: iteration 2
smoothSolver: Solving for Ux, Initial residual = 7.6585e-06, Final residual = 2.10173e-11, No Iterations 1
smoothSolver: Solving for Uy, Initial residual = 5.33958e-05, Final residual = 1.03302e-10, No Iterations 1
smoothSolver: Solving for Uz, Initial residual = 0.000121995, Final residual = 2.14589e-10, No Iterations 1
GAMG: Solving for p, Initial residual = 0.00253285, Final residual = 7.7775e-07, No Iterations 3
time step continuity errors : sum local = 2.04369e-13, global = 4.55125e-14, cumulative = -2.65291e-12
smoothSolver: Solving for epsilon, Initial residual = 3.25688e-08, Final residual = 3.91035e-11, No Iterations 1
smoothSolver: Solving for k, Initial residual = 8.77933e-07, Final residual = 5.25053e-11, No Iterations 1
ExecutionTime = 8231.56 s ClockTime = 8233 s

forces forces output:
sum of forces:
pressure : (-101090 2047.83 90.0856)
viscous : (425.65 -2.11477 -0.235153)
porous : (0 0 0)
sum of moments:
pressure : (-1.55338e+07 38333.9 1012.59)
viscous : (-6283.84 -85.6116 4.80584)
porous : (0 0 0)

Courant Number mean: 0.000204503 max: 0.999788
deltaT = 8.91374e-05
Time = 0.0279885

solidBodyMotionFunctions::rotatingMotion::transfor mation(): Time = 0.0279885 transformation: ((0 0 0) (0.999976 (0.00699707 0 0)))
AMI: Creating addressing and weights between 23859 source faces and 24266 target faces
AMI: Patch source sum(weights) min/max/average = 0.987031, 1.39698, 1.00588
AMI: Patch target sum(weights) min/max/average = 0.927634, 6.787, 1.00304
PIMPLE: iteration 1
smoothSolver: Solving for Ux, Initial residual = 3.05357e-05, Final residual = 8.07259e-11, No Iterations 1
smoothSolver: Solving for Uy, Initial residual = 0.000212966, Final residual = 3.96325e-10, No Iterations 1
smoothSolver: Solving for Uz, Initial residual = 0.000486642, Final residual = 8.24374e-10, No Iterations 1
GAMG: Solving for p, Initial residual = 0.000867852, Final residual = 7.4861e-06, No Iterations 1
time step continuity errors : sum local = 1.96148e-12, global = 1.10639e-14, cumulative = -2.64184e-12
PIMPLE: iteration 2
smoothSolver: Solving for Ux, Initial residual = 7.64088e-06, Final residual = 2.10211e-11, No Iterations 1
smoothSolver: Solving for Uy, Initial residual = 5.318e-05, Final residual = 1.02991e-10, No Iterations 1
smoothSolver: Solving for Uz, Initial residual = 0.000121565, Final residual = 2.13811e-10, No Iterations 1
GAMG: Solving for p, Initial residual = 0.00252295, Final residual = 8.05773e-07, No Iterations 3
time step continuity errors : sum local = 2.10458e-13, global = 4.80043e-14, cumulative = -2.59384e-12
smoothSolver: Solving for epsilon, Initial residual = 3.25134e-08, Final residual = 3.88938e-11, No Iterations 1
smoothSolver: Solving for k, Initial residual = 8.78791e-07, Final residual = 5.22215e-11, No Iterations 1
ExecutionTime = 8322.19 s ClockTime = 8324 s

forces forces output:
sum of forces:
pressure : (-101091 1964.54 89.9517)
viscous : (425.182 -2.11331 -0.235278)
porous : (0 0 0)
sum of moments:
pressure : (-1.55275e+07 38375 983.145)
viscous : (-6277.26 -84.9156 4.82144)
porous : (0 0 0)

Courant Number mean: 0.000204541 max: 0.999794
deltaT = 8.91558e-05
Time = 0.0280776

solidBodyMotionFunctions::rotatingMotion::transfor mation(): Time = 0.0280776 transformation: ((0 0 0) (0.999975 (0.00701935 0 0)))
AMI: Creating addressing and weights between 23859 source faces and 24266 target faces
AMI: Patch source sum(weights) min/max/average = 0.987078, 1.39716, 1.00589
AMI: Patch target sum(weights) min/max/average = 0, 1.31696, 1.00247
PIMPLE: iteration 1
rank 0 in job 57 no_46067 caused collective abort of all ranks
exit status of rank 0: killed by signal 8

[Artur]

Hi,

This is a well-known problem using AMI and rotating meshes in OpenFOAM, see e.g. here: http://www.cfd-online.com/Forums/ope...-tutorial.html .

From my experience, the key steps to avoid it are:
1. check, re-check, and check your mesh again at the interfaces
2. if using snappyHexMesh, use many featureSnapIters (I would go up to 25 or 30 even sometimes)
3. Try to make sure all faces on either side of the AMI have similar areas
4. Play with the AMI tolerance
5. Be careful with the adjustable time step option, if you can set a fixed time step which will cause your mesh to see the same blade angles at each revolution and you succeed in getting it around 360 degrees then you're home; with adjustable time step this will never happen
6. if it's crashed already you may try to re-start from the last save point and tweak the time stepping options to make the solver "jump" over the problematic mesh conformation (should be a last resort though in my opinion)

All the best,

A

[amintalezade]

Thank for your excellent experiences in AMI simulation, Artur.
I have the same problem simulating a periodic propeller. as the propeller rotates it passes from the stationary region and the min value in the AMI patch target decrease to near zero and the solution stops!
AMI: Patch target sum(weights) min/max/average

does your comment can be use for periodic simulation? how can I solve the min value problem?

That would be really appreciated.

[Tobi]

I used AMI and ACMI and I never had problems... (not checked periodic stuff - but here I read that GGI is the better choice)

https://www.youtube.com/watch?v=XC-_F42CZjg

https://www.youtube.com/watch?v=KCIBzVWyqzg

https://www.youtube.com/watch?v=lNavcJb6Pn8

https://www.youtube.com/watch?v=wlK1jM4twBc

In my experience ... know what you do and everything is fine.

[amintalezade]

Originally Posted by Tobi

I used AMI and ACMI and I never had problems... (not checked periodic stuff - but here I read that GGI is the better choice)

In my experience ... know what you do and everything is fine.

Dear Tobi
I checked my cyclicAMI faces and also change the featureSnapIters to 25 but it doesnt work. the simulation continues for a few time step and AMI min value decreases to zero and exit from the solution as below

Courant Number mean: 0.00113213 max: 0.683572
deltaT = 5e-06
Time = 0.00013

solidBodyMotionFunctions::rotatingMotion::transformation(): Time = 0.00013 transformation: ((0 0 0) (0.999947 (0 0.0102698 0)))
AMI: Creating addressing and weights between 2467 source faces and 2367 target faces
AMI: Patch source sum(weights) min/max/average = 0.635783, 1.00003, 0.997899
AMI: Patch target sum(weights) min/max/average = 0.785625, 1.0004, 0.999555
AMI: Creating addressing and weights between 6477 source faces and 6477 target faces
AMI: Patch source sum(weights) min/max/average = 0.999997, 1, 1
AMI: Patch target sum(weights) min/max/average = 0.999997, 1, 1
AMI: Creating addressing and weights between 6328 source faces and 6984 target faces
AMI: Patch source sum(weights) min/max/average = 0, 1.02797, 0.990961
AMI: Patch target sum(weights) min/max/average = 0.00514256, 1.00165, 0.988335
PIMPLE: iteration 1
smoothSolver:  Solving for Ux, Initial residual = 4.24196e-06, Final residual = 1.23042e-08, No Iterations 1
smoothSolver:  Solving for Uy, Initial residual = 5.83482e-06, Final residual = 1.76498e-08, No Iterations 1
smoothSolver:  Solving for Uz, Initial residual = 9.60301e-05, Final residual = 2.06976e-07, No Iterations 1
#0  Foam::error::printStack(Foam::Ostream&) at ??:?
#1  Foam::sigFpe::sigHandler(int) at ??:?
#2  ? in "/lib/x86_64-linux-gnu/libc.so.6"
#3  Foam::divide(Foam::Field<double>&, double const&, Foam::UList<double> const&) at ??:?
#4   Foam::tmp<Foam::GeometricField<double, Foam::fvPatchField,  Foam::volMesh> > Foam::operator/<Foam::fvPatchField,  Foam::volMesh>(Foam::dimensioned<double> const&,  Foam::tmp<Foam::GeometricField<double, Foam::fvPatchField,  Foam::volMesh> > const&) at ??:?
#5  ? at ??:?
#6  __libc_start_main in "/lib/x86_64-linux-gnu/libc.so.6"
#7  ? at ??:?
Floating point exception (core dumped)

the 6328 source faces and 6984 target faces are belonged to the AMI between the stationary and rotationary zone as shown in the attached figure.
How can I fix the problem?
Thanks you indeed

[hakolekar]

Hi,


Any solution to this problem.



I am experiencing a similar issues with cyclicAMI.



AMI: Creating addressing and weights between 260 source faces and 190 target faces
AMI: Patch source sum(weights) min/max/average = 0, 1, 0.946068
AMI: Patch target sum(weights) min/max/average = 0, 1, 0.754746
AMI: Creating addressing and weights between 260 source faces and 190 target faces
AMI: Patch source sum(weights) min/max/average = 0, 0, 0
AMI: Patch target sum(weights) min/max/average = 0, 0, 0
AMI: Creating addressing and weights between 260 source faces and 190 target faces
AMI: Patch source sum(weights) min/max/average = 0, 1, 0.0539319
AMI: Patch target sum(weights) min/max/average = 0, 1, 0.245254
#0 Foam::errorrintStack(Foam::Ostream&) at ??:?
#1 Foam::sigFpe::sigHandler(int) at ??:?
#2 ? in "/lib/x86_64-linux-gnu/libc.so.6"
#3 Foam::cyclicPeriodicAMIPolyPatch::resetAMI(Foam::A MIInterpolation<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 at ??:?
#4 Foam::cyclicAMIPolyPatch::AMI() const at ??:?
#5 Foam::cyclicAMIPolyPatch::applyLowWeightCorrection () const at ??:?
#6 Foam::cyclicAMIFvPatch::makeWeights(Foam::Field<do uble>&) const at ??:?
#7 Foam::surfaceInterpolation::makeWeights() const at ??:?
#8 Foam::surfaceInterpolation::weights() const at ??:?
#9 Foam::fvPatch::weights() const at ??:?
#10 Foam::coupledFvPatchField<double>::evaluate(Foam:: UPstream::commsTypes) at ??:?
#11 Foam::cyclicFvPatchField<double>::cyclicFvPatchFie ld(Foam::fvPatch const&, Foam:dimensionedField<double, Foam::volMesh> const&, Foam::dictionary const&) at ??:?
#12 Foam::fvPatchField<double>::adddictionaryConstruct orToTable<Foam::cyclicFvPatchField<double> >::New(Foam::fvPatch const&, Foam:dimensionedField<double, Foam::volMesh> const&, Foam::dictionary const&) at ??:?
#13 Foam::fvPatchField<double>::New(Foam::fvPatch const&, Foam:dimensionedField<double, Foam::volMesh> const&, Foam::dictionary const&) at ??:?
#14 Foam::GeometricField<double, Foam::fvPatchField, Foam::volMesh>::Boundary::readField(Foam:dimension edField<double, Foam::volMesh> const&, Foam::dictionary const&) at ??:?
#15 Foam::GeometricField<double, Foam::fvPatchField, Foam::volMesh>::readFields(Foam::dictionary const&) at ??:?
#16 Foam::GeometricField<double, Foam::fvPatchField, Foam::volMesh>::readFields() at ??:?
#17 Foam::GeometricField<double, Foam::fvPatchField, Foam::volMesh>::GeometricField(Foam::IOobject const&, Foam::fvMesh const&, bool) at ??:?
#18 Foam::basicThermo::lookupOrConstruct(Foam::fvMesh const&, char const*) const at ??:?
#19 Foam::basicThermo::basicThermo(Foam::fvMesh const&, Foam::word const&) at ??:?
#20 Foam::fluidThermo::fluidThermo(Foam::fvMesh const&, Foam::word const&) at ??:?
#21 FoamsiThermosiThermo(Foam::fvMesh const&, Foam::word const&) at ??:?
#22 Foam::heThermo<FoamsiThermo, FoamureMixture<Foam::sutherlandTransport<Foam::s pecies::thermo<Foam::hConstThermo<FoamerfectGas< Foam::specie> >, Foam::sensibleEnthalpy> > > >::heThermo(Foam::fvMesh const&, Foam::word const&) at ??:?
#23 Foam::fluidThermo::addfvMeshConstructorToTable<Foa m::hePsiThermo<FoamsiThermo, FoamureMixture<Foam::sutherlandTransport<Foam::s pecies::thermo<Foam::hConstThermo<FoamerfectGas< Foam::specie> >, Foam::sensibleEnthalpy> > > > >::New(Foam::fvMesh const&, Foam::word const&) at ??:?
#24 Foam::autoPtr<Foam::fluidThermo> Foam::basicThermo::New<Foam::fluidThermo>(Foam::fv Mesh const&, Foam::word const&) at ??:?
#25 Foam::fluidThermo::New(Foam::fvMesh const&, Foam::word const&) at ??:?
#26 ? at ??:?
#27 __libc_start_main in "/lib/x86_64-linux-gnu/libc.so.6"
#28 ? at ??:?
Floating point exception (core dumped)




I do observe that if the source faces is less than or equal to the target faces, the simulation runs fine. But as soon as the source faces become more than the target faces, the simulation crashes.



Any ideas?


Regards,

Harshal

[dscian]

Although my mesh was quite good I also had the same issue. I have overcome this by using constant timestep which means I turned off adjustTimeStep.

I recommend to use moveDynamicMesh solver before the main simulation in order to check that the mesh does not collapse in time.

Utkan

[fedenr]

Hi, I know this is an old post, but i've been facing this problem lately and just found a solution, so i wanted to put on record how i solved it in case someone else finds it useful.

In my case, the problem ocurred because the two AMI surfaces weren't identical (see attached). This ocurred when mesing with snappyHexMesh and using explicitFeatureSnap. Just changing to implicitFeatureSnap in snapControls was enough in my case to resolve the problem.

[Ngaru]

Hello Everyone,

I encountered this thread and I am experiencing similar problems with cyclic AMI. I have tried solutions suggested here and in other links on the website but I am still experiencing errors.

In my case, I intend to simulate a marine propeller's single blade. The boundary condition for the sides are periodic, therefore the use of cyclicAMI. This is shown in the image provided.

The propeller is a 5 blade propeller therefore, one blade is presumed to take a portion of 72 degrees.

I have provided the createPatchDict, the result from running createPatch Utility (createPatch -overwrite) and dynamic meshing checking(moveDynamicMesh -checkAMI -noFunctionObjects)

If you have ideas on this case or encountered similar problem let us think together. Thank you in advance.

Best regards
Jay

[Artur]

It seems you are splitting cells at the interfaces, I suspect this may lead to these issues - note that not only is the minimum weighting 0, but maximum is about 2, suggesting twice the face size. Have you tried without grid refinement at the interfaces?

[Tobi]

You cannot use cyclicAMI for periodic things as far as I know. You need cyclicPeriodicAMI. Its obvious that you run into trouble with cyclicAMI.

[Ngaru]

Originally Posted by Artur

It seems you are splitting cells at the interfaces, I suspect this may lead to these issues - note that not only is the minimum weighting 0, but maximum is about 2, suggesting twice the face size. Have you tried without grid refinement at the interfaces?

Thank you Artur for your response.

Intially I had prepared the base mesh from blockMesh(Box) and used snappyhexmesh refine stl region giving the shape as previously attached above.

Without grid refinement - I tried without grid refinement however the weight remained at zero.

To check on splitting cells at the interface - I decided to make a basemesh(blockMesh) that has the shape of the domain and only use snappyHexMesh for the blade and hub. This has improved the AMI weights as shown

Calculating AMI weights between owner patch: AMI1 and neighbour patch: AMI2
AMI: Creating addressing and weights between 7398 source faces and 7395 target faces
AMI: Patch source sum(weights) min/max/average = 0.5550600558, 1.045356542, 0.9999971939
AMI: Patch target sum(weights) min/max/average = 0.3245599576, 1.002642677, 0.9999967814
ExecutionTime = 9.59 s  ClockTime = 9 s

The mesh is not as good as the first one but I will try to improved and simulate to see results

[Ngaru]

Originally Posted by Tobi

You cannot use cyclicAMI for periodic things as far as I know. You need cyclicPeriodicAMI. It is obvious that you run into trouble with cyclicAMI.

Thank you Tobias for your response,

Initially, I had read that for periodic boundary conditions one can use cyclic boundary, if the conformal match is granted for interfaces(Eg mesh from starccm+) otherwise cyclicAMI, is used when conformal matching is not possible(as for the case with snappyHexMesh). In case I get this literature I will attach it later.

I have no experience with cyclicPeriodicAMI, by any chance do you have some lead on that?

Best regards,
Jay

[Artur]

Hi,


That's good to hear. I tried an approach like this in the past and found that stating with blockMesh like you're doing now is a much more robust approach for the AMI, but unfortunately comes at a price of worse shm grids. You should check out the advice from Tobi as well, I was actually not aware of this BC myself.


An alternative would be to try using engrid for mesh generation, it should be more consistent with the geometry of the domain:
Primsatic boundary layer creation fixed


Best of luck,



A

[kont1901]

Hello,
Has anyone solved the Ngaru's problem?

[Ngaru]

Originally Posted by kont1901

Hello,
Has anyone solved the Ngaru's problem?

Hello Kont1901,

I solved the problem by making a base mesh using blockMesh. The base mesh had the shape of the domain and I only used snappyHexMesh for the blade and hub. So far I have no other solution. This worked for me.

[Tobi]

We have a lowWeightCorrection keyword you can put into the boundary file for the cyclicAMI. Which is somehow similar to ACMI; means, if you have minWeight < lowWeightCorrection, FOAM handles this face as wall.