As you probably know I have an active Topic about 2 issues I am having with Feature and Surface Refinements.
The cause of the yPlus discontinuities in the above image is Issue #2 at this post. I do not think the layering algorithm can handle that angular jaggy causing the layers to deflate there.
The mesh jaggies at this surface/surface edge intersection as seen above are Issue #2 exactly. I have tried to reduce the effect of Issue #2 in my mesh by simply refining all the way to Level 11 (overkill I think but had to due to Issue #2). Unfortunately, there are still jaggies even at Level 11 and this is one of them, If I go to a Feature Refinement these ‘step changes of leading edge planform angles’ at the wing ‘ribs’ will also be refined at Level 11 but at a cost of a larger mesh size (a temporary solution at best until Issue is fixed ).
Also, if you look closely at the leading edge joint in the mesh, even at Level 11 there is still small jaggies, which I believe is causing a lot of the small leading edge red zones in the yPlus planform mapping.
I will try the bandaid Feature Refinement and report back…
Dale
Hi @DaleKramer, there is a lot of info here, I just wanted to comment that the red zones that show higher Y+ might actually be where the layers cancel:
And on the topic of jiggles Not sure what is classed as a jiggle, but there will always be some geometry miss representation, we just make the mesh finner until the representation is sufficiently close.
Also on the Y+ estimation and actual, did you turn relative layers off? I have always found that there is some difference between estimation, with some estimates being very off, but they are useful for getting a starting point, and then with results altering the mesh until the correct y+ values are obtained.
If you have a surface highlighted or selected on a mesh and you look at the edge faces, a ‘jaggy’ is where any outside edge face has outside edge corner points that are not precisely on the geometry edge curve which the mesh surface should be following.
I understand that you look at this as just a miss representation which is ‘fixed’ (but not really, you just get smaller jaggies) by meshing finer but that is a bandaid solution. There should be ZERO jaggies on a Surface or Feature Refinement whose job it is to follow the geometry edge curves.
It appears that the layering algorithm can handle what I call Rectangular Jaggies but not the Weird Angular Jaggies where the yPlus red zones are:
Oh if I could only figure out what layer or mesh parameter to change to stop these dips from happening on my layers (that is a ‘rib’ location with Feature Refinement to Level 9 to reduce the jaggies):
@DaleKramer, so we got a mesh, that I would say is acceptable, we could go with this mesh, there are lots of settings in the mesher that will alter this but I’m not sure it would significantly affect results. I would try reducing this to maybe 1 or 2 inflated cell layers and then run with full res and wall modelling to determine the result change. if none, then we probably have good results. Could we then compare to experimental data? is there any?
Best,
Darren
Edit:
We could simplify this to a wing section, validate the results and once valid we can assume the full wing will also be valid?
I was able to get a pretty decent layering (and I am sure I can do better, will explain what I did after I refine it a little more) but I ran into some issues trying to see the relevant yPlus Range and even issues on what the real range is after I did a Save State.
Remember when I asked if the range was ‘normalized’ somehow, well I think it is because we are looking at the data on the first simulation iteration. I finally had an AHA moment and decided to run it to convergence. That converged range is finally what I was expecting and if I can trust the results from opening the PostProcessor from the Solution Fields, here is the mapping and adjusted range so that I get the most Green area on the wing (I REALLY want those max, min, average, std deviation numbers ) :
I don’t really have experimental data, just XFLR5’s predictions which I know are not quite realistic even though it is based on sound methods.
I really don’t want to simplify the example too much, I am sure there are many comparisons of section data with CFD already. I do not necessarily want to have to rely on an assumption that a full wing would be valid.
Now I will make a new Comparison Chart between XFLR5 vs CFD and add it here in the morning along with a synopsis of how I meshed the wing within the limitations of the current refinement algorithms (Mesh 4 in the project is the best and it currently has 2,300,000 faces including the layering).
And my current meshing strategy is (I update this as I learn more ) :
Decide on the wind-tunnel wall sizes and location of the geometry in it, then define these in the Background Mesh Box coordinates. For me, that BMB (on my left/right symmetrical geometry), was about double the wingspan wide, centered in triple the height of the geometry (but much more for just a wing and more if at high aoa’s) and with a BMB length 4 times the length of the geometry with geometry positioned one geometry length back from the front of the BMB.
Set Parameters for number of x,y,z cells on the Background Mesh Box (I started with about ~50 inch mesh squares, it is these cells that get divided by mesh refinements on the geometry. BUT, in the end, 15 inch squares were best for this 125 inch half span wing based on final BMB dimensions and final refinement levels chosen)
A wing geometry should have 3 spanwise edges, 1 at the leading edge at the smallest radius of the airfoil and 2 at the trailing edge. The multi taper wing was split into spanwise planform taper surfaces with ‘rib’ surface edges at each change in taper. You can not have intersecting solids in your geometry, so far I boolean all my touching solids together into one solid in CAD but I expect later to use multiple touching solids but that do not intersect. So far I have only used solids, but I understand that single surface meshes and closed meshes can be used but likely with the same touching/intersecting rules.
You might have to create a narrow surface break near the plane of symmetry to get Surface refinements to act on the symmetry edge of some surfaces (you may likely only have to do this if your geometry is already a 1/2 model of symmetrical item).
I use a cartesian box to provide a refinement ‘outside’ the geometry that is refined at level 2 so that the air gets ready to hit the geometry in smaller cells. I am using about 1/2 the length of x,y and z dimensions of BMB and positioned sorta like the BMB is positioned around the geometry.
I use a cartesian box to enclose the geometry pieces (ie Wing, Horizontal stabs, Fins, Fuselage) and create a Region Refinement for all of them at a Level 5 refinement level.
I used a Surface Refinement on all the wing surfaces to try to get all the edges of the surfaces clearly defined in the mesh. I had to go to Level 10 fineness to minimize the effect of edge jaggies and to keep the trailing edge defined all the way to the wingtip. Unfortunately, I had to change the Level back to 8 when I started layering the mesh since the layering algorithm was choking on the small face sizes and deflating everywhere, so the level was a balance between edge sharpness and layering results.
To keep total number of faces low, I set the edge distance of the Surface Refinement to 0.
To determine if my layering has succeeded sufficiently, I no longer look at clips of my mesh (very tedious). I just use my method of getting a weighted % inflated value for the mesh from the last % inflated chart in the meshing log. This post should show how to create the weighted % inflated mesh parameter.
To get my yPlus between 30 and 300 without too many layer deflation zones, I am using only 2 layers at an expansion ratio of 1.1 or 1.2. I use the old post processor to look at my yPlus range on the on a surface plot of yPlus onto the geometry (this is done on the results of a CONVERGED simulation). The old post processor lets you turn off the bounding box and internal mesh to do this and I can’t figure out how to do the same in the new post processor.
Make sure Parameter ‘Use relative size for layers’ is off (false).
Wow, now that we have a more valid layered mesh and its output data added to the chart… Phew …
I put a note at the beginning of Post 1 to try to reorganize this Topic.
Here are the questions from my first post that are still basically unanswered:
What is most likely the cause of that BIG difference between Cd’s?
Why did the CFD simulation complete with an error (Re Post 1 ‘CFD does NOT include Boundary Layer’ Table)?
Which CFD case is closer to reality (including Boundary Layer or Not)?
6: If CFD results really are closer to reality, why is good old XFLR5 Lift/Drag ratio so far off?
This is where CFD is most useful, we can slice the fields for pressure and velocity through the wing and see why. Create a velocity and pressure slice for with and without boundary layers, furthermore, if you want to invest time into learning to use paraview you could create a delta plot to visualise the difference between the layered and no-layer model (this is not easy though).
Not really sure, can you explicitly send me a link to that project?
Just one thing, be careful about terminology, if the walls are no slip there will always be a boundary layer, and if we are modelling with wall function a certain part of that boundary layer will be modelled. The statement should be with or without cell layer inflation, where with inflation, modelling will likely be correct, without it would likely be incorrect. So with wall inflation is likely to be better. With no validation, however, we can simply say that considering all best practices appear to have been followed, results are likely to be accurate.
I may just do that when I have some time (interpreted as not in the foreseeable future , but oh-oh I see another forum topic
Sorry, simulation was renamed after I started playing with expansion ratios. It is still in the [original project][Deleted by author], Simulation named ‘ExpRatio1.3 Layered and Refined mesh 2’, Run named ‘ExpRatio1.3 135mph’. The Force and Coefficient Plots stop at ~250s and are very stable before 250s. The Convergence Plot stops at ~90s but ‘looks like’ it would converge at or before 250s.
I will be more careful. I suspected there was some BL formula being used with no cell layer inflation as in that case surface mapping of U, shows 0 everywhere. I just was never able to get an image that showed how it got from 0 to freestream magnitude near the surface.
I guess it really was just a rhetorical concluding question. As you can probably tell by how much burning of the midnight oil has gone on around here, I am sold on SimScales interface with OpenFoam and CFD in general. I guess I have to go back to XFLR5 and do some digging, I will report if I find an error in my case there…
If you are ever in central Florida I have this waiting for you…
Is there a way to set up a simulation to assume irrotational flow?
I found this SimScale Doc that suggests a Potential Flow Analysis is what I want, but I have not been able to figure out from that link what parameter values are actually needed to set up a Potential Flow Analysis. It is a great link that provides a lot of parameter explanations but not to tell me what to do to set one up and it looks like it MAY be 2D.
And then I thought, aha, I bet if I just did a laminar simulation, it would be irrotational and then I find out not all laminar flows are irrotational
Just trying to be able to compare apples to apples as it looks like XFLR5 assumes irrotational flows.
Yes, that is what you are looking for, and unfortunately, it was removed as analysis type because nobody used it and it wasn’t accurate in most cases anyway. All is not lost, however, if you go into simulation control and select initialise with a potential flow (it might already be set as true?) then the time step 0 will have the results of the potential flow simulation (we use it to get a better set of initial conditions). The catch is, that I am not sure if lift and drag values are reported for 0-time step, if so great, else, you might have to do some imaginative post-processing in paraview.
Also, I read a paper showing that in 2D cases lift and drag values for both Blade Element Momentum Theory and CFD both showed to have a similar lift and drag values and were similar to experimental also, now, it could be that the CFD model could be run through a mesh independence study to get more accurate results, but I would not have said that the level of indifference could be corrected. My theory is that a 3D BEM doesn’t solve things like lift-induced drag caused by tip vortexes and the like, however, at this moment cannot find a paper to back it.
If I had to do what you are doing, I would be tempted to go 2D, not because it is what I want to simulate, but because it would prove to myself that the setup is valid and that CFD does agree with xfoil, and if so, move on with the assumption that the 3D results would also be correct. This is because, despite apparent simplicity, wings are not easy things to simulate, and if sufficient mesh is not present where needed, then this could skew results. And knowing what the results should be, compared to CFD, we can easily determine what is working and what isn’t, at this moment in time, both BEM and CFD could equally be valid, we just don’t know
Ok, there is no reason why this error happened, it looks to me like it just crashed, I will report this issue immediately, but for now please just restart the simulation, and most definitely let me know if it occurs again (I think it would be unlikely). Also, if I was selecting an instance to run on, I would probably pick a 16 or 32 core machine for a 3 million cell mesh, to be efficient but your choice might be worth checking you are actually saving time though.
Thanks, that simulation was eons ago in my 15 day learning curve , I have since learned a lot from different sources on # of core usage. In my memory now is #volumes/50,000 if #volumes < 500,000 else /100,000, whats your in brain memory formula? Also, what is in your memory for what to remember most about a mesh, nodes, faces or volumes?
Ahah, I don’t actually have a formula, I just tend to band into 3 categories, sub 1 million sub 16 cores, 1-5 million 16-32 cores, more than 5 million 16 core + depending on ram needed and how fast I want the results But that’s me just being lazy.
I remember volumes, I normally say mesh size, by that I mean size in terms of cell count. So 500k and 32 million, would be mesh sizes to me in terms of cells/volumes.
In the meantime I tried a laminar flow assumption on the NON layered mesh with air viscosity 0 (I was trying to stop rotation) but that only got the Cd by CFD to be only 320% bigger than XFLR5.
I will try the 0-time look at NON layered mesh with potential flow initializing and report back.
2D is next
BUT for sure my eyes are opened and are seeing for sure why XFLR5 type programs should not be relied on for real life 3D situations about drag…
).
Not sure what is classed as a jiggle, but there will always be some geometry miss representation, we just make the mesh finner until the representation is sufficiently close.
) :
, but oh-oh I see another forum topic 
waiting for you…
cheers buddy sounds amazing!
, I have since learned a lot from different sources on # of core usage. In my memory now is 
But that’s me just being lazy.