SNESSetUp() and matrix-free options

[Barry Smith]

On Jul 21, 2009, at 8:19 PM, Lisandro Dalcin wrote:

> On Tue, Jul 21, 2009 at 6:20 PM, Barry Smith<bsmith at mcs.anl.gov>  
> wrote:
>>
>> On Jul 21, 2009, at 3:03 PM, Lisandro Dalcin wrote:
>>
>>> First of all, I'm very sorry about this... I just didn't noticed...
>>> How can I have access to the nightly tests?
>>
>>   I use "make alltests" on my machine after I make a big change  
>> (actually I
>> am a bad boy and don't do this as much as I should), this would  
>> have found
>> the problem for you.
>>
>
> Yes, I know... I DO make test before pushing... But it seems this time
> I got confused (probably ran make test in other source tree), and
> end-up pushing code that I did not actually test...

    Don't worry about it,. I get angry about everything all the time  
so it is no big deal. Better to
push something broken then never to push anything :-)
>
>>   Regarding the nightly tests, maybe this will get Satish to get  
>> his butt in
>> gear and switch to buildbot. Currently I think they are dumped on  
>> some ANL
>> machine and you cannot access them.
>>
>
> So you have to manually log-in to the ANL machine and look for the
> output? No automatic mailing of the output log?

    Yes, embarressing. This is why I've been hassling Satish about it  
for a long time.
>
>>> - we should discuss deeper this whole stuff of having
>>> SetFromOptions()/SetUp()/Solve() calls in KSP/SNES/TS; define the
>>> rules, and review and fix any place that does not follow the rules.
>>
>>   It may simply be impossible to get the model fully consistent  
>> with all the
>> features we want.
>>
>
> Can we at least agree on the simple rules below:
>
> 1) KSPSetFromOptions() requires a previous call to KSPSetOperators()
>
> 2) SNESSetFromOptions() requires a previous call to:
>   a) SNESSetFunction(), and also SNESSetJacobian() unless matrix- 
> free is used.
>   b) just SNESSetJacobian() if the problem is actually linear (a case
> that SNESComputeFunction() seems to handle)
>
> 3) TSSetFromOptions() should have similar requirements in order to
> being able to satisfy (1) or (2) depending on the problem type.
>
> Barry, does all this make sense?

   Sometimes, so what went wrong with the broken TS example and can it  
fit in this paradgm?

    This is tough when there are nested sub KSP inside PCs and picking  
these is done at
the command line.

   Barry

>
>
>>>
>>> On Tue, Jul 21, 2009 at 1:09 PM, Barry Smith<bsmith at mcs.anl.gov>  
>>> wrote:
>>>>
>>>>   Your moving of the -snes_mf options to SNESSetFromOptions() has  
>>>> broken
>>>> PETSc.
>>>>
>>>
>>>
>>>
>>>> [bsmith-laptop:ts/examples/tests] barrysmith% make runex4_2
>>>> Possible problem with ex4_2, diffs above
>>>>
>>>>  Please fix!
>>>>
>>>
>>> Done. Comments below...
>>>
>>>> This has been broken for a long time and broken things mean no
>>>> one checks the nightly builds which means more and more things  
>>>> break.
>>>>
>>>
>>> Too bad. I ask again: How can I access the nightly builds? Take for
>>> sure that If I would have access to such results, I would fix my
>>> faults almost immediately... I just did not know about this  
>>> situation
>>> (BTW, many thanks).
>>>
>>>> In SNESSetFromOptions() you have
>>>>
>>>>
>>>>  if (mf) { ierr = SNESSetUpMatrixFree_Private(snes, mf_operator,
>>>> mf_version);CHKERRQ(ierr); }
>>>>
>>>> as my email says in May this is a problem. I think the easiest  
>>>> fix is to
>>>> save the mf flags in the SNES data structure and call
>>>> SNESSetUpMatrixFree_Private()
>>>> as it use to be called in SNESSetUp(). Perhaps there is a problem  
>>>> with
>>>> that
>>>> fix I do not know about.
>>>>
>>>
>>> Well Barry, the way you are suggesting is not going to actually 100%
>>> fix things, but just mask other broken parts... Let me elaborate:
>>>
>>> - SNESSetFromOptions() calls KSPSetFromOptions()
>>> - but before calling KSPSetFromOptions(), you sould call
>>> KSPSetOperators() (in order to let KSP pick good defaults)
>>> - then we should build the MFFD Jacobian at SNESSetFromOptions()...
>>>
>>> Do you agree with my rationale?
>>>
>>> So I pushed a quick fix that makes the TS tests pass, but IMHO you
>>> should follow one of:
>>>
>>> - "hg backout" my commits (first "b17fe4b08207" and next
>>> "6fcd5defc59c"), and forget about the whole thing.
>>>
>>> - we should discuss deeper this whole stuff of having
>>> SetFromOptions()/SetUp()/Solve() calls in KSP/SNES/TS; define the
>>> rules, and review and fix any place that does not follow the rules.
>>>
>>>
>>>
>>>>
>>>> Begin forwarded message:
>>>>
>>>>> From: Barry Smith <bsmith at mcs.anl.gov>
>>>>> Date: May 6, 2009 3:25:43 PM CDT
>>>>> To: For users of the development version of PETSc
>>>>> <petsc-dev at mcs.anl.gov>
>>>>> Subject: Re: SNESSetUp() and matrix-free options
>>>>>
>>>>>
>>>>>  Lisandro,
>>>>>
>>>>>   The checking of the options can be moved to  
>>>>> SNESSetFromOptions() that
>>>>> then set some flag in the snes object;
>>>>> but the actual action of MatCreateSNESMF() etc must continue to  
>>>>> take
>>>>> place
>>>>> in the setup.
>>>>>
>>>>>  Feel free to change if you like,
>>>>>
>>>>>  Barry
>>>>>
>>>>>
>>>>> On May 6, 2009, at 3:15 PM, Lisandro Dalcin wrote:
>>>>>
>>>>>> Currently, -snes_mf* options are handled in SNESSetUp()... I  
>>>>>> think all
>>>>>> you will agree that the proper place for them is
>>>>>> SNESSetFromOptions()... However, perhaps I'm missing something  
>>>>>> and
>>>>>> things are like that for some reason... In that case I would  
>>>>>> like to
>>>>>> know the reason and perhaps I could fix this...
>>>>>>
>>>>>> --
>>>>>> Lisandro Dalcín
>>>>>> ---------------
>>>>>> Centro Internacional de Métodos Computacionales en Ingeniería  
>>>>>> (CIMEC)
>>>>>> Instituto de Desarrollo Tecnológico para la Industria Química  
>>>>>> (INTEC)
>>>>>> Consejo Nacional de Investigaciones Científicas y Técnicas  
>>>>>> (CONICET)
>>>>>> PTLC - Güemes 3450, (3000) Santa Fe, Argentina
>>>>>> Tel/Fax: +54-(0)342-451.1594
>>>>>
>>>>
>>>>
>>>
>>>
>>>
>>> --
>>> Lisandro Dalcín
>>> ---------------
>>> Centro Internacional de Métodos Computacionales en Ingeniería  
>>> (CIMEC)
>>> Instituto de Desarrollo Tecnológico para la Industria Química  
>>> (INTEC)
>>> Consejo Nacional de Investigaciones Científicas y Técnicas (CONICET)
>>> PTLC - Güemes 3450, (3000) Santa Fe, Argentina
>>> Tel/Fax: +54-(0)342-451.1594
>>
>>
>
>
>
> -- 
> Lisandro Dalcín
> ---------------
> Centro Internacional de Métodos Computacionales en Ingeniería (CIMEC)
> Instituto de Desarrollo Tecnológico para la Industria Química (INTEC)
> Consejo Nacional de Investigaciones Científicas y Técnicas (CONICET)
> PTLC - Güemes 3450, (3000) Santa Fe, Argentina
> Tel/Fax: +54-(0)342-451.1594