I did indeed bypass them. Ok, thanks.
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 -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.mcs.anl.gov/pipermail/petsc-dev/attachments/20120615/cdd73976/attachment.html>
