[petsc-dev] SNESLineSearchApply_BT logic divergence

[Daniel Lowell]

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?


-- 
Daniel Lowell
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mcs.anl.gov/pipermail/petsc-dev/attachments/20120615/3045f419/attachment.html>