How to calculate scalar based on frozen average velocity?

[Tsubasa]

Hello Yvan,

I faced the same problem in the last post, and I noticed when it occurs.

Let's say when the flow simulation is run with Steady RANS to get the average flow field at first,
we have a problem if we use unsteady RANS or something different solver after restarting.
In that case, the flow becomes 0 everywhere.

Best regards,
Hamada

[Yvan Fournier]

Hello Hamada,

So if I understand correctly, this occurs when you change the turbulence model between runs ? In this case it should be easy to reproduce, but if anyone has a simple (small) test case allowing me to reproduce and debug this quickly, I'll be happy to take a look.

Best regards,

Yvan

[Tsubasa]

Hello Yvan,

Can you test it with these files?
At first, flow is solved and get average velocity field by URANS.

flow_simple_test.zip

(1018.48 KiB) Downloaded 67 times

Second, the scalar transport is solved on the average velocity field by pseudo-RANS.

scalar_simple_test.zip

(468.91 KiB) Downloaded 62 times

As I said, in the example for scalar transport, all the velocity is replaced by 0.

Mesh is this.

simple_test.med

(168.62 KiB) Downloaded 55 times

I really need this way, so I hope this bug will be fixed as soon as possible.

Best regards,
Tsubasa

[Yvan Fournier]

Hello,

Checking under a debugger, I think the issue is related to the fact that your original run uses a local (pseudo-steady time step) and the new one uses a constant time step.

When handling time moments, 2 fields need to be stored for the recursive updates: that of the moment, and an accumulator. When using a constant time step, the accumulator is optimized so as to need only a single value, but it seems the case where we switch from uniform to local time step is not handled in the restart mechanism.

I'll need to see if we can handle this better when doing restarts, as switching between global and local time steps is a common practice, so this is a "so far undocumented/unexpected" limitation and can be considered a bug.

In the meantime, if you run the initial case with a constant time step (at least the part where you accumulate the mean), you should be able to work around the issue.

Best regards,

Yvan

[Tsubasa]

Hello Yvan,

Thank you for your quick response.

As you said, what I want to do now is to switch PRANS to URNAS before and after restarting.
I know this bag does not occur when I used PRANS (or URANS) both before and after restarting.
But unfortunately, I had a divergence problem when running URANS for the initial case... but it works with PRANS. Based on the average velocity, in the second case, I want to see an unsteady trend so I have to use URANS...

Best regards,
Hamada

[Yvan Fournier]

Hello,

If you switch from steady to unsteady (constant or time-varying, but uniform time step) before activating the time moments, you should be OK. If you have a divergence with a constant time step, your CFL value may be took high, so you may need to reduce the time step a bit...

Best regards,

Yvan

[Tsubasa]

Hello Yvan,

Sorry I do not understand well, so let me check.

What I want to do now is
Step 1 - make an average velocity field in some way (total 18000 steps, and calculate the average from 6000step to 18000step)
Step 2 - Solve scalar transport on the average velocity using URANS. (Here I want to get the time history of the concentration)

Actually, I am trying a pressure-driven flow, which is more unstable than a normal simulation. Divergence happens when using URANS, but not pseudo-RANS. Therefore, I am glad if I can switch from pseudo-RANS (PRANS) to URANS after replacing the flow field with the average velocity field obtained by PRANS. To get the average, do I have to activate the time moments, right? For pressure-driven flow, SRANS never works.

Best regards,
Hamada

[Yvan Fournier]

Hello,

I prefer not to express this in terms of URANS/SRANS, but in terms of local/unifor time step, as the equations solved are the same in all cases (i.e. time-dependent terms may be computed unless you expressly set the "istat" option for turbulence-related fields, but only the numerical scheme is modified by the steady/pseudo-steady settings).

If the uniform or constant time step always fails in you case, than to work around the issue, you could overwrite the instant velocity and mass fluxes by the averaged values in the cs_user_extra_operations function at the last time step of the initial computation, and just use a standard froze field restart in the downstream, "frozen field" computation. which basically amounts to moving and adapting the block of code you have in cs_user_initialization on your 2nd computation to the cs_user_extra_operations of the initial computation (only at the last time step).

Best regards,

Yvan