[petsc-dev] multiple dispatch code currently in PETSc

Jed Brown jedbrown at mcs.anl.gov
Tue Jan 15 14:45:19 CST 2013


I think it's relevant for ODE problems (and general applicability of PETSc
to very small problem sizes). I don't think it's urgent and I'd rather work
on multigrid in the next few days. I'd say put it on the website at
somewhat higher priority. Is it more important than MatColoring and
MatOrdering objects?


On Tue, Jan 15, 2013 at 2:31 PM, Barry Smith <bsmith at mcs.anl.gov> wrote:

>
>   So who wrote the PetscOpFList() code and who will refactor it?  Is this
> a high priority or just something to be listed on that website and then
> ignored for years?
>
>    Barry
>
>
>
> On Jan 15, 2013, at 2:14 PM, Jed Brown <jedbrown at mcs.anl.gov> wrote:
>
> > On Tue, Jan 15, 2013 at 1:50 PM, Barry Smith <bsmith at mcs.anl.gov> wrote:
> >
> >   Do we really want mallocs for EVERY single multiple-dispatch function
> call in PETSc? I suggest not having MatQueryOp() but calling directly
> PetscOpFListFind() (with the MatOpFList argument) and changing
> PetscOpFListAdd/Find() to use variable args directly.
> >
> >    Finally do we really want string comparisons at all here? Or do we
> want XXXRegister() (for example, MatRegister()) to compute an integer type
> id to go with each char *type_name and do the search off the integer type
> id instead of strings? Thus making PetscOpFListFind() super light weight?
> >
> > static struct {
> >   PetscMultiDispatch ptap;
> >   ...
> > } MatMultiDispatch;
> >
> > I would have
> PetscMultiDispatchRegister("MatPtAP",2,&MatMultiDispatch.ptap), then
> >
> >
> PetscMultiDispatchFind(MatMultiDispatch.ptap,(PetscObject)A,(PetscObject)P,&ptapfunc);
> >
> > I think passing PetscObject is natural here, in which case using
> obj->type_id instead of obj->type_name can be done later. But on that
> front, yes, I think making integers for all registered type_names would be
> good. Among other things, it would make the PetscObjectTypeCompares fast,
> although I think those places should eventually be refactored.
> >
> >
> >    Barry
> >
> >
> > PetscErrorCode  MatQueryOp(MPI_Comm comm, PetscVoidFunction* function,
> const char op[], PetscInt numArgs, ...)
> > {
> >   PetscErrorCode ierr;
> >   va_list        ap;
> >   PetscInt       i;
> >   const char     *argType;
> >   char           **argTypes = PETSC_NULL;
> >
> >   PetscFunctionBegin;
> >   va_start(ap,numArgs);
> >   if (numArgs) {
> >     ierr = PetscMalloc(sizeof(char*)*numArgs, &argTypes);CHKERRQ(ierr);
> >   }
> >   for (i = 0; i < numArgs; ++i) {
> >     argType = va_arg(ap,const char*);
> >     ierr = PetscStrallocpy(argType, argTypes+i);CHKERRQ(ierr);
> >   }
> >   va_end(ap);
> >   ierr = PetscOpFListFind(comm, MatOpList, function, op, numArgs,
> argTypes);CHKERRQ(ierr);
> >   for (i = 0; i < numArgs; ++i) {
> >     ierr = PetscFree(argTypes[i]);CHKERRQ(ierr);
> >   }
> >   ierr = PetscFree(argTypes);CHKERRQ(ierr);
> >   PetscFunctionReturn(0);
> > }
> >
> >
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mcs.anl.gov/pipermail/petsc-dev/attachments/20130115/1c7b96ed/attachment.html>


More information about the petsc-dev mailing list