PETSc options treatment

[jkozdon]

The way the library is currently written the PETSc options are not universally set, but turned on and off for different operations.

I don't know enough about PETSc, but is this a good design decision? Is it possible that the options won't carry through properly when we need them?

For example

PETSc.jl/src/snes.jl

Lines 48 to 62 in 38552ba

	function SNES{$PetscScalar}(comm::MPI.Comm; kwargs...)
	@assert initialized($petsclib)
	opts = Options($petsclib, kwargs...)
	snes = SNES{$PetscScalar, $PetscLib}(C_NULL, opts, nothing, nothing, nothing, nothing, nothing)
	@chk ccall((:SNESCreate, $libpetsc), PetscErrorCode, (MPI.MPI_Comm, Ptr{CSNES}), comm, snes)
	with(snes.opts) do
	setfromoptions!(snes)
	end
	if comm == MPI.COMM_SELF
	finalizer(destroy, snes)
	end
	return snes
	end

Is this mainly needed when things are created?

@boriskaus or @psanan you have any thoughts?

My inclination right now is to leave it as is, but wanted to start a discussion in case this became important or a problem.

[boriskaus]

I think this is consistent with the way it is usually done in PETSc. There is a general options database to which command-line options are added. If you want specific options for a KSP or SNES object, you need to activate that for this option. What is important to have in practice is the ability to add a prefix for a certain KSP; this way you can set different solvers for different equations (e.g., direct solvers for temperature diffusion and multigrid solvers for Stokes).

[psanan]

Right - the "options database" is a key-value store which is used to set up solvers, as @boriskaus says, and can also be directly used by the user if they want to define their own command line options. In normal usage there is a single (formerly global) options database that's used for everything, but there can be multiple ones.