<div dir="ltr">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?<div class="gmail_extra">
<br><br><div class="gmail_quote">On Tue, Jan 15, 2013 at 2:31 PM, Barry Smith <span dir="ltr"><<a href="mailto:bsmith@mcs.anl.gov" target="_blank">bsmith@mcs.anl.gov</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
  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?<br>
<span class="HOEnZb"><font color="#888888"><br>
   Barry<br>
</font></span><div class="HOEnZb"><div class="h5"><br>
<br>
<br>
On Jan 15, 2013, at 2:14 PM, Jed Brown <<a href="mailto:jedbrown@mcs.anl.gov">jedbrown@mcs.anl.gov</a>> wrote:<br>
<br>
> On Tue, Jan 15, 2013 at 1:50 PM, Barry Smith <<a href="mailto:bsmith@mcs.anl.gov">bsmith@mcs.anl.gov</a>> wrote:<br>
><br>
>   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.<br>

><br>
>    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?<br>

><br>
> static struct {<br>
>   PetscMultiDispatch ptap;<br>
>   ...<br>
> } MatMultiDispatch;<br>
><br>
> I would have PetscMultiDispatchRegister("MatPtAP",2,&MatMultiDispatch.ptap), then<br>
><br>
> PetscMultiDispatchFind(MatMultiDispatch.ptap,(PetscObject)A,(PetscObject)P,&ptapfunc);<br>
><br>
> 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.<br>

><br>
><br>
>    Barry<br>
><br>
><br>
> PetscErrorCode  MatQueryOp(MPI_Comm comm, PetscVoidFunction* function, const char op[], PetscInt numArgs, ...)<br>
> {<br>
>   PetscErrorCode ierr;<br>
>   va_list        ap;<br>
>   PetscInt       i;<br>
>   const char     *argType;<br>
>   char           **argTypes = PETSC_NULL;<br>
><br>
>   PetscFunctionBegin;<br>
>   va_start(ap,numArgs);<br>
>   if (numArgs) {<br>
>     ierr = PetscMalloc(sizeof(char*)*numArgs, &argTypes);CHKERRQ(ierr);<br>
>   }<br>
>   for (i = 0; i < numArgs; ++i) {<br>
>     argType = va_arg(ap,const char*);<br>
>     ierr = PetscStrallocpy(argType, argTypes+i);CHKERRQ(ierr);<br>
>   }<br>
>   va_end(ap);<br>
>   ierr = PetscOpFListFind(comm, MatOpList, function, op, numArgs, argTypes);CHKERRQ(ierr);<br>
>   for (i = 0; i < numArgs; ++i) {<br>
>     ierr = PetscFree(argTypes[i]);CHKERRQ(ierr);<br>
>   }<br>
>   ierr = PetscFree(argTypes);CHKERRQ(ierr);<br>
>   PetscFunctionReturn(0);<br>
> }<br>
><br>
><br>
<br>
</div></div></blockquote></div><br></div></div>