Clipping of the Reynolds-stress tensor

[StandardRANSUser001]

Hi everyone,

I am working with the elliptic blending Reynolds-stress model, and there is an issue that I am unable to resolve. The calculation is running (unsteady or local timestepping), and the velocity and pressure fields look good. What I am finding however, is that the Reynolds-stress tensor is clipped in certain regions, and I cannot eliminte these clipped regions. This tensor is important to my work, and I would like to see this without any clipping.

Are there any strategies to elimintate this clipping? I have seen this same issue accross different test cases.

If I had to make a guess, it is associated with the timestep in some way, as I often see a correlation between regions of high Fourier number that are asociated with regions of clipping.

Interestingly, the steady solver does not have this clipping issue. However, my steady solver is diverging, and I would like to have the same result with a local timestepping option.

Can anybody provide any advice or best practice recommendations on this?

Best regards,
Sean Hanrahan

[Yvan Fournier]

Hello,

I think some colleagues are working on trying to solve this sort of issue (so they have observed it too), but I don't know how much progress they have made. I'll remind them to check the forum if they find a bit of spare time...

Best regards,

Yvan

[StandardRANSUser001]

Hi Yvon,

Thanks for your quick reply.

Could you provide any more information about the issue, or the how the developers intend to implement the change?

I am looking to finalise some work with the EBRSM before mid December, and I will need to understand whether this clipping is affecting the solution of my RANS calculation, or whether it is a post-processing issue.

Any guidance on this would be greatly appreciated.

Best regards,
Sean Hanrahan

[Yvan Fournier]

Hello,

I am not sure about details, but talked about it a bit with my colleague, and he expects to push a fix within a few days. I am not sure how much influence this can have on the computation.

Best regards,

Yvan

[StandardRANSUser001]

Hi Yvon,

Thanks for your help with this - if there is a way to push this out shortly, that would be very helpful for my work. It would be great if he could please provide some indication of what has been modified, as I have been wrestling with this issue for several months, and I would like to understand what has changed. This will help me understand if I need to rerun any calculations.

I am not sure if this is just me, but I have also noticed some strange time-stepping behaviours with the EBRSM model. Firstly, I have noticed that the fourier number is not limited (even when a limit is set). Secondly, I have noticed that the setup.xml file has precedence for the time-stepping characteristics.
As an example of this, if I have a setup.xml file and a cs_user_parameter.c file (with time stepping options set), I find that the setup.xml file time-stepping options have precedence.

I thought that I would mention this second point, so that we could investigate this behavour further when time allows.

Best regards,
Sean Hanrahan

[Yvan Fournier]

Hello,

Are you using v8.0, v8.2, or the master branch ? The time-stepping priority you describe does sound like a bug, unreported/noticed so far, so we'll need to check that.

Regarding the clippings, Jean-François just pushed a change allowing separate deactivation of clippings for Rij and epsilon, but I assume it is only part of the changes he is working on.

Best regards,

Yvan

[StandardRANSUser001]

Hi Yvon,

Thanks for your help with this.

Currently I am on the 8.2 branch.

Please also thank Jean-François for his help as well. Has he been able to test this in any particular configuration? i.e. with/without the coupled solver option, particular schemes, time-stepping options, or gradient clippings?

Does this solve the "pixilated" issue that we see in the Rij, epsilon, and Fourier NB fields? I see this effect in regions of the flow that don't have any particularly interesting flow physics/turbulent effects.

Best regards,
Sean Hanrahan

[StandardRANSUser001]

Hi Yvon,

I was wondering if you would be willing to bring these modifications back to cs8.2.x?

I think that these modifications were made after the functions in src/base were updated to c++. This is not a simple undertaking port these changes back into a 8.2.x implementation, right? I would assume that these changes are still in testing, and not suitable for production calculations.

Best regards,
Sean Hanrahan

[Yvan Fournier]

Hello,

Actually, using:

git fetch origin master
git cherry-pick fa6d25e5a3ff43a8e53da8e073d37dcb15e0bb75

From the v8.2 branch "almost" works. The C to C++ conversion is not the issue, You can run the command and edit cs_turbulence_rij do see the merge conflicts (between "<<<<<", "=======" and ">>>>>>>").
The conflicts seem to come from successive changes, and also mostly changes in cs_parameters.c.

The nightly validation runs seem mostly OK, and we added som fixes today, so trying out the master branch is probably simpler. v8.3 will be released between December 15 and 20, but I understand that may come a little too late for you.

Best regards,

Yvan