PROBLEM IN THE BOUNDARY CONDITIONS USING COMPRESSABLE MODEL

[Yvan Fournier]

Hello,

Thanks for the feedback. Actually, I spent quite a bit of time on this case, and the missing flow information might a separate issue that I will fix as soon as possible.

I have now fixed the cause of the crash (inconsistent checks initialization changes and tests) in the master, v7.0, and v6.0 branches (mirrored on GitHub). So at least the computation can run, even if there is a missing info in run_solver.log.
Results seem different though (max velocity higher in v5.0 after 10 iterations; have not pushed it further yet, I need to understand where this comes from...)

On v5.0, there is no issue. On my machine, 5.0.13 works as well as 5.0.4. So if you have a problem with v5.0.13, it is probably either a difference in settings, or an installation issue.

The other issues seem to come from a change in September 2017... And it seems our test suite has a shock tube with all other compressible BC's, but we are probably missing a regression test (or test case) for this BC type... I'll see what I can do, but no guarantee it will be this week...

Best regards,

Yvan

[tpa]

Hi Yvan.

I just downloaded and compiled v5.0.13 to see.

The reason it fails to me seem related to the libhdf5 implementation and it fails in the preprocessing stage. Pecucilar that preprocessing has worked fine in the later tested versions which were compiled using the same libraries (those of Salome Meca 2018 ( in V2018.0.1_public/prerequisites/Hdf5-1814)

The error message is not in any log file of code_saturne but if the case is started directly from the terminal is will be shown on the terminal:

Code: Select all

/opt/code_saturne-5.0.13/arch/Linux_x86_64/libexec/code_saturne/cs_preprocess: error while loading shared libraries: libhdf5.so.9.0.0: cannot open shared object file: No such file or directory
Error running the preprocessor.
Check the preprocessor.log file for details.

If I make a link from /opt/Salome-Meca-2018/V2018.0.1_public/prerequisites/Hdf5-1814/lib/libhdf5.so.9.0.0 to /usr/lib/x86_64-linux-gnu the calculation actually starts. So seemingly the compilation environment is not implemented completely in v5.0.13 as it should. Also, if you have installed and use the libraries of the host system distribution you might not experience this.

Conclusion: The main issue of the compressible module seems not present in v5.0.13

Considering v5.0 is approaching end of life it might not be using time on that issue, unless you want a bug free v5 for download. Anyway the above dirty fix works.

I will not let the study run to an end in v5.0.13 and see the results. It will take some hours - but is is the computer working, not me Thanks again for the great support.

[Yvan Fournier]

Hello,

It seems a bug was hiding another one....

In all versions (including 5.0), when defining an imposed compressible inlet, the flow rate (or velocity, depending on selected variant) was not set correctly. It seems flow occurred through the effect of other variables, but the value was too small.
This has been fixed in the master, v7.0, v6.3, v6.0, and v5.0 Git branches.

As for the difference in behavior between v5.0 and later version, thanks to Erwan, this has been fixed also yesterday.

With all the fixes, velocities are quite a bit higher in this case, but running with a time step of 10-7 seconds works (or better, an adaptive time step with 10-7 seconds reference) seems to work well.

So hopefully we have finally solved this issue. The next releases (v7.0.0, v6.3.1, v6.0.7) will contain the fix, but is is available immediately cloning from GitHub. The same goes for v5.0.14. As we usually do, when v7.0.0 is released, a final v5.0.14 version will also be released).

Thanks for the bug report. Though we do not use the compressible model much ourselves, people in other organizations do, or try to...

As regards the hdf5 issue, it is probably best to go back to a separate thread in the install section of this forum, but if you have a workaround, it may not be essential for v5.0.

Best regards,

Yvan Fournier

[tpa]

Thank you very much Yvan and Erwan. I really appreciate all you do with code_saturne. I will try the revised versions. Is it possible to get the revised v5 source from github, or is only the latest build available there?

[Yvan Fournier]

Hello,

All release branches starting with 1.3 (first open-source version) are available from GitHub, and synced the changes yesterday, so yes, the latest v5.0 fixes are available from GitHub.

Basically, you need to run

Code: Select all

git clone https://github.com/code-saturne/code_saturne.git
git checkout v5.0

(assuming your Git version is not too old; there was an extra command needed in older version if I remember correctly).

Then :

Code: Select all

cd code_saturne
./sbin/bootstrap

Which requires that the GNU autotools are installed (autoconf/autmake/libtool).

After that, the install is the same as when using a .tar.gz version (except the documentation is not pre-compiled).

Regards,

Yvan

[tpa]

Hi Yvan

I also see a not very convincing difference in results between versions. A factor 2 on velocity and pressure.

After 3.5ms in v7(from github):

After 3.5ms in v5.04:

I tried to run a incompressible steady solution to have something to compare with but I the solution is unstable. If you have a standard test case (maybe also a bit smaller) I could try that, if you want.

Edit: I just realized that the "Fluid properties" tab has now disappeared. And stays gone, even if I delete ~/.config/Code_Saturne and creates a new case structure. So my v7 is not functional anymore so I may not be able to assist with testing with the newer versions than v5.

[Yvan Fournier]

Hello,

In v7.0, fluid properties can be defined separately by volume zones (mainly to allow for easier setup of fluid/sold internal thermal coupling).

So the fluid properties are now in the "volume zone"s tabs.

As for the difference between v7 and v5.04, as I said in my previous post, v5.0.4 already had a bug, in which the imposed inlet velocity was not taken into account (to verify it in v5.0.4, simply change the input mass flow in the GUI; you will probably have no change in the solution due to that bug). So v7.0 (or v5 from GitHub) should be better.

Regarding the steady state test case, are you trying to run this on the same case ? Given some velocities, the compressible aspects may have some influence, and perturb comparisons.

The ideal solution would be to have experimental results on this test case, or a test cas with experimental results on which we could match this. I am not too sure about the imposed inlet either: whether before of after the patch, the flow rate does not seem to match, so I assume there is an "unsteady" aspect,

Comparing with a subsonic inlet condition would be interesting. A way to turn the problem around may be to use the Laval nozzle test case, currently using a subsonic inlet condition, by using a prescribed inlet (based on postprocessing of the current setup) and check that results remain similar.

There a a few (not many) additional boundary condition options for compressible flows, available in user subroutines but not in the GUI. Maybe post v7.0, we could try to add them to the GUI.

Best regards,

Yvan

[tpa]

Dear Yvan,

I am sorry to seem knitpicking ... but I just installed v5.0.13 trough github, and as seen with Paraview the results from above case at t=1.0ms look very alike for all three tested v5 branches:

v5.0.4: Mach: 0.48 (max); Velocity: 160 m/s (max)
v5.0.13: Mach: 0.48 (max); Velocity: 160 m/s (max)
v5.0.git: Mach: 0.48 (max); Velocity: 160 m/s (max)
v7.1.git: Mach: 0.82 (max); Velocity: 400 m/s (max)

The inlet boundary condition is defined as volumic flow rate in all runs (same .xml). But yes indeed there is a bug in v5.0.4 as the application of the inlet condition as a mass flow failed to run - also for me.
Edit: added numbers for v7.1.alfa.

[Yvan Fournier]

Hello,

Sorry, I had forgotten to push my local fix to the main Git repository...

If you update 5.0.git, you should now obtain higher velocities than with 5.0.4 and 5.0.13.

Best regards,

Yvan

[tpa]

Dear Yvan.

I wanted to test current v6.0 as well. So I issed the "git checkout v6.0 ; sbin/bootstrap" and installed, which gave me version "6.0.6-patch". It gives this error message:

Code: Select all

@                                                            
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@                                                            
@ @@ WARNING : STOP WHILE READING INPUT DATAS                
@    =========                                               
@    SPECIFIC PHYSICS MODULES (COMPRESSIBLE) SET             
@                                                            
@  The bounds of the variables energy or temperature         
@    have been modified :                                    
@                                                            
@                      SCAMIN        SCAMAX                  
@  energy         0.00000E+00   0.10000E+13
@  temperature   -0.10000E+13   0.10000E+13
@                                                            
@  The bounds of these variables should not be modified.     
@  It is possible to modify the bounds of the variables      
@  density or energy in uscfx2, but it is not recommended.   
@  It is advised to manage the possible overshoot by the     
@  use of the functions defined in the file cfther.f90:      
@  cf_check_internal_energy, cf_check_temperature (stop of   
@  the calculation at the end of the time step in case of an 
@  overshoot).                                               
@                                                            
@  The calculation could NOT run.                            
@                                                            
@  Check parameters.                                         
@                                                            
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@

I also still get an error (presently with v7.1.alpha) when I apply inlet boundary condition as a mass flow, stating that the density product is zero on the boundary. In order to get things running I need to apply this boundary condition as velocity or volumic flow.
Maybe relevant compile.log reports the following:

Code: Select all

.../CFD/Laval/RESU/20210321-2232/src/cs_meg_initialization.c: In function ‘cs_meg_initialization’:
.../CFD/Laval/RESU/20210321-2232/src/cs_meg_initialization.c:48:17: warning: unused variable ‘c_id’ [-Wunused-variable]
       cs_lnum_t c_id = zone->elt_ids[e_id];
                 ^
.../CFD/Laval/RESU/20210321-2232/src/cs_meg_initialization.c:63:17: warning: unused variable ‘c_id’ [-Wunused-variable]
       cs_lnum_t c_id = zone->elt_ids[e_id];
                 ^
.../CFD/Laval/RESU/20210321-2232/src/cs_meg_initialization.c:80:17: warning: unused variable ‘c_id’ [-Wunused-variable]
       cs_lnum_t c_id = zone->elt_ids[e_id];
                 ^

I am thinking there is a synchronisation delay on github so I will try later in the week to come to see if the latest patches will be included.