[petsc-users] Wise usage of user contexts

[Barry Smith]

> On 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 ?

   You could.  The disadvantage of modules, which may not matter in your case, is that there can only ever be ONE data structure that contains all this information and can be used in your form functions. If you use a derived data type you can have multiple different ones of these data structures in the same code. Say for example, you had two different sets of physical parameters and you wanted to solve in your program both problems, you would just a derived type designed to hold this information and put each set of parameters into a different derived type object. With a module there could only be one set of parameters so you would have to do some horrible thing like constantly be changing the values in the model back and forth between the two sets.

> Maybe it has something to do with the fact that PETSc is initially written for C ?

  Modules are kind of like singletons in object oriented programming. They are occasionally useful but limiting yourself to ONLY having singletons in object oriented programs is nuts.

  Barry

> 
> 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
> 
>