[petsc-dev] How to get subsnes for subproblems based field decomposition
Barry Smith
bsmith at mcs.anl.gov
Fri Aug 19 14:13:22 CDT 2016
Toby,
Yes. We don't currently have a SNESFIELDSPLIT, someone could write such a beast.
Barry
> On Aug 19, 2016, at 1:56 PM, Tobin Isaac <tisaac at uchicago.edu> wrote:
>
> On Fri, Aug 19, 2016 at 01:01:35PM -0500, Barry Smith wrote:
>>
>>> On Aug 19, 2016, at 8:49 AM, Lulu Liu <lulu.liu at kaust.edu.sa> wrote:
>>>
>>> Hi,
>>>
>>> For example, I would like to solve the nonlinear driven cavity problem (ex19.c in SNES). There are four components: u,v, omega, T.
>>>
>>> I want to solve one equation at one time, is there any easier way to get subsnes (for subproblems) from original SNES.
>>
>> Here's the thing. If the example defines a single monolithic function that computes the unknowns entire function, in this example the function is called FormFunctionLocal() there there is no way for PETSc which is a library to "pull out of" that FormFunctionLocal() an function that computes say just the functions for u or v or omega or T. That would require compiler tools that understood the mathematics of the source code function written in C which is essentially impossible.
>>
>> The only hope to be able to build nonlinear solvers that work on "a component at a time" is if the user provides the unknowns mathematical function not as a single monolithic function but as a collection of functions one for each component. This is why there is no way to automatically generate the SubSNES's you desire. Note that for the linear case where a matrix is provided it is easy to pull out the sub-linear problems because they are just sub matrices of the original matrix.
>
> Couldn't the IS's that define the fields be used to create a
> restricted wrapper to the original SNES? i.e.
>
> 1. VecScatter X_field into X_monolithic (the (monolithic \ field) values of X_monolithic are fixed)
> 2. SNESComputeFunction(snes_monolithic,X_monolithic,Y_monolithic)
> 3. VecGather Y_monolithic into Y_field
>
> This is of course inefficient because we're throwing away most of the
> function evaluation Y_monolithic (and forming a Jacobian this way
> would be inefficient^2). But if you're just exploring whether it makes
> sense to use a component-wise solver, it's better than nothing. If it
> looks promising, the monolithic snes can be refactored as a system of
> subproblems.
>
> Toby
>
>>
>> Barry
>>
>>>
>>> Thanks!
>>>
>>>
>>> This message and its contents, including attachments are intended solely for the original recipient. If you are not the intended recipient or have received this message in error, please notify me immediately and delete this message from your computer system. Any unauthorized use or distribution is prohibited. Please consider the environment before printing this email.
More information about the petsc-dev
mailing list