Hi @cweisheng!
Let me comfort you a bit here. I will work on a video on y+ next week which will include my posts, some theoretical background but also applying the knowledge to a case where you we go through this iterative process of improving y+, does that sound good to you?
The problem I see is that a lot of people write and talk about y+ but almost nobody shows how to actually do it.
Keeping you up-to-date! 
Jousef
Hi @jousefm! Good to see this topic has sparked some discussion and apologies for dipping into the negativity a bit in my frustration. As you know I’m very bullish on SimScale in general, however I do think there needs to be some work in this area. An iterative example would be very helpful… I’ve been through the “mastering CFD” course you offer and I understand the Law of the Wall at least well enough to apply it here (I think), but the combination of a LOT of possible settings in the mesher, inability to do detailed inspection at high cell counts (mesh clip always fails), and 20+ core-hour runs per iteration has me shooting in the dark
For my little project I think I’m going to scale back to the automatic settings which were working passably well and then run comparative simulations from there. While they may not be objectively correct, they should show me the differences between geometries as long as I’ve made the same mistakes in each one.
Hi @DaleKramer, many thanks for BOTH of your very interesting posts. My problem is that I’m simulating a high beta AND alpha angle for lateral stability, so there isn’t much in the way of symmetry I can use. I’m investigating tendency of the aft control surfaces to become ineffective and why.
Also, when you have ‘Layer Size’ (used to be Relative layering) enabled in the mesh parameters, you need to specify your final layer thickness (FLT) as a ratio of the nearest cell size. You have it enabled and are requesting a FLT of 0.0003 which is a very small ratio, I used ~0.3 to 0.4 when using relative layers.
I think you may have simply looked at the project after I had reverted to my simpler mesh settings to be able to move forward. I had it “layer size” disabled and was specifying in meters. I think in the future I would probably revert to relative layering to help the solver automagic out any discrepancies.
I think you need to take a close look at your boundary layer thickness calculations. Those are awfully thin layers you are requesting for that size and speed of aircraft.
Perhaps this is an indicator that I DONT really understand y+ then. Certainly I’m using an arbitrary reference length (~1/3 of the fuselage), but I’ve tried a range and the reference length doesn’t seem to have a large effect on the y+ result. Here’s the results from the y+ calculator, would love your thoughts:
Very interesting, I am about to make a long post to help, but first off I see your p an u values are significantly different than SimScales default values of 1.1965 and 0.000015295. This makes a huge difference in the wall spacing.
Can you look into the difference while I make my long post 
Absolutely no problem! It is great that you communicate your feelings about the platform which helps us to further improve it and helps others in the end. So feel free to criticize as much as you can and let me know what we can do better!
@DaleKramer, I guess time for a hangout call if you are free in the next time to plan something great for our users here, what do you think? 
Cheers!
Jousef
@jousefm Yes, I am available most times, but my schedule changes a lot at the last minute, so we can try again
I understood that, which is why I was trying to suggest a way to get a larger cell count full model into SimScale than your 16 core limit can create. But that is likely moot now, read on…
If there was a way to recall settings from simulations (even failed ones) and mesh settings we would not have these problems like the current misplaced FLT ratio issue I saw. (I have asked for this - hint hint).
I copied your project and started my [own version here (I will delete this in a couple weeks)] [Deleted]
First, I am straying from my normal position that I don’t like to do the work myself for others, but here I will because you are making an effort and goals of this project are on my list to investigate anyway 
Below are my changes to get a 5 layered mesh at 33 m/s (that is what your velocity vector approximated in magnitude). I tried to use all my previous suggestions to you as follows.
:I will leave it to you to run a simulation and confirm the y-plus surface values.
I suggest not starting out with zero gradient walls (I have not had much luck with them but perhaps they behave better now). This gives you a baseline comparable for ‘Forces and Moments’ that can be used to see if zero gradient walls behave the same as slip walls at 0 Beta and 0 Alpha.
You can add further refinements as needed to stay within your 16 core limit (eventually I will have a procedure to optimize them too ). If you really want those small trailing edges to be layered, then you might try an (ugh) feature refinement and a further, finer surface refinement on those trailing edge surfaces.
Hope this gets you going again
Dale
I assume you’re referring to my Pressure Outlet walls with 0 Pa value. This is something I struggled with; how to keep the flow going in the specified direction. After testing a bunch of inlet-outlet and freestream conditions I settled on this method as the velocity vectors seem to stay constant after stabilization, at least as far as I have been able to introspect. However, I am seeing a strange issue that may be related - I’m using a velocity table to ramp velocity from 0 to 31 m/s over about 25s. The entire simulation time is 250s but over that time I still see a fairly dramatic difference in flow velocities between timesteps, such that I don’t necessarily trust that I’m dealing with fully developed flow by the end of the simulation. Any ideas on how better to implement flow? I initially wanted to move the model with straight on flow, but that doesn’t seem to be available in Incompressible.
If you want to use zero gradient walls then we need input from others ( Power users ). I simply create a different geometry and mesh for each alpha or alpha/beta I want to investigate and used slip tunnel walls on an optimally sized BMB. I hope you are OK with finishing your mesh from here…
Thanks many times to you, @DaleKramer for your work on meshing and your direct help on this project. I was lost before and I didn’t know how much. Following the CFD master class, I naively expected that an incomplete boundary layer would simply change the magnitude of my results. In fact it completely changes the flow characteristics across a model, as I’ll show below. I was finding the results from my initial analysis really confusing and now I know why: I had a really crappy mesh with an overly-large boundary layer and poor coverage.
Side note: perhaps this is a trivial finding for you CFD experts out there, but for people like me (engineer with little experience in complex physics simulations), it’s super important. The accessibility of SimScale make it really tempting to throw something together and end up with a garbage-in/garbage-out result. I’ve seen more and more engineering candidates come through my door lately with an over-reliance on FEA/CFD methods and not enough skepticism or sophistication to even attempt corroborating the results with experiments or hand calcs. I’m hoping this post will serve as a warning for how wrong it can really be even if it looks right.
My original mesh, developed using the various refinements recommended in car/truck/plane tutorials and example projects I found in the Public Projects. I included surface refinements, boundary layer inflation, feature refinement, and some detailed flow volumes. Total cells: 6.8MM.
Mesh developed using the Kramer’s Method (oh yeah). Only two refinements: surface and BL inflation. Surface refinement calculated with a target y+ of 165 to be 6 resulted in a nice fine mesh with really good BL coverage (assessing this from the meshing log table). Despite a finer mesh, 4.7MM cells. It’s not how many cells you have, it’s where you put them.
Running identical simulations - velocity ramped over 25s, 1s timestep, the Kramer model converged more quickly. Here is my convergence plot:
And the Kramer plot:
y+ for my model was all over the place, and high:
The results speak for themselves. Here’s pressure distribution across the model
And isovolumes showing ~50% of the freestream velocity and lower. My mesh shows a large recirculation zone beside the fuselage, eventually enveloping the tail midway along the horizontal stabilizer.
Okay that’s what I’ve got… now running out of memory trying to bring the surface refinement up so this might be as good as I can do on 16 cores. Next I’ll add some region refinements to Kramer’s mesh to see if I can smooth out the flow field a bit, but until then - HEED MY WARNING 
EDIT
I went ahead and extended the simulation time of the Kramer BL mesh because I had a feeling that it hadn’t achieved steady-state yet. The result is more in-line with what would be expected… similar flows but probably more accurate with a better BL.
Moments of the poor mesh:
You would need to start the process over if you want to change the surface refinement level. As you can see there were quite a few calculations done before we determined that Level 6 was what to use for surface refinement from the conditions that we started with…
With a region refinement you need to look at the granularity of say the pressure profile around and behind the craft by post processing and showing some slices of the volume mesh results. My guidelines for this is stalled until the 2.5% undefined error I found is resolved.
I personally think that proper meshing is about 90% of what separates good and bad CFD results.
Please post a y-plus surface mapping for my interest
Sorry, overlooked that … Looks good, you can try to lower that 165 to 50 and look at the difference.
Hi everyone,
A custom BC with all parameters set as zero gradient is usable for the sides of the domain. For varying the AOA without needing to re-mesh and re-do the geometry, you can use simple vector notation and apply it as a inlet-outlet BC at the top, bottom, front and rear of the domain. This leaves the sides as “open air” for the custom zero grad BC.
Try it out and see if you can get the flow to behave accordingly. From what I’ve tried before (albeit a long time ago) this works and is a good workaround.
Do note that the same rules still apply in that a sufficiently large Bounding Box is required.
Cheers.
Regards,
Barry
@jousefm, any way to get him some more core power for now so he can complete this very worthwhile project?
This is also a bit of a bump post in case people have not seen the amazing edits @jhartung made to Post #27…
Dale
Be careful, using more cores than absolutely needed is VERY core hour wasteful
Amazing discussion here folks. Really insightful.
Okay @DaleKramer, true to form I threw a bunch more cores at the problem and ended up with a mesh failure (again). What I changed was the addition of a refinement volume of level 6 around the empennage. Having thought a bit about this, it makes sense - a refined volume requires a recalculation of the layer thickness ratio in order to keep the thickness of the BL the same. This begs a question: have you found any way to have refinement regions that don’t encompass the entire model, or are we limited to full-model refinement regions with your method?
I have not had much luck with region boxes that split my model. I think you can enclose the whole model as follows without too many more cells created…
From my personal procedure I am developing re: Un-Optimized Region refinement box:
I have never found the need to use the refinement level of the GBorg as fine as the initial surface refinement.
Your surface refinement is Level 6, so my gut says try 4 (5 at the most) for the GBorg refinement level.
So, maybe try level 4 or 5 on your box that splits the model and if that does not help, then try the box that encloses the model as above.
