Barry Smith <[email protected]> writes: >> What about -mg_levels_2_mat_view or -fieldsplit_pressure_mat_view? If >> the number of levels or the fieldsplit names are obtained automatically >> From the matrix, then the object cannot reasonably exist at >> PCSetFromOptions. Or is there a way? > > Ahh, but the XXX/PCSetFromOptions for the inner PC IS called after > the inner KSP/PC is created! Hence > -fieldsplit_pressure_factor_mat_view should work. Search for > KSPSetFromOptions() in field split.c and mg.c > > The key is that the calls to the inner XXXSetFromOptions() are not > nested in the calls to the outer XXSetFromOptions() (obviously > because the inner ones do not exist when the outer one is called).
Indeed, but I thought we wanted to avoid this because it can lead to options being checked on each iteration and it's crappy for interactive configuration. [Two examples that are hard] When you use GAMG, you don't know how many levels will exist until running with the matrix. Even the same nonzero pattern can create different numbers of levels due to thresholding. Also look where PCFieldSplitSetDefaults() is called from. The number of splits may not be known until PCSetUp_FieldSplit.
pgpFFj1Q4Zabv.pgp
Description: PGP signature
