[Saturne 6.0.6] Particles are accelerated by head loss

Forums code_saturne usage
1

Hello. I guess I found the bug in Saturne 6.0.6. I’m not allowed to share the entire geometry, but, I think, it’s not a matter of particular case. In this case, there is a gas duct with recirculation line intake and head loss volume zone that represent the tube bundle. Gas phase calculation was successful (tube bundle resistance is accounted for without problems), then I introduced particles on frozen gas velocity field. Although particles move by expected streamlines, when they enter volume zone with head losses, their velocity rises gradually by ~25m/s (gas velocity is around 7.5 m/s in this area). I attached picture with particles mean velocity field.
Case setup is very basic. Gas velocity in problematic area is ~7.5 m/s (aw well as particles velocity before resistance zone), gas pressure drop across resistance zone is ~250 Pa at height of 1.2 m (resistance coefficient is 16.8 m^-1). Gas density is 0.365 kg/m3, dynamic viscosity is 3.17e-05 Pa*s. There are 9 particle fractions (classes) with sizes from 2.5 to 100 mkm. I attach case setup [xml] files for gas-phase and particle runs (case for gas-phase run is marked with A suffix that means “pure aerodynamic”). Please note that, in particles case, some values for gas phase are not set.

I tried Saturne 6.3 feature version but I was unable to set resistance coefficient in this version. GUI just doesn’t accept it, when you switch to another dialog and back, all 3 resistance coefficients become zeroes whatever you set.

Would anybody, please, fix this particle acceleration in resistance zone? Maybe pressure gradient force is accounted for incorrectly?

BTW, Saturne gave 11% of particles coming into recirculation line while Fluent gave 15% that is quite good agreement (this case’s purpose is to ensure that Fluent doesn’t give us too low particle fraction in recirculation line).
D-G000-R000-S000A.xml (16.8 KB)
D-G000-R000-S000.xml (17.6 KB)

ParticlesVelocity.png
ParticlesVelocity.png514×624 58.3 KB

2

Hello,

I reproduce the issue for the head loss in v6.3 (in a somewhat variant form) so I’ll fix this.

For the main issue, I’ll suggest the Lagrangian model specialists to take a look and post here.

Best regards,

Yvan

3

I just fixed the GUI head losses input issue in the v63. GUI, so the fix will be in v6.3.1, and is already on the v6.3 branch on GitHub.

Best regards,

Yvan

4

Thanks! Willl wail for reply about particle acceleration from Lagrangian module programmers.

5

Dear user,

Thank you for the feedback. We are aware of this problem which is due to the fact, if I understand well, that the additional force you have on the mean fluid (with the head loss) is missing in the lagrangian module (all terms on the momentum are not automatically taken as they should).
We will try to fix that soon.
Best Regards
Martin

6

Hello, thanks for so fast reply. Sorry, but, I think, it cannot be due to a missing force on particles because, if you leave such particles with only drag and gravitational forces under case conditions (given densities and gas viscosity, constant gas velocity), they will not accelerate more than by 1.1…1.4 m/s (terminal velocities by 3 different models for largest particle class of 100 mkm). So I can only guess that you consider gas pressure gradient force on particles and there is a mistake like unit conversion in pressure gradient force. Although it may be something more deep. Hope you will fix it without problems.

7

Regarding aerodynamic resistance zone interaction with particles, in my opinion, maximum that can be done for distributed resistance approach is an optional calculation of resistance with gas-particle mixture density instead of gas density (0.5DXResistanceCoefRhoMixtureGasVel^2). If calculation is performed with frozen gas flow field, density effect from particles on head losses cannot be accounted for (no particles at this stage). If you have porosity<1, gas will accelerate and so particles, it doesn’ require additional code. I think it will be as physical as possible.

8

Hello,

What Martin means is that when using head losses in code_saturne, an external force is always added, but the Lagrangian module does not take it into account in a consistent manner, which explains the issue you have. This is more a refactorization issue in the code.

If you are trying to reach a steady state and have one-way coupling, a workaround would be to use head losses in an initial Eulerian computation, then run a “frozen field computation” , removing the head losses to avoid the extra term. For a coupled computation, a fix in the code is necessary.

Best regards,

Yvan

9

Hello. May I know current progress in resolving the issue?
Regarding physics, sorry, but I cannot agree with applying additional force to particles in resistance zone. What happens physically in that region? Fluid is accelerated and decelerated when passing through construction elements like tubes or perforated plates, static pressure is not restored fully that cuses head loss and it’s correct to represent it by mass force. Particles physics is different. They are carried by the fluid, if there was no fluid, just gravity, their behavior would be completely different from gas or liquid. For particles it’s enough to be driven by the drag force and other forces from liquid + gravity etc in this approach (small concentrations, not KTGF \ fluidized beds). If you apply additional force to particles in resistance region, their velocities and concentrations will change that is not true. In reality, if you measure particle and gas mean axial velocities and concentrations in resistance zone referred to full section (superficial velocity, that is shown by the model when porosity is 1), they will be the same as for other parts of the straight duct with constant section.

10

Hello,

As I am not an expert in that part of the code, I was perhaps not very clear, but the issue is one of numerics, not physics:

In the Eulerian part of the code, head losses are handled by adding an “equivalent” external pressure force. The Lagrangian model uses some elements from the Eulerian part, and terms should be handled in a consistent manner. It does not mean we would be adding a “physical” force, just making the model consistent. In any case, in a head loss region, I would assume competing effects, with acceleration with the flow due to reduced porosity/flow section, and slowdown due to collisions.

There has been recent work (in the master branch) so as to handle the “complete” turbulence model for Particles in a cleaner manner: so either particles are purely fluid (tracer), or handed as solid particles, whose handling with stochastic equations is adapted/synchronized with the Eulerian part. I cannot say more because I am not familiar with the details of the theory for the Lagrangian model in code_saturne (which is based on stochastic differential equations, not a collision model).

Again, the issue here is related to an inconsistent handling of some terms between the Eulerian and Lagrangian parts. So the forces which would need to be added are “numerical” in nature, to compensate for the artificial force induced by the pressure forces added to the Eulerian model. Otherwise, you get the acceleration you observe.

In any case, head loss zones are tricky, since the concept of head loss is simple in 1D but subtle in 3D, and mainly because the obstacles which lead to head loss often have effects on porosity (which handled by code_saturne), and turbulence (so specific turbulence source/sink terms should be added, but depend on the actual geometry, so a specific finer, resolved model, or measurements would be necessary for each physical component type).

In any case, I do not know if the issue is easy to fix (just a matter of refactoring some code), or much more subtle. I’ll let Martin or Mathieu comment on this, as they are more familiar with this.

In the meantime, you might try to experiment with the “full” model to see if the same effects occur.

Best regards,

Yvan

11

Thanks for your explanation and support! I see that it’s more numeric thing… Resistance zones are not simple for the universal representation as distributed pressure drop / heat transfer. We use this approach intensively for boiler heating surfaces and heat exchangers (in Ansys CFX/Fluent) and I can say that there is no “distributed approach” that can represent real object reasonably well in all cases even with user-defined expressions for heat transfer or resistance coefficient. So it’s normal that Saturne will not describe real objects perfectly with distributed resistance/porosity/heat transfer. No any program can do that. Regarding resistance area, it will be enough if program will physically just retain particle forces that are accounted for in entire domain. If porosity is less than 1, fluid will accelerate and so particles (due to drag force). CFX also has option to enable heat transfer with porous solid material (that is stationary) via simple correlations like q=HTC*DeltaT. Also, if you want to implement near most detailed resistance model, you may add porous resistance option (porous resistance is proportional to velocity, inertial one - to velocity^2, there is only inertial resistance in Saturne GUI for now in version 6.3). Although we never used porous resistance, there may be users interested in it.

12

Hello. May I know if there is some progress in resolving particle acceleration issue?

13

Hello,

No, not to my knowledge. Looking at the code (analyzing another possible issue), I see that in src/lagr/cs_lagr_sde.c,
after the call to cs_user_lagr_ef, there are expressions using “grav” and “gradpr” (both with and without added mass).

The gradpr (pressure gradient) is probably influenced by the head loss, and thus related to the issue. It would be interesting to replace this by a constant value in a test to confirm this avoids the incorrect behavior.

If this is the case, pending a clean solution, adding an artificial “compensation” external force (which ideally would be “pressure gradient without head loss - pressure gradient with head loss”) with the user function would probably be a working solution.

Best regards,

Yvan