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