[petsc-dev] Patch review

[Jed Brown]

On Tue, Aug 28, 2012 at 10:56 AM, Jie Chen <jiechen at mcs.anl.gov> wrote:

> Oh, in KSPSetTolerances(), the outer_rtol should be the inner_rtol
> instead... Could you push a fix for me please?
>

http://petsc.cs.iit.edu/petsc/petsc-dev/rev/1b7eeaed2630


>
> Jie
>
>
>
> ----- Original Message -----
> From: "Jed Brown" <jedbrown at mcs.anl.gov>
> To: "Jie Chen" <jiechen at mcs.anl.gov>
> Cc: "For users of the development version of PETSc" <petsc-dev at mcs.anl.gov>,
> "Hong Zhang" <hzhang at mcs.anl.gov>
> Sent: Tuesday, August 28, 2012 10:23:00 AM
> Subject: Re: Patch review
>
> I just pushed some fixes for compilation in complex mode
>
> http://petsc.cs.iit.edu/petsc/petsc-dev/rev/49030d6e26f7
>
> In the following code, surely you intended to pass inner_rtol to
> KSPSetTolerances()?
>
>
> PetscErrorCode KSPMonitorDynamicTolerance(KSP ksp,PetscInt its,PetscReal
> fnorm,void *dummy) {
> PetscErrorCode ierr;
> PetscReal *coef = (PetscReal*)dummy;
> PC pcksp;
> KSP kspinner;
> PetscReal outer_rtol, outer_abstol, outer_dtol, inner_rtol;
> PetscInt outer_maxits;
> PetscFunctionBegin;
> ierr = KSPGetPC(ksp,&pcksp);CHKERRQ(ierr);
> kspinner = NULL;
> ierr = PCKSPGetKSP(pcksp,&kspinner);CHKERRQ(ierr);
> if (kspinner) {
> ierr = KSPGetTolerances(ksp, &outer_rtol, &outer_abstol, &outer_dtol,
> &outer_maxits);CHKERRQ(ierr);
> inner_rtol = (*coef) * outer_rtol / fnorm;
> ierr = KSPSetTolerances(kspinner, outer_rtol, outer_abstol, outer_dtol,
> outer_maxits);CHKERRQ(ierr);
> }
> PetscFunctionReturn(0);
> }
>
>
>
> On Fri, Aug 24, 2012 at 6:44 PM, Jed Brown < jedbrown at mcs.anl.gov > wrote:
>
>
>
>
> On Fri, Aug 24, 2012 at 6:38 PM, Jie Chen < jiechen at mcs.anl.gov > wrote:
>
>
> 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.
>
> 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.
>
>
>
> 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.)
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mcs.anl.gov/pipermail/petsc-dev/attachments/20120828/0df765f2/attachment.html>