[petsc-users] Wise usage of user contexts

[Matthew Knepley]

On Tue, Aug 18, 2015 at 4:20 AM, Timothée Nicolas <
timothee.nicolas at gmail.com> wrote:

> Dave,
>
> Thx a lot for your very clear answer. My last question about modules could
> be reformulated like this :
>
> Why would I put anything in a ctx while I could simply use modules ? Maybe
> it has something to do with the fact that PETSc is initially written for C ?
>

We think it makes the code more modular and easier to understand,
especially if many pieces are composed together. Global
variables have to be tracked down by someone looking at your code.

   Thanks,

     Matt


> Best
>
> Timothee
>
> 2015-08-18 17:59 GMT+09:00 Dave May <dave.mayhem23 at gmail.com>:
>
>>
>>
>> On 18 August 2015 at 10:42, Timothée Nicolas <timothee.nicolas at gmail.com>
>> wrote:
>>
>>> Hi all,
>>>
>>> I am in the process of writing an implicit solver for a set of PDEs
>>> (namely MHD equations), in FORTRAN. When setting the non-linear function to
>>> solve via Newton-Krylov, I use a "user defined context", namely the thing
>>> denoted by "ctx" on the doc page about SNESFunction :
>>>
>>>
>>> http://www.mcs.anl.gov/petsc/petsc-current/docs/manualpages/SNES/SNESFunction.html#SNESFunction
>>>
>>> In practice ctx is a user defined type which contains everything I need
>>> in the local routine which sets the function on the local part of the grid,
>>> FormFunctionLocal. That is, some local/global geometrical information on
>>> the grid, the physical parameter, and possibly any other thing.
>>>
>>> In my case it so happens that due to the scheme I have chosen, when I
>>> compute my function, I need the full solution of the problem at the last
>>> two time steps (which are in Vec format). So my ctx contains two Vec
>>> elements. Since I will work in 3D and intend to use a lot of points in the
>>> future, I am concerned about memory problems which could occur.
>>>
>>
>> In the grand scheme of things, the two vectors in your context aren't
>> likely to significantly add to the total memory footprint of your code. A
>> couple of things to note:
>> * If you run in parallel, only the local part of the vector will be
>> stored on each MPI process.
>> * All the KSP methods will allocate auxiliary vectors. Most methods
>> require more than 2 auxiliary vectors.
>> * SNES also requires auxiliary vectors. If you use JFNK, that method will
>> also need some additional temporary vectors.
>> * If you assemble a Jacobian, this matrix will likely require much more
>> memory per MPI process than two vectors
>>
>>
>>
>>> Is there a limit to the size occupied by ctx ?
>>>
>>
>> The only limit is defined by the available memory per MPI process you
>> have on your target machine.
>>
>>
>>> Would this be better if instead I was declaring global variables in a
>>> module and using this module inside FormFunctionLocal ? Is this allowed ?
>>>
>>
>> What would be the difference in doing that - the memory usage will be
>> identical.
>>
>> Cheers
>>   Dave
>>
>>
>>>
>>> Best regards
>>>
>>> Timothee NICOLAS
>>>
>>
>>
>


-- 
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-users/attachments/20150818/634ee9e1/attachment.html>