[Alhasan]

I have seen it long ago when i started using snappyHexMesh

The geometry I am struggling with is is just a simple blade but it has a small step on top

if i have attached the STL for a better idea about the geometry.

just a small box around it

- I am loosing bits and bobs of the step on the blade and the corners of the blade
- and the step kinda disappears on the lower side of the blade :/

dunno what could cause that

Thanks,
Hasan K.J

[Alhasan]

Hey Bruno,

So from the picture above, when i do mesh merging, i will have issues with the overlapping mesh right ? since i have lost a small bit of geometry and since the internal meshing is going to have that piece of geometry they will overlap and I am going to have issues, From what you had mention before

- this is the AMI patch of the external mesh btw

Thanks,
Hasan K.J

[wyldckat]

Hi Hasan,

Yes, that's going to be a problem.

The tutorials I was implying from openfoamwiki.net were these:

• A Comprehensive Tour of snappyHexMesh - 7th OpenFOAM Workshop (25 June 2012):
  • Original source: EugenedeVilliers-TrainingSlides.tgz
  • Local copy here at openfoamwiki.net: Final-AndrewJacksonSlidesOFW7.pdf

• Advanced Preprocessing and Meshing with snappyHexMesh
  • Original source: [2]

There are 4 suspects:

1. Maximum number of cells, both global and local.
2. The quality parameters.
3. The base mesh cell alignment with your blade.
4. The refinement could be insufficient.

Best regards,
Bruno

[Alhasan]

Hey Bruno

the above tutorials were beautiful would have given me a better idea if they had attached a SnapyHexDict file..

I have an another question. I was trying to stitch two mesh and when i did that it got stuck here and nothing is happening after that no error no nothing, what could be happening, i left it on the HPC for 8 hrs nothing happened.

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

Create mesh for time = 0

Coupling partially overlapping patches Internal_Ext and Internal
Resulting internal faces will be in faceZone Internal_ExtInternalCutFaceZone
Any uncovered faces will remain in their patch
Adding pointZone Internal_ExtInternalCutPointZone at index 0
Adding faceZone Internal_ExtInternalMasterZone at index 1
Adding faceZone Internal_ExtInternalSlaveZone at index 2
Adding faceZone Internal_ExtInternalCutFaceZone at index 3
Sliding interface parameters:
pointMergeTol            : 0.3
edgeMergeTol             : 0.05
nFacesPerSlaveEdge       : 5
edgeFaceEscapeLimit      : 10
integralAdjTol           : 0.15
edgeMasterCatchFraction  : 0.4
edgeCoPlanarTol          : 0.8
edgeEndCutoffTol         : 0.0001
Reading all current volfields

Thanks,
Hasan K.J

[wyldckat]

Hi Hasan,

Originally Posted by Alhasan

I have a another question. I was trying to stitch two mesh and when i did that it got stuck here and nothing is happening after that no error no nothing, what could be happening, i left it on the HPC for 8 hrs nothing happened.

I have no idea. But a few questions to help diagnose:

1. How many cells does checkMesh report, before you run stitchMesh?
2. Have you tried running stitchMesh, without the folder "0"?
3. Did you run stitchMesh in serial more or parallel mode?
   1. If in serial mode, are you certain that the node where it ran had enough memory?

By the way, please post code and output text from the screen/log, by using with the [CODE] markers, as explained in the respective link on my signature.

Best regards,
Bruno

[Alhasan]

Hey bruno,

- The mesh has 15mil+ cells
- I am running it without a 0 folder.
- I was running it on serial.
- It has quite a bit of RAM had never had issue regarding that before so never even bothered to check how big was the ram per node on the HPC.

- What should i do to run it in parallel the command i currently use to stitch it is
stitchMesh -partial -toleranceDict toleranceDict -overwrite Internal_Ext Internal

Thanks,
Hasan K.J

[Alhasan]

Hey Bruno,
Regarding the SnappyHex

There are 4 suspects:
Maximum number of cells, both global and local.
The quality parameters.
The base mesh cell alignment with your blade.
The refinement could be insufficient.

The culprit was the base mesh cell alignment with the blade. it was kinda coarse for the blade.

Thanks,
Hasan K.J

[wyldckat]

Hi Hasan,

I suggest that you test one of those stitching example cases from the other thread on that topic and check what are the steps it takes to stitch the mesh.
Because that way you will know what is the next step that stitchMesh should have done for your case.

stitchMesh can only be executed in serial mode. And 15 million cells is a lot for a single core to handle. You can try doing a simple test with 100 kcell, 500 kcell, 1 Mcell and see how much longer it takes with the increased number of cells. I'm guessing here, but expect the time it takes to be exponentially or geometrically proportional to the number of cells.

I don't know what is the topology of the HPC machine/cluster you are using, so it might be sharing the remaining cores with other runs or the memory might be being shared among all machines, which would lead to pretty slow timings if 15 GB is shared among a 2 to 10 machines in a NUMA system.

It's even possible that the process is freezing and is locked out by the HPC job scheduler, if the process takes too long, and gives priority to other runs.

Essentially, there are too many unknowns, but the list above should help you isolate the problem.


By the way: why are you stitching the mesh? Is it because you don't want to rely on AMI?

Best regards,
Bruno

[Alhasan]

- Oki i will start with my trial and error procedures

- I wanted to give it a Try stitching to see if it works, then AMI shouldn't be necessary

- might aswell try it now and learn it for later use.

- AMI is still my next option, just waiting for the results from the new BC that you suggested for my mapped case.

- If the BC works, all of the above would be unnecessary for me

Thanks,
Hasan K.J

[Alhasan]

Hey Bruno,

you are good in coding and you seem to have answer for anything and everything !!
this would be my last question for this year so can please give it a try

The question is here.
http://www.cfd-online.com/Forums/ope...tml#post468240

Thanks,
Hasan K.J

[Alhasan]

Hey Bruno,

The results are here.

The boundary conditions worked out well but not up to the mark. I am not getting the result that i want.

I tired top slant - outlet inlet
and bottom slant inlet outlet
that you prescribed results were not good, the flow was ever so slightly trying to turn upwards (here i want it to turn downwards)

- so figured ill reverse it so i used
top slant - inlet outlet
bottom slant - outlet inlet
and outlet - outlet inlet

I have image attached, the flow is not turning enough it kinda tries to exit asap with a higher velocity that it should be
do you have any BC in mind for the outlet, i have tried inlet outlet, outlet inlet and Zerogradient it dint work what do you think about fixedgradient is even a bc for outlet and is calculate BC feasible for outlet ?

- what could be causing that streak of nut behind the airfoil.

- from the graphs you can see that the flow is not turning enough

I have also attached images of the Nut which actually plays a major role in this case.
- so the problem still persists however it has improved from before you prescription of the BC for the top and bottom was the right one can you think one for the outlet aswell


- I also used a denser Windtunnel mesh with 11 million cells for mapping this time and made sure the solution was converged

Images below:
from left - Nut Mapped, U Mapped, Nut after simulation, U after simulation.
graph - left - from the win tunnel simulation, right from this simulation


Kind Regards,
Hasan

[Alhasan]

Hey Bruno,

Any suggestions on the above Question

Regards,
Hasan K.J

[wyldckat]

Hi Hasan,

Originally Posted by Alhasan

Any suggestions on the above Question

That depends... any updates regarding the information above?
I say this because it was on my to-do list of threads that I want to answer to, which is on my list at http://wyldckat.github.io ... but I guess you haven't looked at it

Originally Posted by Alhasan

The boundary conditions worked out well but not up to the mark. I am not getting the result that i want.

I tired top slant - outlet inlet
and bottom slant inlet outlet
that you prescribed results were not good, the flow was ever so slightly trying to turn upwards (here i want it to turn downwards)

Well, I did explicitly write that I didn't remember which one is the right one to use, because I always get confused between the two of them

Originally Posted by Alhasan

- so figured ill reverse it so i used
top slant - inlet outlet
bottom slant - outlet inlet
and outlet - outlet inlet

I have image attached, the flow is not turning enough it kinda tries to exit asap with a higher velocity that it should be
do you have any BC in mind for the outlet, i have tried inlet outlet, outlet inlet and Zerogradient it dint work what do you think about fixedgradient is even a bc for outlet and is calculate BC feasible for outlet ?

And I'll have to go read the User Guide or check the tutorials again, to figure out which one is which...
OK, "inletOutlet" stands for, and I quote from here: https://github.com/OpenFOAM/OpenFOAM...tchField.H#L31

This boundary condition provides a generic outflow condition, with specified inflow for the case of return flow.

[...]

Example of the boundary condition specification:

    myPatch
    {
        type            inletOutlet;
        phi             phi;
        inletValue      uniform 0;
        value           uniform 0;
    }

How did I find this? Remember post #3? The current link for "inletOutlet" is actually this one: http://foam.sourceforge.net/docs/cpp...2.html#details - but it will change with the next release of OpenFOAM Which is why I've provided above a link to the 2.2.x code repository, which won't change.

Anyway, the correct settings, at least in theory, should be:

• Top slant: inletOutlet
• Outlet: inletOutlet
• Bottom slant: outletInlet

Which, from the looks of it, is not what you've used.

Originally Posted by Alhasan

- what could be causing that streak of nut behind the airfoil.

Bad boundary conditions... as ascertained from the previous statement.

Originally Posted by Alhasan

- from the graphs you can see that the flow is not turning enough

The third figure "Screen Shot 2014-01-03 at 04.16.21.jpg (3 of 5)" pretty much tells the whole story... the flow at the outlet clearly cannot get out

Originally Posted by Alhasan

I have also attached images of the Nut which actually plays a major role in this case.
- so the problem still persists however it has improved from before you prescription of the BC for the top and bottom was the right one can you think one for the outlet aswell

Not my fault ... I clearly wrote in post #5 (added bold now for clarity):

Originally Posted by wyldckat

2. The ramp-like part afterwards, should be of type... I always get the two confused, but it's either "outletInlet" or "inletOutlet". In other words, you want a boundary condition that allows for a faster exchange of fluid, without the need to either speed up the flow or to forcefully compress/expand the flow.You'll have to search for more information on this, because I don't know what exact OpenFOAM boundary conditions you should be using.

Originally Posted by Alhasan

- I also used a denser Windtunnel mesh with 11 million cells for mapping this time and made sure the solution was converged

Uhm... if the boundary conditions are incorrectly defined, a denser mesh is not going to solve the problem

Best regards,
Bruno