Hi both,
No that is not the issue. Core count does not affect solution stability. The decomposition algorithms are quite robust and only give negligible result errors, not instability in the solution.
Cheers.
Regards,
Barry
1 Like
This is one of those times where a Slack or Discord chat would be great.
Yes we did mention about it. I use slack and wouldn’t mind joining one. Maybe @jousefm can start one?
Hey Barry & Bryce!
Will create a channel and invite all of the PowerUsers 
Best,
Jousef
I’m not sure I like Slack for this kind of thing. The beauty of a forum is that the posts persist, are editable and searchable, and the conversation stays (mostly) on one topic. I find important information gets lost in Slack conversations as posts move up the infinite scroll. Other users won’t be able to benefit from the conversation either. Not to mention it’s super distracting.
I agree with you in general terms but I just joined that new Powerusers Slack (and never used Slack before).
I can see where there is purpose in both ways of communicating and I hope that we can all divide the conversations between forum posts and Slack (and other) appropriately 
1 Like
Slack is good for figuring out what everybody wants for lunch.
Or discussing privately a potential forum item post between power users in order to ensure the post’s validity
1 Like
Yes, wow
@jhartung looks like you are making progress. While potentialFoam is great for reaching convergence, it can cause a few issues of its own.
Looks like pitch and roll moments will take quite a bit longer to stabilize, may have to think about trying the ‘Continue the run’ feature (but won’t take many more core hours for long runs at these settings ) unless you see another issue here???
Yes, with less than 500 core-hours left I’ve been pondering this. I think it’s time to be an engineer about the problem. My goal is to understand the lateral stability in the airframe with a variety of nose lengths. Looking back on all my simulations, yawing moment has been consistent regardless of all my BL or mesh density shenanigans: around 2800 N-m about my measurement datum. Pitching and rolling moments vary wildly though, so I’m not going to trust those until I do more.
On the positive side I’m getting closer to a full resolution mesh!
That is very nice, how many cells?
Sorry, spoke too soon, did not notice your Y+ scale.
I think this is Run 22 more pertinent Y+ map scaling and it is very confusing to me, did I do it wrong?
Hi Barry, @Get_Barried
I looked into the ‘body check errors’ more on the geometry we are working with, when I remove the spinner and nose cowl from the plane and re-import that, the ‘body check errors’ disappear.
But the ‘geometry is watertight’ message disappears when I do this.
@jhartung, perhaps you can look into getting a geometry that imports without the ‘body check errors’…
I also had a look at the layering parameters I calculate to determine how good a layering is , using data which I obtain from the the meshing log table. I was hoping you were using that metric in your cat and mouse efforts.
I calculate ‘Average Layers per Face’ and dividing that by the ideal # of layers requested I calculate ‘% of perfect’.
Here they are for your Run22 mesh (top part of chart only):
I am now less confused with the Y+ mapping I shown here (and the previous one is likely similar too)… 47% is not very good…
I am running a 64 core on the 69% perfect 25.6M mesh now, but I do not have much hope for it. I like to see in the 90% perfect range…
I think it is time for a MK4 project 
, start with geometry that has no ‘body check errors’ and is watertight.
While you are doing geometry ops, try to get rid of as many faces in the geometry that had zero layers made on them in the mesh log, they are very small in one direction at least (you could layer them but you would have to surface refine them to a much higher level… Every time you have a deflation at a small face it takes a great surface distance away from that face to get back to 12 layers, which is likely the cause of losing such a high % of perfect for you…
Hi Josh!
Added 3,000 more to your account for your investigations, also extended your academic licence. At the end we want to summarize everything and create a guide out of it if possible 
Best,
Jousef
I see I may have created a monster here. While it is amazing you are striving for a pure y^+ < 1 mesh, please remember that this only matters for areas where determining the the separation point is absolutely critical. For example, a NACA 0012 at flat and level has no flow separation and therefore you don’t need such a strict y^+; however, if you wanted to find the exact stall point by doing successive simulations then the separation is critical and y^+ \leq 1 is absolutely necessary.
I’m guessing for the majority of your plane that a higher y^+ will be adequate but areas that are really important to separation should be refined. Does that make sense?
1 Like
Yes, but I assume that the wing will have separated well in front of the trailing edge and that the side of the fuselage will have separated somewhere and both of those areas are not anywhere near Y+=1. (in fact Y+ seems to be measured in the 1000’s there).
I think both areas mentioned will surely have an effect on rudder blanketing.
I assume that in order to know where separation lines exist, that the boundary layer must be modeled properly everywhere…
I too have seen the great variations in moments between different y+ results and have been very confused with that since forces seem to vary little with different y+ results . I am hoping perseverance here will lead to better understanding on my part from my weird perspective
And we have not even looked at EVR plots yet