Maximim number of linear solver iterations in Code Saturne 5

[Antech]

Hello. I need to control the maximum number of iterations in linear solver (although I set the precision to 1E-5, sometimes it tries to do too many iterations for velocity). In earlier versions I was able to set the maximum iterations for each variable in GUI, but now, in Saturne 5.0.4, these options has gone. I set maximum iterations directly in case XML, but I'm not sure that it works (till now, numbers of iterations are below the limit) and, sorry, but it's not convenient.

Are there chances that maximum iterations for linear solver will return to Saturne GUI? If not, is it correct to insert these options in XML by hand?

Thanks.

[I also checked the "Stop now" button in 5.0.4 GUI, it still doesn't work in my CentOS 6.5 system from the moment Saturne was 5.0-alpha. I hope it's OK that I opened the minor bug on your tracker]

[Yvan Fournier]

Hello,

The maximum number of iterations cannot be set so simply anymore (since the addition of extra solver options and optional PETSc addition), because we considered it does not have a general meaning (I.e. between simple solver or multigrid solver).

So you need to use cs_user_parameters.c (there are several examples under the Document doc).

For the GUI bug, I'll check if I reproduce it on my machine (I never use this particular feature of the GUI, and you are the first to report this). I'll keep you updated on the big tracker.

Best regards,

Yvan

[Antech]

Hello, Ivan.
Thanks for useful info! Years has passed from the moment I was here at first time and you still help people to cope with difficulties using Saturne. Great work.

I took a look at the cs_user_parameters-linear_solvers.c and, if I get it right, I should change the n_max_iter_coarse_solver (1000) in calls like this for all variables:

Code: Select all

cs_multigrid_set_solver_options
      (mg,
       CS_SLES_JACOBI, /* descent smoother type (default: CS_SLES_PCG) */
       CS_SLES_JACOBI, /* ascent smoother type (default: CS_SLES_PCG) */
       CS_SLES_PCG,    /* coarse solver type (default: CS_SLES_PCG) */
       50,             /* n max cycles (default 100) */
       5,              /* n max iter for descent (default 2) */
       5,              /* n max iter for asscent (default 10) */
       1000,           /* n max iter coarse solver (default 10000) */
       0,              /* polynomial precond. degree descent (default 0) */
       0,              /* polynomial precond. degree ascent (default 0) */
       1,              /* polynomial precond. degree coarse (default 0) */
       -1.0,           /* precision multiplier descent (< 0 forces max iters) */
       -1.0,           /* precision multiplier ascent (< 0 forces max iters) */
       0.1);           /* requested precision multiplier coarse (default 1) */

But this is for multigrid solver. What if I will change the selected linear solver in GUI? Is there a way to limit "linear iterations" for all solvers simultanously? If not, how can I set them on per-solver basis, what functions should I use and what arguments should I set? There is only a multigrid solver in example and I don't know the code to rule out what should I do...
BTW, your code now runs. It does a useful work for one of our calculation cases (noise killers aerodynamic resistance estimation with CFX and Saturne for reliablilty).

Regarding GUI bug. I made a simple script to set some parameters via control file (maximum outer loop iterations, iteration for the checkpoint), so I can do without GUI solver control. But, maybe, this matters for others who use this button in GUI.

[Yvan Fournier]

Hello,

For a simple (non-multigrid) solver, the following example is simpler (choose the solver and number of iterations). It is also from the Doxygen documentation

Code: Select all

  cs_field_t *cvar_user_1 = cs_field_by_name_try("user_1");
  if (cvar_user_1 != NULL) {
    cs_sles_it_define(cvar_user_1->id,
                      NULL,   /* name passed is NULL if field_id > -1 */
                      CS_SLES_BICGSTAB2,
                      1,      /*  polynomial precond. degree (default 0) */
                      10000); /* n_max_iter */
  }

As you may see in the example, this a a "per-variable" setting (here for a user variable named "user_1").

As usual, the settings in user C functions or Fortran subroutines preempt those from the GUI (i.e. those functions are called just after settings from the GUI are read, so as to complete/modify/overwrite them).

Happy to know the code lets you obtain useful results.

I have not checked fro the GUI bug yet, but I'll try to do it soon.

Regards,

Yvan

[Antech]

Hello and thanks for suggestion.
In your example fields are accessed by name. Can I cycle (loop) through all fields setting maximum ~1000 iterations for every field? Is something like this correct or I must use another approach?

Code: Select all

for ( iField=0 ; iField<cs_field_n_fields() ; iField++)
{
 cs_field_t* field=CS_F_(iField); // Field parameters structure pointer
 // Set number of iterations for current field (basic solvers)
 cs_sles_it_define(field->id,
                   NULL,
                   CS_SLES_BICGSTAB2,
                   0, // Polynomial precondition degree (default 0)
                   1000); // Maximum iterations
 // [!] THE SAME FOR OTHER SOLVERS
 // Multigrid solver parameters structer for current field
 cs_multigrid_t *mg=cs_multigrid_define(field->id,
                                        NULL);
 // Set maximim number of iterations
 // for the multigrid solver for current field 
 cs_multigrid_set_solver_options(mg,
                                 CS_SLES_JACOBI, /* descent smoother type (default: CS_SLES_PCG) */
                                 CS_SLES_JACOBI, /* ascent smoother type (default: CS_SLES_PCG) */
                                 CS_SLES_PCG,    /* coarse solver type (default: CS_SLES_PCG) */
                                 100,             /* n max cycles (default 100) */
                                 2,              /* n max iter for descent (default 2) */
                                 10,              /* n max iter for asscent (default 10) */
                                 1000,           /* n max iter coarse solver (default 10000) */
                                 0,              /* polynomial precond. degree descent (default 0) */
                                 0,              /* polynomial precond. degree ascent (default 0) */
                                 0,              /* polynomial precond. degree coarse (default 0) */
                                 -1.0,           /* precision multiplier descent (< 0 forces max iters) */
                                 -1.0,           /* precision multiplier ascent (< 0 forces max iters) */
                                 1);             /* requested precision multiplier coarse (default 1) */
};

Sorry, I'm not a professional programmer and not familiar with the code and I'm not sure that it will not spoil results even if it will compile. Is it OK?

Am I correct setting "precondition degree" (have not clue what's this ) to zero and other parameters (except number of iterations) also to their defaults? I don't want to modify anything except number of iteration and, may be, precision (1E-8 => 1E-5). Are "precision multipliers" in my code proper defaults?

Also, is it necessary to set number of iteration for multigrid solver, or I can just apply cs_sles_it_define() to each field and then multigrid solver will use "basic" solvers with already limited numbers of iterations?

Sorry for many questions...

[Yvan Fournier]

Hello,

You code will not work, because CS_F_ is a macro to access fields with an enumerated index (a quick access structure for some but not all fields).

You can use cs_field_by_id instead, but if you loop on all fields you will define many extra settings for non-solved fields such as properties.

Polynomyal preconditioning degree 0 means diagonal (Jacobi) preconditioning and is the default.

But mostly, I do not understand which solver you want to use. For multigrid, default smoothing steps are fare below 1000 and even the coarse solver is less than that. The default maximum cycles is 100 or 1000 (I don't remember).

For simple linear solvers it is 10000.

Some equations such as pressure correction lead to symmetric (Laplacian) systems, while convection-diffusion leads to non-symmetric solvers. If you use the same type of solver for both, some solutions will probably crash, or not converge. You can query the solver type already set for a given system, but this requires additional programming.

I do not understand why you need to reduce the number of iterations. The only legitimate reason for this is when you need only an partial convergence, such as within multigrid.

Otherwise the cleaner solution is to simply reduce the required precision (or use a solver with better convergence where applicable).

Best regards,

Yvan

[Antech]

Thanks for fast reply.
I just need to trim "very long" iterations at initial stage of calculation. Most of iterations, even from very start, are done quickly but some require thousands on linear solver iterations to converge to 1.0E-5 precision (usually for velocity). So I wanted to reduce maximum iterations for linear solvers, it doesn't affect solution much (usually no more then 500 linear iterations needed) and worked on previous versions. But I see that I can easily do something wrong setting max iterations via use subroutine. It seems that the best option is to lower the precision on first run (anyway I use first order Upwind scheme for the first run) and then to increase precision to 1.0E-5 and switch to SOLU with default blend factor of 1.0. What precision do you recommend for linear solvers at first run?
I also will keep in mind this method with user function. If lowering precision will not help, I possibly will just implement the function for velocity and pressure iterations (I hope, there should be no problems with field structures that can be pointed by field names).

[Yvan Fournier]

Hello,

If you have this issue only for velocity, simply change the maximum number of iterations for velocity, keeping a simple (Jacobi or Gauss-Seidel) solver:

Code: Select all

  cs_sles_it_t *c = cs_sles_it_define(CS_F_(u)->id,
                                      NULL,
                                      CS_SLES_JACOBI,
                                      0,
                                      1000);

Regards,

Yvan

[Antech]

Hello. Thanks for advise. I thought about this (change only maximum iterations for velocity and pressure that are accessible by field names). Can it be advanced to all solvers? I would like to do it universal, not dependent on solver selection (for example, I use Automatic solver selection in Saturne 5 now). Should I apply the limitation for all basic solvers and multigrid one? Or to basic solvers only?

[Yvan Fournier]

Hello,

No, this cannot be done in a "global" manner because the number of iterations does not have a "global" meaning (i.e. it is completely different between multigrid and simple iterative solver, and even or similar variants, may have a different meaning; for example, A iteration of symmetric Gauss-Seidel is more or less equivalent to 2 iterations of basic Gauss-Seidel). As I explained, this is why the option was removed from the GUI.

When you force solver options, those replace the "default" in any case. We could think of adding "global" defaults for solver categories (i.e. symmetric/Laplacian mainly for pressure an non-symmetric for convection/diffusion for most other variables), but even this may be tricky (i.e. convergence behavior may vary from one variable to another due to different BC's or source terms, upwinding or limiter aspects, ...)

I still do not understand why you want to do this for all solvers when you only seem to have issues with velocity.

Regards,

Yvan