On Sat, Jun 16, 2012 at 12:10 AM, Daniel Lowell <redratio1 at gmail.com> wrote:
> Are there any other values cached by the vector? > It does not matter how much stuff is cached. What matters is the state: http://www.mcs.anl.gov/petsc/petsc-current/docs/manualpages/Sys/PetscObjectStateIncrease.html Matt > On Fri, Jun 15, 2012 at 11:06 AM, Matthew Knepley <knepley at gmail.com>wrote: > >> On Sat, Jun 16, 2012 at 12:03 AM, Daniel Lowell <redratio1 at >> gmail.com>wrote: >> >>> Hey Satish, >>> >>> So I'm having an issue with this function: >>> >>> *#define PetscObjectComposedDataGetReal >>> <http://www.mcs.anl.gov/petsc/petsc-current/include/petsc-private/docs/manualpages/Sys/PetscObjectComposedDataGetReal.html#PetscObjectComposedDataGetReal>(obj,id,data,flag) >>> \**((((obj)->realcomposedstate && >>> ((obj)->realcomposedstate[id] == (obj)->state))? \**(data = >>> (obj)->realcomposeddata[id],flag = PETSC_TRUE >>> <http://www.mcs.anl.gov/petsc/petsc-current/include/petsc-private/docs/manualpages/Sys/PETSC_TRUE.html#PETSC_TRUE>) >>> : (flag = PETSC_FALSE >>> <http://www.mcs.anl.gov/petsc/petsc-current/include/petsc-private/docs/manualpages/Sys/PETSC_FALSE.html#PETSC_FALSE>)),0)* >>> >>> >>> Called from VecNorm which is called from SNESLineSearchApply_BT >>> >>> I have two examples running one is the vanilla ex14 using my GPU vector >>> and matrix type. The other example is a variant of ex14test where I am >>> implementing GPU formfunction and formjacobian. >>> ex14 vanilla runs through correctly, however ex14test diverges in the >>> logic within VecNorm, specifically line 164: >>> /* >>> * Cached data? >>> */ >>> if (type!=NORM_1_AND_2) { >>> ierr = PetscObjectComposedDataGetReal >>> ((PetscObject)x,NormIds[type],*val,flg);CHKERRQ(ierr); >>> if (flg) PetscFunctionReturn(0); >>> } >>> >>> The ex14 detects there is a "real" part, however the ex14test does not >>> and VecNorm returns. >>> >>> "val" in VecNorm is PetscReal gnorm = fnorm defined in >>> SNESLineSearchApply_BT. >>> For ex14: val[0]=3.44e-317, val[1]: 0.580 >>> For ex14test: val[0]=3.44e-317, val[1]: 0.029 >>> >>> >>> This difference makes SNESLineSearchApply_BT branch into different >>> execution paths. >>> >>> I'm not sure where the issue could have come from. Any ideas? >>> >> >> If you change values in a Vec, you must increment the internal state, >> since we cache norms. >> The internal functions for array getting do this automatically, so I am >> not sure why this is >> messing up. Did you bypass them? >> >> Matt >> >> >>> >>> -- >>> Daniel Lowell >>> >>> >> >> >> -- >> What most experimenters take for granted before they begin their >> experiments is infinitely more interesting than any results to which their >> experiments lead. >> -- Norbert Wiener >> > > > > -- > Daniel Lowell > > -- What most experimenters take for granted before they begin their experiments is infinitely more interesting than any results to which their experiments lead. -- Norbert Wiener -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.mcs.anl.gov/pipermail/petsc-dev/attachments/20120616/1240c65c/attachment.html>
