code_saturne User's Forum

I've completed a simulation with:
- SIMPLEC algorithm
- reference time step 0.01 (1/10 than before)
- BiCGstab with 1e-5 precision

It took almost 19 hours over the weekend.
Courant number is now <20 almost everywhere and regions >1 are small.
"c Velocity" is about 60-70 at each step.

The overall pressure drop is in the attached file.
I'm planning to produce a "realistic" geometry that I can post here, but I need to talk to my boss when he's back.

Hello,

With all the previous tests, I have lost track of some details, so it would be interesting to also post some info about your latest data setups (listing, setup.log, performance.log files), to see if I have any additional recommendations.

The "final" pressure drop is difficult to interpret without details in those files.

Also, in addition to the pressure drop plot you have, a cut plane visualization of pressure and velocity on different options may be interesting (even if you don't post them, checking them to see how the flow differs in a more qualitative manner may be useful for you).

Regards,

Yvan

Hello.

Yvan Fournier
IMHO, I found some bugs in Saturne 4.0.0 that I don't see in "what's new" for 4.0.1 and 4.0.2.

1. Intermediate results writer doesn't work via GUI. The bug seems to arise due to incorrect "options" field in XML file written by the GUI module. Please checkout this fragment of the XML: As you can see, EnSight options for built-in writer is "binary" while for my intermediate writer this field is set to empty string. As a result, no any intermediate results a written.

2. Saturne processes crash on calculation finalisation with button "Stop now" in GUI. Fortunately, they write results first, including restart files, but partitioning info is not written at all or written partially (for example, for 2 of 4 partitions). It may be due to old OpenMPI version that wat installed from repository and should be 1.4.3 for my Ubuntu 12.04.

3. May be not a bug but... Two of three Reynolds stress models (RSM) doesn't converge with all known to me "converging" settings in Saturne GUI (SIMPLEC + target CFL as low as 1.0, increased relaxation sweeps up to 7, relaxation=0.1 for SIMPLE and even Upwind for Velocity that reduces precision). Symptoms are maximal velocity spikes up to 2 orders of magnitude relative to normal with fast reduction to expected level. These spikes are persistant during tens of iterations even if calculation was started from complete SST results (more than 1000 of iterations). Setup is described below (valve test for this topic).

Sorry if I missed something about fixes for 4.0.1 and 4.0.2 in "what's new" and for offtopic.

Ccaccia73
Results look a bit terrible taking into account that CFL<20. Not a disaster, but so big difference (~8.25/~11.0 bar) in SIMPLE/SIMPLEC results is not pleasant.

I performed my test calculations with abstract valve geometry. Results are more or less normal except maximal velocities (not pressure difference) with Reynolds stress model.
I attached the 3D geometry outline in my previous post. Valve consist of inlet part, membrane with orifice, disk on a stem and outlet part (sorry for terminology, I don't work with valves). Inlet and outlet diameters are 100 mm, membrane orifice diameter is 40 mm. Tetrahedral mesh built with NetGen in Salome (two variants with ~0.33 and ~1.0 millions of cells).
Fuild is water with density of 1000 kg/m3 and dynamic molecular viscosity of 0.0002 Pa*s. Inlet velocity set to 5 m/s, walls are smooth.
There was five main variants:
1. Mesh ~1 mln cells, SIMPLE, SST turbulence.
2. Mesh ~1 mln cells, SIMPLEC, SST turbulence.
3. Mesh ~0.33 mln cells, SIMPLEC, SST turbulence.
4. Mesh ~0.33 mln cells, SIMPLE, K-Epsilon turbulence.
5. Mesh ~0.33 mln cells, SIMPLE, RSM turbulence (second and third RSMs from 4.0.0 GUI).
Number of iterations in all variants was enough (IMHO). I controlled the solution by maximal pressure stabilisation (in fact - our target parameter, pressure drop) and maximal velocity stabilisation. Minimum number of iterations was more than 300 (AFAIK), for first variant ~700 iterations, for second (based on first) ~700+500 iterations.
I attached the archive with my case (without big RESU directory), it's abstract and not confidential.

You can see the comparison of velocity fields in axial cross-section on attached image. Primary flow features and velocity levels are very similar with different meshes and turbulence models (SST/k-epsilon). But there are differences in secondary features like recirculation zones or "slack flow" zones. It's not very good, but also is not surprising, you may obtain differences like these in commercial programs too (various programs or turbulence models). We should also take into account that flow may be unstable in "secondary" zones.
RSM variants on "0.33M" mesh didn't converge, there was maximal velocity spikes up to thousands m/s while normal level is 71 m/s (it's not in the axial section on the picture or there are interpolation issues).
Meanwhile, pressure difference on this abstract valve was almost the same in all variants and lied in range 1.41...1.45 MPa depending on variant and iteration (even including one non-stable RSM variant). As you can see from total pressure distribution on the picture below, pressure loss in this case, like in many other cases, is due to local accelerating of the fluid (dynamic pressure increase) with subsequent slowing down and dissipation of energy that was associated with dynamic pressure. Please note that total pressure on the picture (and, IMHO, in most other meanings) is a sum of static and dynamic (0.5*rho*w^2) pressures, not an absolute pressure like in Saturne terminology. Distributions of total pressure are very similar among tested variants so I only attached one of them.

So what do we have? There are apparently no significant difference between my valve-test variants (in pressure drop) inspite of changing the mesh and turbulence models. Therefore, I don't see the way I can help you because your geometry is confidential at the moment (it's OK, I just point it). Possibly we'll found the reason for different results when you will get the permission to upload you geometry. Have you performed current test with the old mesh or with refined mesh?

Hello,

I doubt there is a bug with intermediate outputs, as I use this feature quite frequently (so I should have noticed). The "binary"/"empty" aspect is not an issue, as binary is the default.

Are you sure you associated the additional writer to your output meshes ? Did you check the "auto" variables feature for possible additional meshes ? They don't seem to be in your xml files.

I am interested in details about the crash when you stop the calculation from the GUI. Partitioning info is not written by default if you use space-filling curve (Morton or Hilbert) partitioning, as it is deterministic an can be recomputed easily. Otherwise, you can change this behavior in the "performance tuning" section fo the GUI.

For the cases that don't converge, a "listing" (and "performance.log") file would help me guess whether the issue is due to a too high initial time step (even if the later target is good), to a mesh quality issue, and how best to work around it, without needing to run the computation.
The differences in results are probably related to a time step issue, and the initial time step may have a role.

Also, the major point (why I recommended looking at the velocity and pressure fields in detail in the first place) is that if there is no significant influence of the turbulence model (or code version) on the velocity and pressure fields, there should not be a major influence on the pressure drop either. Meaning the difference may be "artificial", due to the way things are postprocessed (as measuring a pressure drop in a 3D complex geometry is often more tricky than it seems).

Regards,

Yvan
Regards,

Yvan

Yvan Fournier
Thanks for you reply.

It's a good news that intermediates are OK. Looks like I missed some setings. I only added intermediate writer with properties similar to default writer except output interval (50 iterations). Will check manuals now...

Partitioning info is not written by default
Yes, I enabled it for my 5.7-million mesh on furnace for testing and because this relatively small mesh is not very small for PC, partitioning takes sensible time. First run was OK but then there was crashes. I disabled partitioning info writing for valve tests but solvers continued to crash at the end of calculation (GUI reports MPI timeout, listing without errors, no *error* files).

For the cases that don't converge, a "listing" (and "performance.log") file
OK, hope I will not forget about them. Now I have no saved RSM runs because they all was unstable, possibly due to mesh issue (many "bad-gradient" cells on 0.33-million mesh). I then noticed similar maximum velocity peaks on k-epsilon (although they was rare) so I decided to run RSM on 1-million mesh (it's better than 0.33-mln). In this run there are also high maximal velocities but number of iterations is not enough.

the way things are postprocessed
BTW, may I ask a question about postprocessing? To "measure" pressure at the inlet I tried to use "Integrate variables" filter in Salome (ParaVis/ParaView), but it only integrates area or volume and, AFAIR, coordinates. No other variables! On inlet or volume, on points or cells, no other variables... I asked a question on CFD-Online but there is no answer after 26 days.

Hello,

Writing partitioning should not be the cause of your crashes.

How much memory does your machine have ? On your largest mesh, if you happen to need "swap space" memory, then performance crawls, and you can get timeouts... Otherwise, do you have user subroutines ? Statistically, crashes are caused most often caused by bugs in user subroutines, then by installation issues, then by bugs in the code itself.

I would recommend integrating inside Code_Saturne (for example in cs_user_extra_operations, which was called usproj in version 2.0) rather than under SALOME, as you can ensure more consistent values. Be careful, the boundary pressure output by version 2.0 is "non-reconstructed" (it can also be output by 4.0 using a low-level setting). And as the code uses a cell-centered discretization, interpolation to the boundary in a consistent manner is tricky even within the code (I am not a specialist for that part of the codes, but there are many related threads on this forum, both old and new). And inconsistencies here can explain differences in postprocessed pressure drop values, especially if pressure variations are important near domain boundaries.

For balance-type integration on a volume, there are code examples in version 2.0's usproj and version 4.0's user_examples cs_user_extra_operations-*balance* files. The balance by zone is useful for scalars, but I am not sure whether it may be adapted easily to pressure (I'll ask colleagues later this week).

Otherwise, if you still want to do it under ParaView, you probably need to have a projection of the pressure on the boundary, so, for a "non-reconstructed" output, check the cs_user_parameters-output.f90 user example to see how to do this (search for iflpst). Othewise, using the "Cell Data to Point Data" filter may help (though it is hard to tell how ParaView interpolates; I tried checking once, and it seems interpolation is a non-weighted average of neighboring values).

Regards,

Yvan

Yvan Fournier
Hello.

How much memory does your machine have ?
PC have 16 GiB of RAM, maximum consumption for 5.7-million mesh (test "cold flow in furnace") was ~8 GiB (Saturne report), crashes was on 1-million mesh too (but they are not on every run). No user subroutines in both cases, no swap activity (0 bytes in swap).
May be the reason is some incompatibility. Saturne have a number of dependencies, maybe, for example, my OpenMPI version (should be 1.4.3 from repo) does not match Saturne 4.0.

I would recommend integrating inside Code_Saturne
I thougth about this. But it's only applicable for runtime monitoring. If you need, say, a static pressure for pressure sensor selection in a custom section, "user-function" method will require a re-run of calculation and additional function programming instead of just creating a slices and integration filters in ParaView. So, IMHO, user functions are more appropriate for runtime monitors (and. I hope, I'll use them for this).

boundary pressure output by version 2.0 is "non-reconstructed"
Fortunately, it often can be avoided by placing BC where the pressure gradient is low, like in my valve-test case.

"Cell Data to Point Data" filter may help
It does not help... I use this filter extensively because many ParaView features cannot work with cell-associated data, only with poit-associated. But this filter has not effect on integration, "IntegrateVariables" still outputs only coords and volume (or area for BC). I will now ask on Salome forum.

it seems interpolation is a non-weighted average of neighboring values
Not good... Thanks for the info.

Now about the diverging RSM case. I performed another test yesterday. Model was set to Rij-SSG, reference time step 1e-05 s, target CFL=1.0. Despite of a very small time step, velocities was up to 10^5 m/s Is is laminarization, or it's not actual for SSG? I attached a case archive without large files in RESU. If you want, I'll upload whole RESU directory. Relevant settings are in "Valve Mesh=1M RSM" XML, you can open the case directly in GUI.

Hello,

Yes, the RESU directory (or at least one run) would be most useful (at least the log files it contains, which should not be too large).

If the problem is not a time step issue, it is probably a mesh quality or refinement issue. In this case, some options (additional sweeps, gradient reconstruction, scalable wall functiions...) may help somewhat.

Regards,

Yvan

Yvan Fournier
Hello.

Small files from RESU directory are already in archive, it's a complete case without huge result files (see my previous message). If you want full RESU content, you may download it from my Google disk:
https://drive.google.com/file/d/0BzPt_Y ... sp=sharing
Just unzip files in RESU.

some options (additional sweeps, gradient reconstruction, scalable wall functiions...) may help somewhat
I already tried some "stability" options and it did not help (SIMPLEC + target CFL as low as 1.0, increased relaxation sweeps up to 7, relaxation=0.1 for SIMPLE and even Upwind for Velocity that reduces precision).

Sorry for the usual lag, I just collected the data of the last 3 tests:

test01:
- simplec and improved pressure interpolation
test02:
- simple
test03:
- simplec, tstep = 0.01 (1/10 wrt. previous tests) and biCGstab

when trying to plot streamlines with Salome/ParaVIS, it looks like there's something not working properly. This is what I have when I plot streamlines from Saturne 4 results: And this is what I have form Saturne 2 results (please note that they're not exactly the same conditions, so absolute values might be different)