Saturne doesn't like tube bundle?

[Antech]

Hello.

I'm working on simulation of gas flow around the ribbed tube bundle and decided to compare CFX results with Saturne for additional verification. Computational domain includes a slice of the several rows of ribbed tubes with inlet region for velocity profile development before the bundle model (see attached picture). I built tetrahedral mesh in Salome successfully (2 mln cells with sizes 1...3 mm while domain thickness if ~20 mm).
BCs include velocity inlet (~10 m/s), pressure outlet, symmetries at top, bottom and one side, and walls (see the same picture). Turbulence model is SST k-omega.

The problem is that Saturne 4.0.0 "doesn't like" this case for some reason. From first iteration there are extremely high pressures (10^5 Pa e.t.c.) and then very high velocities, after that solver crashes. I reduced case to minimum complexity: only pressure/velocity fields, small timesteps (down to 10^-3...10^-5 s) and strong relaxation (with coefficient 0.1). I tried SIMPLE and SIMPLEC schemes, steady and unsteady modes but problem is persistent. SIMPLE with default settings divegres in several iterations and solver crashes. Unsteady SIMPLEC with reference step 0.001 s and target CFL=1.0 gives velocity magnitudes up to 137 m/s at 379th iteration (10 m/s at the inlet) that grows with iterations (no convergence). IMHO, it's not normal, I can't get what is the reason.
I can visualize the solution after several iterations with small timestep while solver is still working and I see normal gas streamlines without obvious "bugs". Pressure distribution shows maximums at the outlet and high values at the tubes (ribs).

Why does my case is so unstable? There is no "custom physics" or user functions, pure aerodynamics. May be I should not split the pressure outlet in 3 sections (see picture)?

I also attach a case archive without big files in RESU (but logs are there). There is an unsteady run with timestep 0.001 and target CFL 1.0. Full results can be downloaded here:
https://drive.google.com/file/d/0BzPt_Y ... sp=sharing

Thanks for your attention.

[Antech]

Ivan Fournier
Sorry for inconvinience! I used Google's drive for the first time and didn't know about permissions. I replaced the download link and, if I did it right, granted the access by prevoius link for you.

[Yvan Fournier]

Hello,

One possible issue I can think of is the fact that Code_Saturne often doesn't like non-orthogonal meshes near the outlet. I'll be working on an integrated extrusion feature later this month, but for now, your best bet may be to add one or two layers of "extruded" cells at the outlet(s), so that the cell-center -> boundary distance is the same for all neighboring outlet cells.

This may help quite a bit.

Regards,

Yvan

[Antech]

Yvan Fournier
Thanks, I will make a case with common outlet (without splitting into 3 parts) and prism layers (constant thickness) and the outlet. May the division of the pressure outlet into 3 parts be the reason for instability? Would it be better to move the outlet away from tubes and make it a single face?

[Antech]

Yvan Fournier
Hello.
I made the new bundle case with single outlet and it sems to be better than first one. Although I used SIMPLE with default numerics + relaxation 0.5 (including pressure increase relaxation), the only stability problem was pressure strike to ~10^5 Pa at first iteration.
But results are still not plausible. There is a velocity (and pressure) peak near the outlet (see attached picture). I'll try to create prisms at the outlet to make the mesh orthogonal.

[Antech]

Hello.

I performed calculations with mesh prisms at the outlet. You can see the mesh fragment near the outlet on attached picture.
Case parameters remained the same (steady, SIMPLE) except relaxation coefficients that was restored to defaults (1.0 for pressure increase and 0.7 for other variables). By the way, I discovered that Saturne does not set user-specified (GUI) relaxation for pressure (SIMPLE scheme setting) and retains "internally selected" 0.9.

The problem with pressure strike to 10^5 Pa on first iteration did not eliminate! Maybe it's somehow connected with gaps between ribs that has only 3 mesh cells in heigth.
But other iterations was OK and "solution bug" with non-physical velocity peak at the outlet disappeared. I dont know what was the particular reason because both relaxation and mesh was changed (to save time).

Some results are on another attached image.

[Yvan Fournier]

Hello,

I wouldn't be too worried about the pressure at the first iteration: you're going from non-moving fluid to moving fluid in one time step, which is a sort of "non-physical" transient, so I'd avoid interpreting that part too much as long as things converge well.

Regards,

Yvan