[petsc-dev] SNESLineSearchApply_BT logic divergence

[Matthew Knepley]

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>