[petsc-users] How to set up -mat_mumps_icntl13 1 in the code?

[Barry Smith]

   Giacomo,

    src/snes/examples/tutorials/ex22.c is an example of how one can set options in the program and then have the command line options override them.

char  common_options[]      = "-ksp_type fgmres\
                               -snes_grid_sequence 5 \
                               -pc_type mg\
                               -mg_levels_pc_type none \
                               -mg_coarse_pc_type none \
                               -pc_mg_type full \
                               -mg_coarse_ksp_type gmres \
                               -mg_levels_ksp_type gmres \
                               -mg_coarse_ksp_max_it 6 \
                               -mg_levels_ksp_max_it 3";

  PetscInitialize(&argc,&argv,PETSC_NULL,help);

  /* Hardwire several options; can be changed at command line */
  ierr = PetscOptionsInsertString(common_options);CHKERRQ(ierr);
  ierr = PetscOptionsInsertString(matrix_free_options);CHKERRQ(ierr);
  ierr = PetscOptionsInsert(&argc,&argv,PETSC_NULL);CHKERRQ(ierr); 

You don't need any if checks to see if something has already been set.

   Barry


On May 14, 2012, at 12:45 PM, Giacomo Mulas wrote:

> On Mon, 14 May 2012, Matthew Knepley wrote:
> 
>> The problems below are exactly why we do not advocate this strategy.
>> However, you
>> can get this effectusing http://www.mcs.anl.gov/petsc/petsc-dev/docs/manualpages/Sys/PetscOpti
>> onsSetValue.html
> 
> Thanks Matt!
> 
> Hmm, this would be more or less the same as adding the options to argc and
> argv before initialising slepc and petsc, I gather. Functional, even if not
> quite as clean as I would have liked. My idea was to set some working
> default in the code, but still honor command line options if different, whereas what you suggest overrides any conflicting command line options. Indeed, in my code I call EPSSetFromOptions() _after_ my explicit function
> calls, to make sure that command line options override my defaults (at
> least, that's my intended logic...).
> 
> Maybe I should first check for appropriate command line options, and then
> set them in the code _only if_ none were given on the command line?
> What about:
> 	  PetscInt ival;
> 	  PetscBool isset;
> 	  ierr = PetscOptionsGetInt(PETSC_NULL, "-mat_mumps_icntl_13",
> 	  &ival,
> 				    &isset);CHKERRQ(ierr);
> 	  if (isset==PETSC_FALSE) {
> 	    ierr = PetscOptionsSetValue("-mat_mumps_icntl_13","1");
> 	    CHKERRQ(ierr);
> 	  }
> 
> Does it look sensible?
> 
> Also, could you please specify a bit more what strategy you do not advocate,
> and for what problems? Do you mean setting up options by direct function
> calls, as opposed to setting them via PetscOptionsSetValue() ?
> Or do you mean it is deprecated to set options in the code in any way, be it
> via direct function calls or via PetscOptionsSetValue() ?
> 
> And the problems you are referring to are essentially the runtime error I
> get, i.e. calling functions in the wrong order? Or something else?
> 
> Finally, if I call EPSGetST(), should I then call STDestroy() on the ST I
> obtained, or will it be done by EPSDestroy()? And the same question iterates
> for the KSP I obtained via STGetKSP(), and the PC I obtained via KSPGetPC().
> 
> Thanks, bye
> Giacomo
> 
> -- 
> _________________________________________________________________
> 
> Giacomo Mulas <gmulas at oa-cagliari.inaf.it>
> _________________________________________________________________
> 
> OSSERVATORIO ASTRONOMICO DI CAGLIARI
> Str. 54, Loc. Poggio dei Pini * 09012 Capoterra (CA)
> 
> Tel. (OAC): +39 070 71180 248     Fax : +39 070 71180 222
> Tel. (UNICA): +39 070 675 4916
> _________________________________________________________________
> 
> "When the storms are raging around you, stay right where you are"
>                         (Freddy Mercury)
> _________________________________________________________________