[openfoam_user]

Hi,

I have improved the convergence using:
grad(p) cellLimited leastSquares 1;// (new)
instead of
grad(p) Gauss linear corrected;// (old)

Any other advice ?

Stephane

[openfoam_user]

Hi OF-users,

which maxCo are you reaching for pimpleDyMFoam computation with AMI patches ?

What manner do you use to increase maxCo ? Manually or a more sophisticated method ?

Regards,
Stephane.

[Randomizer]

What about your mesh non-orthogonality? In your fvSolution file you set nNonOrthogonalCorrectors to zero. Is your mesh orthogonal?

[Attesz]

Originally Posted by openfoam_user

Hi OF-users,

which maxCo are you reaching for pimpleDyMFoam computation with AMI patches ?

What manner do you use to increase maxCo ? Manually or a more sophisticated method ?

Regards,
Stephane.

Hi,

I could use Co numbers up to 1. At the beginning of the simulation the max Co increases a lot, so the solver decreases the timestep. Later, the timestep as well as the meanCo increases. At the beginning, using 0.5 is a good start. Later switching to 1 or maybe higher is also possible. meanCo is more important than maxCo. And yes, I increase it manually...

[Attesz]

Originally Posted by openfoam_user

Hi,

I have improved the convergence using:
grad(p) cellLimited leastSquares 1;// (new)
instead of
grad(p) Gauss linear corrected;// (old)

Any other advice ?

Stephane

did you try cellLimited Gauss Linear 1?

cellLimitation helped you to have better convergence. leastSquares is slower than linear in my opinion.

[openfoam_user]

Hi,
checkMesh gives me:

*Number of severely non-orthogonal faces: 182.
Non-orthogonality check OK.
<<Writing 182 non-orthogonal faces to set nonOrthoFaces

So you suggest to set nNonOrthogonalCorrectors 1;

I will try the schemes you suggest me to have a better convergence. Thanks.

Some words about maxCo.
Now I have a simulation that seems to run well. In my controlDict file I have set maxCo = 2 (like the propeller tutorial case). And the log file gives me: Courant Number mean: 0.00127652 max: 1.99524. So you say to increase manually the maxCo in order to have obtain a Courant Number mean = 1 ! Is it right ?

Regards,
Stephane.

[Attesz]

modify nNonOrthogonalCorrectors to 1 or 2 only if you have problems with the pressure residuals. this correction may help, but not too much as I experienced. It increases the calculation time as well.

maxCo can be adjusted during run, too. Set it initially to 1, but your meanCo is 0.001 which is quite low.

are you using adjustable time stepping?

Originally Posted by openfoam_user

Hi,
checkMesh gives me:

*Number of severely non-orthogonal faces: 182.
Non-orthogonality check OK.
<<Writing 182 non-orthogonal faces to set nonOrthoFaces

So you suggest to set nNonOrthogonalCorrectors 1;

I will try the schemes you suggest me to have a better convergence. Thanks.

Some words about maxCo.
Now I have a simulation that seems to run well. In my controlDict file I have set maxCo = 2 (like the propeller tutorial case). And the log file gives me: Courant Number mean: 0.00127652 max: 1.99524. So you say to increase manually the maxCo in order to have obtain a Courant Number mean = 1 ! Is it right ?

Regards,
Stephane.

[openfoam_user]

Hi,
yes I use adjustable time stepping.

As you can see my maxCo = 2 and my resulting meanCo is around 0.0012.
I can only play my the maxCo number.

So you suggest to increase maxCo till I get meanCo = 1 ! I hope my computation won't blow up.

Regards,
Stephane.

[Randomizer]

I guess you could set nNonOrthogonalCorrectors 2; if it won't make the calculations to long

[Attesz]

No, absolutely not. I said decrease maxCo to 1. if you have conv. errors, attach the conv. curve here.

Originally Posted by openfoam_user

Hi,
yes I use adjustable time stepping.

As you can see my maxCo = 2 and my resulting meanCo is around 0.0012.
I can only play my the maxCo number.

So you suggest to increase maxCo till I get meanCo = 1 ! I hope my computation won't blow up.

Regards,
Stephane.

[JulytoNovember]

My AMI works with blockMesh, I saw someone stated there was a problem in a previous post. My AMI is made of internal faces, then using topoSet , I created my patch for my AMI. I think the problem is the topoSet, previously I created a patch for my AMI. After the topoSets ran my AMI was incorrect, when initially it was correct.

[arnau1985]

Hello everyone,

I am experiencing some troubles when running cases with pimpleDyMFoam and AMI meshed with Salome. These cases worked properly with GGI, so I assume the mesh is OK.

Does anybody have any case or tutorial I can use as a reference to fix my problems, please? The OpenFOAM tutorials, meshed with snappyHexMesh, blockMesh and so on, are not being very helpful. I would really appreciate it.

Thanks a lot,

Arnau.

[ADGlassby]

I'm looking at possibly using AMI for a model I am putting together but I want to be sure this is the right approach.
Looking at the propellor example in the OPENFOAM tutorials the cylindrical AMI1 and AMI2 regions are situated with their axes oriented with the flow direction. What about if i wanted to model a centrifugal device where the exit is in the radial direction? or the flow field is actually across the axis (like a quarter turn ball valve) would AMI be an appropriate technique to use?

Trust this has a straight forward response :-)

Kindest Regards

Andrew

[Randomizer]

Hi,Andrew, i don't see any problem with using AMI with your case. AMI is just an interface between 2 patches with differnt mesh topology, and it shouldn't care whether the flow is axial or not. Mesh movement is provided by dinamic mesh library, and it works with non-axial flows.

[ADGlassby]

Hi Alexander, thanks for your response, just what I was looking for. I just didn't want to go through the effort of setting up a new model only to find that it was the wrong technique to use! I'll look more closely at this now.

Regards

Andrew

[Randomizer]

Hi,Arnau, what exactly is not working? Does the calculation crash after some iterations? Or it doesn't start?

[ADGlassby]

Alexander,

I wonder if you could help me? I am trying to implement the AMI methodology using a snappyHexMesh generated mesh but I am experiencing problems introducing the AMI interfaces. My mesh becomes cut at the position of the AMI interface. How can I introduce the AMI interfaces in the snappyHexMesh procedure?

I tried introducing the cylinders into the STL of the whole geometry. should I produced a separate geometry STL file for the AMI interface cylinders? if so WHEN and HOW should this be done?

My geometry is not TOO complex but I have curves which look quite involved in producing with simple blockMesh that's why I'm using snappyHesxMesh since I can use CAD to pro due my STL geometry file.

I'm really looking for some general advice/pointers since I THINK I'm almost there and just need the last little pointer (hopefully!!)

Best Regards

Andrew

[Randomizer]

Andrew, did Iunderstand correctly that you make your whole mesh with snappyHexMesh and then try to cut it with surfaces? This way it won't work, I think. I would recomend you to create two parts of your mesh (divided by ami surfaces) separately. Each part should have one of the ami surfaces. Then you can union the with mergeMeshes utility, for example. I do this way for my ami cases, but I use Salome. Hope it helps.
Alexander.

[ADGlassby]

Hi Alexander, What I'm trying to achieve is something similar to the mixerVessel2DAMI example. My problem is that I have used snappyHexMesh to develop the mesh and I'm not understanding how to introduce the AMI interface ring like in the mixer geometry. I'm going to have a look at building the mesh using blockMesh (since it's not THAT complex really) and then when I get it working this way I'll have a look at SnappyHexMesh again since I can see the advantages of being able to work up my geometry in a CAD package.

I've attached a jpeg of part of my geometry, the moving bit.

It would be great if you had any pointers based on the mixerVessel2DAMI example as I could then apply any pointers from there.

Thanks again for your kind help!

Best Regards

Andrew

[Randomizer]

Andrew, the simplest way is to divide our geometry in two parts, separated by this ami "ring". And then connect them together in one case. Just choose some ring inside your geometry so the moving part would rotate around it (like in mixerVessel2DAMI case). In your case this ring should be inside the circle on your picture. So each mesh part would have a patch, which will represent the ami interface.