[Alhasan]

Hi All,

I am trying to map fields between two different domains, one being the Windtunnel with blade init and the other being only a small section of the blade with symmetry on two sides.

since the domains are different I am using Cutting Patches for mapping the Fields like mentioned above mapped patches inlet outlet and topandbottom

I am aware that my problem is to do with boundary conditions for a fact - as the mesh is of reasonable quality with 8 million for the wind tunnel and 6 million for the smaller blade domain. and KW-SST model for both

I dunno how to attach image - but the mapped domain a typical airfoil2D domain from tutorials but a smaller version it

when i use the boundary conditions
U
inlet - Fixed Value
outlet - zero gradient
top and bottom - fixed value
front and back - symmetry

P
inlet - zerogradient
outlet - Fixed value
top and bottom - zerogradient
front and back - symmetry

When i do this the Cp around the airfoil is Off by 0.2 for all around the blade i.e the cp distribution graph has just moved 0.2cp above the experimental data - even though the Cp distribution is good

then also the flow behind the airfoil is much different from how it was supposed to be much faster

- My question to all this is what boundary conditions can we use to map the data as it is in the Bigger domain - (the wind tunnel setup)

- the Cp and the Velocity behind the airfoil is very good in wind tunnel setup and i want the same for the smaller mapped domain - as i will be using the smaller mapped domain results as the initial condition for a further LES calculations So it is important i get the right results in the smaller domain with the airfoil


- I thought the problem might be because the pressure at the inlet was necessary so i put fixed value for pressure in the inlet - but then the flow starts to flow inward from the top and bottom patch due to the high pressure - then i put top and bottom as well fixed value and the that pressure interfere with the airfoil - so fixed value is not the right choice - i just need the same flow conditions that is there in the wind tunnel around the airfoil here sounds simple - but i am not able to find it

-Talking about the turbulence fields, I am not able to replicate the results from the wind tunnel tunnel RANS simulation(result matches the experiments) in to the smaller domain with only airfoil without mapping the Nut, I initially mapped only P and U and had all the inlet outlet and topandbottom patch as Fixed value but the Nut did not appear any where close to the nut around the airfoil in the wind tunnel setup and I check Nut only because the velocity behind the airfoil in the wake region was not matching with the wind tunnel RANS simulation.however the Cp Matches.
People suggested me that my outlet was too close to the airfoil, but my point is I am mapping the data and shouldn't be a issue right ?
and the author of the paper i am trying to replicate has a similar domain but performed it in FLUENT

Thanks a lot for your reply, - if u hint how to add images ill add em straight away

Kind Regards,
Hasan K.J

[Alhasan]

Hey Bruno,

Thanks for the advice, I will have a look at the utility,

Talking about the turbulence fields, I am not able to replicate the results from the wind tunnel tunnel RANS simulation(result matches the experiments) in to the smaller domain with only airfoil without mapping the Nut, I initially mapped only P and U and had all the inlet outlet and topandbottom patch as Fixed value but the Nut did not appear any where close to the nut around the airfoil in the wind tunnel setup and I check Nut only because the velocity behind the airfoil in the wake region was not matching with the wind tunnel RANS simulation.however the Cp Matches.
People suggested me that my outlet was too close to the airfoil, but my point is I am mapping the data and shouldn't be a issue right ?
and the author of the paper i am trying to replicate has a similar domain but performed it in FLUENT

Regards,
Hasan K.J

[wyldckat]

Hi Hasan,

Thank you for starting a new thread for this topic. For other readers, the initial discussion started on this thread: http://www.cfd-online.com/Forums/ope...g-utility.html

You can find an explanation on how to attach files in the FAQ of the forum (yellow menu above, 3 entry from the left). More specifically, the instructions are here: http://www.cfd-online.com/Forums/faq...l&titlesonly=0


OK, I'm trying to figure out a way to give you a way to visualize in your mind the problem at hand...
The simplest idea I can come up with is the force-moment relation. If you have a pen and try to bend it by only holding the extremities, it's rather difficult to bend and/or break the pen; but if you hold it near the centre and use the rest of the pen to hold with your hands, it's rather easy to break the pen, since you're able to apply more force and moment to the whole pen.

Another example would be if you were trying to run inside a 2x2 meter room on top of a treadmill vs running outside.

The same might be happening in this case, namely the smaller domain is too small and leads to the air flow to be too constricted, which leads to it to sort-of bend itself in order to flow around the blade, which leads to the Cd being offset by a bit.


My guess is that either the symmetry planes should not be used (perhaps slip wall would be best?) or that the inlet should be one of those fancy pressure-based ones... if you look at the Inlet ones pointed from here: http://foam.sourceforge.net/docs/cpp/a00001.html

• Currently it's this page: http://foam.sourceforge.net/docs/cpp/a09487.html - but it will change with future releases.

Problem is that I'm not familiar with any of those fancy boundary conditions

Best regards,
Bruno

[Alhasan]

Hey Bruno,
I totally agree with the boundary condition being too close poses an issue
-but I had to do it there was no other option

1) the airfoil is 0.56 chord lengths far from the wind tunnel exit so the C grid could go only so far in front for mapping

2) The paper I am trying to replicate is by an author who has 7 papers on a domain with a same size - i have used his domain size and he has successfully performed the simulation but dunno how he did it he used FLUENT to do it though the link for the paper
http://arc.aiaa.org/doi/abs/10.2514/6.2009-3197

the experimental setup http://www.mb.uni-siegen.de/iftsm/fo..._etal_fn07.pdf

so without mapping and without using a smaller domain, the number of cells necessary to perform this LES simulation in 3D with the wind tunnel in unimaginable.

- please have a glance at Fig.7 in the experimental Setup and throw ideas of how this simulation could be done - other than the method i am currently trying of mapping

- Images below -
(Left)- Full Windtunnel Simulation (matches the experimental results for Cp and Wake Flow)
(Middle)-Mapped right after mapping - before the simulation
(right) - after the simulation (have a look at wake flow behind the airfoil doesn't match the experimental, however Cp is accurate)

Thanks
Hasan K.J

[wyldckat]

Hi Hasan,

Yeah, from the images, it's what I was imagining. The even simpler idea is that even though you are using symmetry boundary conditions on top and bottom, they essentially act as flow walls. This forces the fluid to respect those "walls" and therefore enforces the wake to go more upwards than it should (if I'm seeing it correctly).

Given the descending ramp after the blade, even the slip boundary condition will not be the correct solution. You have to keep in mind that the fluid still acts as sort-of incompressible, therefore either it has to speed up or increase the pressure, which will lead to the distortion of the flow.

The simplest idea that comes to mind is this:

1. The patches directly above and below the blade, can be of type "slip". You can find several tutorials that use this boundary condition, by running:
   

   find $FOAM_TUTORIALS -name U | xargs grep slip

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.

Best regards,
Bruno

[Alhasan]

Hey Bruno,

Thanks,

you have slightly misunderstood the problem, or i have to blame myself, I am so bad in explaining stuff

- I have tried all boundary conditions that i know of i will explain

- Symmetry is used for the "front and back" of the geometry not the top and bottom.

- I have tried Slip for "top and bottom" and the Cp also doesn't match so its useless

- I tried Zerogradient - Useless

- I tried FixedValue - Treat the "top and bottom" it as a inlet and that solved the problem.of the Cp

- I have also tried "inletOutlet" for U and "outlet Inlet" for P for the "Top and bottom" patch works fine - but Cp is slightly off

- I have wasted more than 240 hours of Computing time 128 processors on these boundary conditions - i feel ashamed they dedicated me a 10 day slot

- For the outlet i have tried Zerogradient, InletOutet, OutletInlet, FixedValue
Nothing Seems to do any changes to the Wake Flow !!!! which is what surprised me

- after some discussion in LikedIN came to conclusion that Nut might the Culprit as the turbulence fields from the wind tunnel has to be mapped, But even that has failed me as of now

- So, looking at other options such as Merging mesh and GGI is the only option i think

- Im open for any suggestions

Regards,
Hasan K.J

[wyldckat]

OK, that does make it a bit clearer.
But... for example, is the top patch both the horizontal and the inclined patches on the top? Or are they "top1" and "top2"?

[Alhasan]

Hey Bruno,
It is both the Horizontal and Inclined Bit together

- so finally the working BC for Top and Bottom to give me a good Cp is the FixedValue BC

- Tried everything I know - no luck with the Wake, if you look at the images,
you can see that the wake is not turning enough and the answer could be after mapping the Nut toward the outlet will be a lot.

Thanks,
hasan K.J

[Alhasan]

Hey Bruno,

Theoretically speaking i shouldn't have any issues right ? because my solution from the wind tunnel is converged and i an using the same flow filed all around the airfoil ?
- that is the reason i kept saying boundary condition issue in all the forums i could !!!
-coz i can't point out another issue !!! since the author has actually used the same geometries

- or am i just trying to do something that is not even possible.. ???

Regards,
Hasan K.J

[wyldckat]

From what I can see and understand, the coarser mesh before mapping, gave better looking values simply because of mere luck.
The cells are too rectangular shaped, which lead to a distortion of the flow. Examples: OpenFOAM: Interesting cases of bad meshes and bad initial conditions


The top part should not be a single patch, same goes for the bottom one. The horizontal parts can easily be slip, but the inclined ones should use "outletInlet" (or "inletOutlet", I haven't checked).

Using fixed value on either one has one advantage: it enforces the flow to keep on going along the main flow orientation. Problem is that it does not account for the effect of some occasional vortexes that the blade could introduce into the flow. In other words, does not account for small expansions and contractions of the flow.

[Alhasan]

Hey Bruno,

I have already tried InletOutlet BC for the "topandbottom" patch, do you think making the inclined ones separately, will make a a difference..?

and slip for the horizontal are affecting for the upper surface, and Cp on the upper surface.

Thanks,
Hasan K.J

[Alhasan]

Hey Bruno,

I used mergeMeshes to merge two meshes and what i have ended up is with the patches i had in both the meshes in the boundary file


inlet -for small domain
type cyclicAMI;
nFaces 60;
startFace 10560;
matchTolerance 0.0001;
neighbourPatch outsideSlider;// what do i put here..?

When i use AMI what do i say for the neighbourPatch ?
what BC should i give for say U and P for these Patches ? they cannot be fixedValue can they be..? so what should i assign then ?

Inlet i have fixedValue usually ?- since i made it cyclicAMI here what do i put inside the boundary file


Regards,
Hasan K.J

[Moderator note: Moved this post from this thread: http://www.cfd-online.com/Forums/openfoam-solving/95697-problem-using-ami-10.html ]

[Alhasan]

Hey Bruno,

From my research into this, it is best that i do an mesh merge and and AMI case and I have only enough time to run one more case due to time constraints !!

I have merged the meshes and I have asked a question here http://www.cfd-online.com/Forums/ope...tml#post467808

Since you say the mesh is too coarse i will increase the density - the mesh that appears to be coarse has 7 million cells i could 11 max and more than that its gonna take too much time probably make a bigger refinement box and that should do - during snappy

- what did u mean try not to over lap the meshes ? here: http://www.cfd-online.com/Forums/ope...tml#post467799
- do mean to say the big mesh has to have an empty space in the middle for me to put another mesh and only then it can be merged ?


- Can you please share if you have any case with AMI ! !? I read all night still it hasn't gone through my head of the neighbouring patch and the boundary contains that has to be used,

- AMI is the Last Stand

Thanks for your time,
Regards,
Hasan K.J

[wyldckat]

Hi Hasan,

Having the top patch divided into the two parts of "top" and "top_inclined", and similarly done for the bottom, should help you with having better adjusted boundary conditions for your case.

Given the complexity of the geometry, I think that if you use that coarse mesh you have and separate the patches as mentioned, then try out the boundary conditions mentioned, namely:

• "slip" for "top" and "bottom".
• "outletInlet" and "inletOutlet" for "top_inclined" and "bottom_inclined".

You should get a good notion of whether this will work for the refined case.

Originally Posted by Alhasan

I have merged the meshes and I have asked a question here http://www.cfd-online.com/Forums/ope...tml#post467808

I've moved that post to this thread and is now above your previous post

Originally Posted by Alhasan

Since you say the mesh is too coarse i will increase the density - the mesh that appears to be coarse has 7 million cells i could 11 max and more than that its gonna take too much time probably make a bigger refinement box and that should do - during snappy

I think that additional refinement will solve nothing. Or at least, not for what you are trying to do.

Originally Posted by Alhasan

- what did u mean try not to over lap the meshes ? here: http://www.cfd-online.com/Forums/ope...tml#post467799

Imagine that you need to build a door made out of wood and you already have a place in the wall where to place the door, and that most of the mechanical parts are already in place on the hole on the wall.
If the door is to fit properly in that hole, it cannot be too big, nor too small and its mechanical parts must be properly aligned with the ones on the hole.
If by any chance one of those mechanical parts have a slight non-alignment, the door will not close because it will hit the wall <- this is overlapping

Originally Posted by Alhasan

- do mean to say the big mesh has to have an empty space in the middle for me to put another mesh and only then it can be merged ?

Yes. And it should fit perfectly or at a maximum have a very small space between the two meshes, but they should not overlap. This can be controlled by the tolerance setting in the cyclic AMI "boundary" file settings.

Originally Posted by Alhasan

- Can you please share if you have any case with AMI ! !? I read all night still it hasn't gone through my head of the neighbouring patch and the boundary contains that has to be used,

Let me remember where there is a post with something like that... found one: http://www.cfd-online.com/Forums/ope...tml#post398703 - post #12.

But the actual instructions on how to set this up is shown here: http://www.cfd-online.com/Forums/ope...tml#post446517 post #184 - which in answer to your previous question, the "neighbourPatch" is the patch name on the other mesh part.

Best regards,
Bruno

[Alhasan]

Hey Bruno,

- for some reason i thought mesh merging was more like snappy hex i though it was going to get rid of all the overlaping mesh of the external mesh within the internal mesh and retain only the mesh that it is merging (internal ones)

I read through the forums and kinda figured out how the Mesh merging works, so currently I am making a External mesh with a hole in the middle so i can place my refined mesh in it, I am using snappy hex to do it, lets hope it works.

- so current plan is make the hole a single patch and for the internal mesh - make all of the patches that is going to be in contact with the external mesh as a single patch. and then they gonna be neighbours !!! and toposetsDict will be created automatically i guess, lets hope i have got it right.

-Does GGI work the same way ? do i need a hole in the mesh to put another mesh or that doesn't matter ? the other mesh can interpolate the data from within the external mesh ?

Thanks Bruno,
Kind Regards,
Hasan K.J

[wyldckat]

Originally Posted by Alhasan

- so current plan is make the hole a single patch and for the internal mesh - make all of the patches that is going to be in contact with the external mesh as a single patch. and then they gonna be neighbours !!! and toposetsDict will be created automatically i guess, lets hope i have got it right.

"topoSetDict" files are not created automatically .
Having a single patch on each side should work, but I would suggest that you try to keep a 1:1 approach for each major patch you already have on the internal mesh, so that you can better diagnose "what is flowing through where".

Originally Posted by Alhasan

-Does GGI work the same way ? do i need a hole in the mesh to put another mesh or that doesn't matter ? the other mesh can interpolate the data from within the external mesh ?

GGI and AMI are sort-of like cousins: have been born from the same need, but have different implementations. Conceptually similar, because of the problem they aim to solve, but due to how they were implemented, configuring each one is a bit different and each one has its own limitations.
So... to answer your question: in theory, it should work with GGI as well, in a very similar way. But in practice, I don't even know how to use GGI

[Alhasan]

I kind of get it now

But is there any method of Mapping the fields between two geometries as the simulation is running,
like in AMI and GGI, I am thinking we need a patch on both meshes where the flow is going to be transferred but i was wondering if there was some function that interpolates from within one mesh to the patch of the other mesh as the simulation was running. rather than having a patch on same location on both meshes !!

Thanks,
Hasan K.J

[wyldckat]

AFAIK, most of the patch mapping BCs available in OpenFOAM need a 1:1 face association. The only able to perform face-area weighted mapping is AMI (and GGI).

But feel free to browse through the official list of BCs here: http://foam.sourceforge.net/docs/cpp/a00001.html

[Alhasan]

Hey Bruno,

The above link is very very helpful i have been using open foam 2years now, i never came across it

By anychance do you know any blog or any forum that describes - how to make a good snappy hex mesh on complicated geometries ? it would be very help full

- what ever i do in snappy hex i always loose some small bits and bobs of my geometry, and i dunno how to avoid it !!!!!

Thanks,
Hasan K.J

[wyldckat]

Originally Posted by Alhasan

By anychance do you know any blog or any forum that describes - how to make a good snappy hex mesh on complicated geometries ? it would be very help full

- what ever i do in snappy hex i always loose some small bits and bobs of my geometry, and i dunno how to avoid it !!!!!

Have you seen this wiki page: http://openfoamwiki.net/index.php/SnappyHexMesh