On May 12, 2010, at 12:19 PM, Jed Brown wrote: > On Wed, 12 May 2010 13:27:18 -0300, Lisandro Dalcin > <dalcinl at gmail.com> wrote: >> Chris is going to use this from Python, and I have to add support in >> petsc4py. I think I'll have to provide a better API, something like: >> >> pc.fieldSplitSetFields(0,[1,2,3],4) # (rho,[Ux,Uy,Uz],p) >> >> or >> >> pc.fieldSplitSetIS(is_rho, is_U, is_p) >> >> and implement then by calling PCFieldSplitSet{Fields|IS} multiple >> times. >> >> Does this API make sense? > > Let's think about improving the C interface. I would really like to > name the splits since otherwise options sitting in petscrc files don't > compose. So what about > > PCFieldSplitSetFields(PC,const char name[],PetscInt > nfields,PetscInt fields[]); > PCFieldSplitSetFieldsByName(PC,const char name[],PetscInt > nfields,const char *fieldnames[]); > PCFieldSplitSetIS(PC,const char name[],IS); > > and on the Python end, the direct wrappers could be called multiple > times to set individual splits (if you provided direct wrappers) or > have > the higher level interface using a dict > > pc.FieldSplitSetSplits(splits) > > with any of the definitions > > splits = dict(velocity=isvelocity, pressure=ispressure)) > splits = dict(velocity=(0,1,2), pressure=(3,)) > splits = dict(velocity=('u','v','w'), pressure='p') > > The latter would only work if the user used DMSetFieldName to identify > fields u,v,w,p (recall that PC has access to the DM in -dev). With > any > of the definitions above, the runtime prefixes would be > -fieldsplit_velocity_* and -fieldsplit_pressure_* instead of just > numbers. > > Does this seem sensible? > > Jed
That makes sense to me. I'm all for naming the fields, and the dictionary representation in python is very intuitive. Chris