XFLR5 vs CFD

Well, I was just querying because the Full Res is not the same as converged, it is the same as the Not Full Res simulation of the same mesh that the Full Res was made from (ie 1,239.387v) and I think it is a significant difference.

I was thinking a line on the surface of the geometry that shows a line of S points from this image:
separation1

That is what I want to know (and see in 3D), I am sure it does behind the trailing edge and maybe a little before the TE, but how much :slight_smile:

Maybe not a line but just a surface color for attached (green) and detached (red).

And then show some nice little particle traces in the air around it :smile:

Dale

Darren @1318980

What do you think about that blue leading edge in my yPlus range image?

Dale

Sorry, I re-read this several times, I think my brain has shut off. To clarify, the same mesh run in full res and wall model are significantly different? which simulation/runs can I look at, maybe I looked at the wrong ones.

Oh yes, I think doable, never done before but doable. So I think by doing a dot product on the surface tangents with the near-field velocity, those that face the ‘wrong way’ we could highlight as -1 and those the correct way as 1 then visualise with a surface colour map between -1 and 1. This needs paraview, I think we should test on one with definite separation where visually we can see the recirculation. Any chance you could run one at say 15 degrees AoA? or do we need more for this foil?

Well, this ties in with the full res simulation. If the results are significantly different then the Y+ in the blue is an issue I would say, but if not then it doesn’t matter.

1 Like

AHA moment… so you are saying that BECAUSE the full res results are same as not full res on the same mesh, that the layering is GOOD.

I thought that the full res would give the best converged results, sorta like a mesh with infinite cells could do somehow, but full res was not used all the time due to excess core time to do it.

I think I understand now, a dangerous thing :smile:

I think at even maybe 12 degrees would show separation sorta between LE and TE, 15 would show close to LE.

I will make a geometry for that as I really don’t like the standard way of changing air inlet vector (but that is another topic :smile: for you to convince me it is OK to change inlet vector without undue wall influence (especially high aoa’s)).

This is fun :wink:

Dale

Haha! well as long as you use an inlet-outlet condition all around the wing its fine, I could link you an example?

Best,
Darren

But what if the air that gets to the wing has already been influenced by some air that was already bounced off a ‘wind tunnel’ wall in front of the wing? (maybe I should see your example but the ones I have seen made me question the method)

Here is my NACA0012 project, it’s my playground for trying weird things so excuse the mess. The best example is validationMK2, to get an idea of setup (ignore the failed runs :slight_smile: )

But essentially the walls above, bellow, upwind and downwind are set to inlet-outlets, where they don’t ‘know’ about what lies outside them (such as surrounds or wind tunnels) they ‘know’ that air is travelling in a direction that is going into the domain, if flow exits the domain, then it acts as if it just moves out of it, to us that is zero gradient. So there will be no deflection from any wall external to it, nor will the walls themselves make the flow behave any differently to if they were orientated with the flow.

1 Like

Maybe that wall setup should be called an open door instead… :smile:

It is so nice to able to do things here that can’t be done in the real world :smile:

I will duplicate your wall and inlet setup and run a 12aoa simulation :slight_smile:

Thanks,
Dale

Haha, yes, a true ‘controlled environment’ I would describe it as :joy:

I just noticed also you were getting errors saying that the instance ran out of memory. This is because you are saving too many timesteps. Since we are only interested in the converged results, if you set it to run to 1000s then the time write intervale can also be 1000s saving only the final results, this saves download time, and allows the most significant data to be saved. When I view your project, it says you saved every 1s, and ran for over 300s and only saved 38 steps before running out of space, so I don’t know what data is present, however, I would guess its the first 38 steps. Does that make sense?

1 Like

Yes it makes sense I thought I was still just using default values for simulation control, I thought I would figure it out later, I guess now is later :slight_smile:

I was caught by the hidden ‘Details’ dropdown on the write value until now…

I will correct.

How is the ‘Adjustable Runtime’ write control any different from ‘Timestep’?

RE: NACA0012

  1. Why are there 2 symmetry ‘walls’? Does this simulate infinite span?
  2. How do you make those symmetry ‘walls’ act like inlet/outlets for some sideflow in air inlet vector?
  3. And the big question… why cant I input my air velocity vector as magnitude and angle about each axis? It is dark ages to me to have to break my vector down into x,y,z components on a calculator, or am I missing something?

Thanks,
Dale

This to me makes more sense when thinking about a transient simulation time steps would be the number of steps between the written times, whereas the adjustable runtime is the interval between written steps in seconds, one is a number the other is a quantity of time. for steady state with a 1s interval, 1000s = 1000 timesteps so both are the same.

Yep exactly :slight_smile:

ooo, bit tricky that one. I think the best solution would be to make a periodic boundary condition between the two for my case, for your case (a non 2D shape) we couldn’t do that, full geometry would be needed removing the symmetric assumption.

The only ease there would be that we don’t have to calculate, we would then require 4 inputs, not 3. But I suppose it makes sense to offer this as an option.

Best,
Darren

So is this why my runs were hanging yesterday, writing results every second?

I must have unknowingly changed it thinking it would do as I expected, not hang the run :slight_smile:

Possibly yes, if there was a lot of results to reconstruct at the end. Didn’t know that then though :smiley:

1 Like

I was thinking just like this (rather do those 4 by the mega keypress’s and brain power to get it right, with my calculator :slight_smile:)

magnitude ____ (+ is away from origin)
x angle ____ (ccw from x+)
y angle ____ (ccw from y+)
z angle ____ (ccw from z+)

Default all to 0, then for 12 degrees aoa I put in two numbers and no chance me getting +/- vector component errors and mis-inputting and calculating the vector components… :wink:

This input method could be one click away (Input Selection Box: Cartesian or Angle) :smile:

Dale

Wow this is SO relevant… I have been hanging runs all day on my whole plane project :smile: :grinning::grinning::grinning:

Thanks, big like on this one…

1 Like

Thinking about it, not sure this would work, fine for planar cartesian aligned inlet, but what if curved or not aligned? to be robust it would need telling the base direction and then angles 6 inputs! but yes if a default of say direction 1,0,0 and angle 0,0,0 was assumed this might be a quick setup option.

Best,
Darren

I’ll let you worry about the curved input, how do you do that into just x,y,z inputs anyway?

I think that the above would handle the vast majority of angles needed for the aerodynamics discipline :wink:

Not aligned cases means you should get your values from a CAD program anyway and I would EXPECT to have to do that in that case, but not the basic case.

Not sure why this is a requirement, doesn’t the (ccw from ?+) take care of it more generally?

I can get the right quadrant and direction in my head just thinking about my 4 inputs.

For my case 12aoa would be magnitude +2376 and x angle +12

:grinning::grinning::grinning::grinning: I just made a little spreadsheet that looks like my suggestion and that took my calculator and a lot of the brain power away from my problem… :heart_eyes:

Hi Dale & Darren and sorry to crash into your exciting discussion.

Dale mentioned that he expects boundary layer separation which means that no wall functions should be used because the log-based wall functions do not correctly predict the profile. Directly resolving the viscous sublayer is strongly recommended in this case - not sure if Darren mentioned it though.

Best,

Jousef