<div dir="ltr">On Wed, Feb 6, 2013 at 11:43 PM, Jed Brown <span dir="ltr"><<a href="mailto:jedbrown@mcs.anl.gov" target="_blank">jedbrown@mcs.anl.gov</a>></span> wrote:<br><div class="gmail_extra"><div class="gmail_quote">
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><div class="h5">On Wed, Feb 6, 2013 at 9:43 PM, Matthew Knepley <span dir="ltr"><<a href="mailto:knepley@gmail.com" target="_blank">knepley@gmail.com</a>></span> wrote:<br>
</div></div><div class="gmail_extra"><div class="gmail_quote"><div><div class="h5">
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><div>On Wed, Feb 6, 2013 at 8:45 PM, Barry Smith <span dir="ltr"><<a href="mailto:bsmith@mcs.anl.gov" target="_blank">bsmith@mcs.anl.gov</a>></span> wrote:<br>

</div></div><div class="gmail_extra"><div class="gmail_quote"><div><div>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
  PETSc is littered with<br>
<br>
  if (A->factortype == MAT_FACTOR_LU) {<br>
#if defined(PETSC_MISSING_LAPACK_GETRS)<br>
    SETERRQ(PETSC_COMM_SELF,PETSC_ERR_SUP,"GETRS - Lapack routine is unavailable.");<br>
#else<br>
    PetscStackCall("LAPACKgetrs",LAPACKgetrs_("N",&m,&nrhs,mat->v,&mat->lda,mat->pivots,x,&m,&info));<br>
    if (info) SETERRQ(PETSC_COMM_SELF,PETSC_ERR_LIB,"GETRS - Bad solve");<br>
#endif<br>
  } else if (A->factortype == MAT_FACTOR_CHOLESKY) {<br>
#if defined(PETSC_MISSING_LAPACK_POTRS)<br>
    SETERRQ(PETSC_COMM_SELF,PETSC_ERR_SUP,"POTRS - Lapack routine is unavailable.");<br>
#else<br>
    PetscStackCall("LAPACKpotrs",LAPACKpotrs_("L",&m,&nrhs,mat->v,&mat->lda,x,&m,&info));<br>
    if (info) SETERRQ(PETSC_COMM_SELF,PETSC_ERR_LIB,"POTRS Bad solve");<br>
#endif<br>
<br>
<br>
due to missing LAPACK routines.   I propose for each missing routine we provide a dummy routine that calls SETERRQ() with the PETSC_ERR_SUP error and returns a "special" error code in the info arg. This way we can have pretty (CPPless :-) code like<br>



<br>
  if (A->factortype == MAT_FACTOR_LU) {<br>
    PetscStackCall("LAPACKgetrs",LAPACKgetrs_("N",&m,&nrhs,mat->v,&mat->lda,mat->pivots,x,&m,&info));<br>
    if (info) SETERRQ(PETSC_COMM_SELF,PETSC_ERR_LIB,"GETRS - Bad solve");<br>
  } else if (A->factortype == MAT_FACTOR_CHOLESKY) {<br>
    PetscStackCall("LAPACKpotrs",LAPACKpotrs_("L",&m,&nrhs,mat->v,&mat->lda,x,&m,&info));<br>
    if (info) SETERRQ(PETSC_COMM_SELF,PETSC_ERR_LIB,"POTRS Bad solve");<br>
  }<br>
<br>
  Does anyone see a problem with doing this?</blockquote><div><br></div></div></div><div>I like that . Configure can auto-generate those in the header.</div></div></div></div></blockquote><div><br></div></div></div><div>
Wouldn't this be easier to add to petscblaslapack.h?</div>
<div><br></div><div>I think that having significant code in petscconf.h is a bad thing for maintainability.</div></div></div></div>
</blockquote></div><br>I think we have to make a distinction as to what kind of code is in there. The proposed</div><div class="gmail_extra">stub does nothing but raise an error, just as Fortran stubs do nothing but forward the call.</div>
<div class="gmail_extra">To me, this should be kept out of petscblaslapack.h.</div><div class="gmail_extra"><br></div><div class="gmail_extra">    Matt<br clear="all"><div><br></div>-- <br>What most experimenters take for granted before they begin their experiments is infinitely more interesting than any results to which their experiments lead.<br>
-- Norbert Wiener
</div></div>