Mesh quality issue and slow running code

[aminrasam]

Hi,

I have recently upgraded from version 2.0 to 3.0.
I am running LES of turbulent channel flow using the wale model at Re_\tau=180.
I generate my grid using a tangent-hyperbolic function and export it as a .unv format file.
In version 2.0 it worked very well. In version 3.0 however, it generates the following warning:

Warning:
-------
Mesh quality issue based on user criteria has been detected
The mesh should be re-considered using the listed criteria.

The code continues to run, but it runs very slowly. In version 2.0 the time per time step
for running the code on my workstation was 0.1 second. On version 3.0 it is 60 seconds.

Could you please comment on, what is the warning about and what is the criteria that is referred to.
Could you speculate, why the code is running very slow.

Thanks a lot,
Best Regards,
Amin

[Yvan Fournier]

Hello,

The warning about mesh quality is not important, it is related to a user example. Still, are you using 3.0.1, 3.0.0, or an earlier beta version ? This warning appeared for older versions, but I do not believe it should appear by default.

The slowdown is not normal, so there is probably a bug in your installation or your data setup, but until you provide the usual details listed in the forum usage recommendations, we can't really guess at what causes it.

Regards,

Yvan

[aminrasam]

Dear Yvan,

Thanks for your reply.
I have attached all of my case files. The version of the CS that I use is 3.0.1.
Please let me know if I should provide more details.

I use the automatic installation both on my workstation and on the cluster.
The files that I provided are from the run on the cluster, but the same problem happens on my workstation.

Thanks,
Best regards,
Amin

[Yvan Fournier]

Hello,

The time per time step in your listing file is about 20 seconds, not 60 (but still a lot for 2000 cells per rank).

There are several issues:

- you seem to include many user subroutines you do not use (for example, cs_user_modules.f90), and in most user subroutines, you leave everything or almost to "false" (meaning it is not used).
It is better to clear unused sections, if only to make them more readable for support (i.e. allowing us to see what is changed compared to defaults).

- I recommend using the GUI for most of the setup, and user subroutines only for the parts where the GUI does not allow fine-enough control. Even if you do not have PyQt4 installed on the cluster, you can edit the XML file on a workstation, and only need libxml2 on the cluster. Same reason as above, it allows using minimalist user subroutines and helps see what you are really doing compared to the defaults.

Also, I do not know if you did the same with version 2.0, but why did you deactivate the multigrid solver for pressure ?

Also, with the automatic installer on the cluster, did you use the MPI already on the cluster, or install one with the installer ? On clusters with fast networks, the MPI installed automatically will not use the fast network (Infiniband for example), so it is essential to use the one already present.
That was already true with version 2.0.

Finally, more detailed information is available in the performance.log file. Also, comparing the "listing" from version 2.0 and 3.0 may help in troubleshooting.

Regards,

Yvan

[aminrasam]

Hello,

Thanks for your reply.
I found the problem with slow running code was related to the incorrect parameters I used.

I could not install the GUI on my own machine or the cluster, so I have to skip using the GUI.

I removed almost all unnecessary files as you recommended and activated the pressure multi-grid solver.

I want to implement my subgrid-scale model in the CS. First, I need to run a LES with no SGS model
in a channel. So I run the CS using the WALE model and I overwrite the eddy viscosity with zero in the cs_user_physical_properties.f90 file. This works well.

For implementing my own SGS model, I need to do test-filtering of various quantities. With the WALE model, I get an error message when I use the 'cfiltr' routine:

'SIGSEGV signal (forbidden memory area access) intercepted!'

Is there a way to use the test filter with the WALE model?

With the dynamic Smagorinsky model, I can use the test filtering using the 'cfiltr',
but I get an error when the code writes intermediary restart files:

SIGFPE signal (floating point exception) intercepted!

I have attached my case files for this run. Could you please comment on why I get the error.

Thanks for your help,
Amin

[Yvan Fournier]

Hello,

Regarding the WALE model, I don't know if there is an expected incompatibility or not with the filter, so I'll try to get info on that withing a few days.

For the Smagorinsky model, I'm not sure, but in src/turb/cs_les_filter.c, line 126, could you replace
n_cells with mesh->n_cells_with_ghosts (adding the modified version of this file to your user subroutines) and check if you still have the SIGFPE ? There might be an incomplete initialization bug (not impacting results, as the values computed in the "ghost cell region" are not used afterwards, but an error here may stop the calculation even if it only impacts temporary "unused" values).

Regards,

Yvan

[aminrasam]

Hi,

Thanks for your reply.
Your suggestion for the dynamic Smagorinsky worked very well.

Overwriting the eddy viscosity from the dynamic Smgorinsky with that of my model makes the computations expensive. Could you please advice me if there is a way to use the WALE model instead with filtering capability.

Best,
Amin

[Yvan Fournier]

Hello,

The bug for dynamic Smagorinsky will be fixed in 3.0.2 (and 3.1), using the same patch I suggested you, so thanks for reporting the bug.

Regarding the WALE model, I'm not one of the turbulence specialists, so I'll have to remind myself ask them before I can give you the answer...

Regards,

Yvan

[David Vincent]

Hello,

The warning about mesh quality is not important, it is related to a user example. Still, are you using 3.0.1, 3.0.0, or an earlier beta version ? This warning appeared for older versions, but I do not believe it should appear by default.

The slowdown is not normal, so there is probably a bug in your installation or your data setup, but until you provide the usual details listed in the forum usage recommendations, we can't really guess at what causes it.

Regards,

Yvan

Hello,

First of all that's the first time i write on this forum.

Although you said the warning about mesh quality was not important , I'd like to show you a report of my the mesh quality that report a fatal error when meshes are read.
Could you tell me if i can ignore these errors?

I use CS 3.1.0 and Salome 7.4.0 as mesh generation.

Regards,
david

[Yvan Fournier]

Hello,

"Warnings" can be ignored (though it is recommended to check them to make sure they are not too important), but in your case, if the Preprocessor has a fatal error, either you file is corrupted (not too probable if it is a recent file generated by a recent version of SALOME), or there is a Preprocessor bug... According to the backtrace, the bug is in the I-deas reader, so it occurs at the earliest stages of preprocessing, basically during mesh import (long before quality can be "measured").

Could you post your mesh (ideally, the smallest mesh which produces the crash) to this forum. If it is confidential, you can send it to me by private message (if you are not allowed or do not want to send it, then building Code_Saturne with --enable-debug would at least add the code line numbers in the error traceback, but debugging on the real mesh will take must less time).

Regards,

Yvan