OMP usage issue and a little bug report

Questions and remarks about code_saturne usage
Forum rules
Please read the forum usage recommendations before posting.
Post Reply
ZHUOJUN
Posts: 15
Joined: Fri Oct 16, 2020 12:16 pm

OMP usage issue and a little bug report

Post by ZHUOJUN »

Hello,
I am writing for a little question about the usage of MPI and OMP in Code Saturne 7.1-alpha. At present, I usually run CS on my laptop within a virtual machine, which has a 8 cores 16 threads CPU, and 8G ram. My computation, or work is easy somehow. I only need to set one time step for a transient situation.
My purpose is to run CS with OMP alone, means no MPI. The reasons are simply. My program skills about MPI is far away for usage, and my ram is relatively insufficient for MPI. I have tried once, when I put some test codes in some SRC files, where I set one core and one thread in GUI. I include the omp.h, and use

Code: Select all

omp_set_num_threads(16);
#pragma omp parallel for 
{
  for (int cell_id = 0;......)
}
to check if openmp is activated. But the result is negative.
So I am eager to know that, if there is any chance I can use openmp to complete my computation alone? Thus I can save time for assigning values to cells due to physical model. Generally, the computation time is much less than the pre-stage.
And also a little bug report. In the latest github version, there is a little error, in file cs_rad_transfer_fsck.c, line 1241

Code: Select all

kfsk[i] /= 100.0;
 to be 
kfsk[i] *= 100.0;
This is a step to change dimension from cm^-1 to m^-1.
Thanks for your any generous help.
Yvan Fournier
Posts: 4077
Joined: Mon Feb 20, 2012 3:25 pm

Re: OMP usage issue and a little bug report

Post by Yvan Fournier »

Hello,

Thanks for the report for FSCK.

I am not sure I understand your other remarks. You mean in your case, one time step with an unsteady solution is enough ? That must be a very specific usage ?

In any case, using MPI usually requires a bit more memory than using OpenMP only, but at low core counts, the difference should not be huge.

Also, you should set the number of threads in the beginning, but if you increase them later, you will get limited benefits in some loops, as renumberings are adjusted to the initial number of threads.

Looking at the beginning of the performance.log file, the number of threads is indicated, so if it is > 1, then OpenMP is activated. But in any case, if you are using MPI and are assigning properties "per cell", the partitioning used by MPI usually makes this even faster with MPI than OpenMP (in most cases, you simply use a local loop, and do not worry about MPI, unless you need a global exchange or reduction).

Best regards,

Yvan
ZHUOJUN
Posts: 15
Joined: Fri Oct 16, 2020 12:16 pm

Re: OMP usage issue and a little bug report

Post by ZHUOJUN »

Hello,
Thanks for your detailed explanation.
My case actually is considered with thermal radiation issues. Given its time scale is so small thanks to the light speed, I only pay attention to a certain(transient) situation. That is why I set one time step. Additionally, I have not coupled it with conduction or convection yet for the sake of debugging my gas model.
In my case, I found that the 'OpenMP threads: 2' and can not set to be another number. But the MPI rank or Processors may vary due to my setting in the GUI.
So I am curious about the "set the number of threads in the beginning". Does this mean that the N_processors * Thread per core? Or I should set Nprocessor = 1, and threads to be anything I want ignoring the reality that 1 core -> 2 threads.
When I set 1 core but threads = 14, I found that it was in fact the ID 14 doing everything. And no matter how many cores are, the omp_get_num_threads() only return the exact number I set for thread pre core.
Sincerely,
Zhuojun
Yvan Fournier
Posts: 4077
Joined: Mon Feb 20, 2012 3:25 pm

Re: OMP usage issue and a little bug report

Post by Yvan Fournier »

Hello,

Normally, you should be able to use the GUI to set the number of cores. This simply sets OMP_NUM_THREADS to the desired value in the temporary "run_solver" script which is executed in the run directory.

You can ignore the actual number of threads per core, because depending on how many cores you have, the total number of OpenMP threads will vary. (The actual hardware topology is not detected, and the number of processors per node detected and listing in "performance.log" is not used, as it can depend on the combination with MPI).

Best regards,

Yvan
ZHUOJUN
Posts: 15
Joined: Fri Oct 16, 2020 12:16 pm

Re: OMP usage issue and a little bug report

Post by ZHUOJUN »

Greeting,

Thank you so much for your help. Now I have fundamental knowledge about this part, and also I am glad to report bug(s) as long as I would found.

Yours,

Zhuojun
Post Reply