I just pushed some fixes for compilation in complex mode<br><br><a href="http://petsc.cs.iit.edu/petsc/petsc-dev/rev/49030d6e26f7">http://petsc.cs.iit.edu/petsc/petsc-dev/rev/49030d6e26f7</a><br><br>In the following code, surely you intended to pass inner_rtol to KSPSetTolerances()?<br>
<br><div>PetscErrorCode KSPMonitorDynamicTolerance(KSP ksp,PetscInt its,PetscReal fnorm,void *dummy) {</div><div>  PetscErrorCode ierr;</div><div>  PetscReal *coef = (PetscReal*)dummy;</div><div>  PC pcksp;</div><div>  KSP kspinner;</div>
<div>  PetscReal outer_rtol, outer_abstol, outer_dtol, inner_rtol;</div><div>  PetscInt outer_maxits;</div><div>  PetscFunctionBegin;</div><div>  ierr = KSPGetPC(ksp,&pcksp);CHKERRQ(ierr);</div><div>  kspinner = NULL;</div>
<div>  ierr = PCKSPGetKSP(pcksp,&kspinner);CHKERRQ(ierr);</div><div>  if (kspinner) {</div><div>    ierr = KSPGetTolerances(ksp, &outer_rtol, &outer_abstol, &outer_dtol, &outer_maxits);CHKERRQ(ierr);</div>
<div>    inner_rtol = (*coef) * outer_rtol / fnorm;</div><div>    ierr = KSPSetTolerances(kspinner, outer_rtol, outer_abstol, outer_dtol, outer_maxits);CHKERRQ(ierr);</div><div>  }</div><div>  PetscFunctionReturn(0);</div>
<div>}</div><div><br></div><br><div class="gmail_quote">On Fri, Aug 24, 2012 at 6:44 PM, Jed Brown <span dir="ltr"><<a href="mailto:jedbrown@mcs.anl.gov" target="_blank">jedbrown@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">
<div class="im"><div class="gmail_quote">On Fri, Aug 24, 2012 at 6:38 PM, Jie Chen <span dir="ltr"><<a href="mailto:jiechen@mcs.anl.gov" target="_blank">jiechen@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">

I am in fact somewhat reluctant to push out everything before it is formally published and fully tested. The patch consists of more than one algorithmic developments that may be far away from maturity (but they are likely to work), though the authors might be the only ones who care about the new algorithms at this point. Besides, the codes are now full of hacks and lack documentation. I have no problem reverting petsc to the old version temporarily, and I promise I will clean everything to meet the production requirement, although this might not happen in a very short time. Meanwhile I think it also does not hurt to keep the patch as is, as the modification is likely to be used by the author circle only.</blockquote>

</div><br></div><div>There isn't a problem with experimental code, but if you are going to push experimental code, it should conform to the usual standards. No need to revert the patch unless you've already decided it is a failed experiment.<br>

</div><div><br></div><div>If something is genuinely useful, we certainly like to have it in our bag of tricks immediately. Waiting until a paper is published to put it in the repo just means that it will take longer to find use in real applications. As far as I'm concerned, an ideal scenario is that by the time someone reads the paper, they already have the functionality in a released version of PETSc, thus can experiment on their own problems without even recompiling. (This being the lowest possible effort, it maximizes the chances of finding other applications where the method is useful, thus maximizing citations, in case that is the metric you care about.)</div>

</blockquote></div><br>