Thanks. 
KSPSetOperators() allows to precondition A^h with M^h. This is lovely and great 
as it allows to implement the shifted Laplace preconditioner for the Helmholtz 
equation. 
Recently I managed to implement shifted Laplace using the DMDA infrastructure 
in 2D. This implementation avoids having to construct the hierarchy in Matlab 
as we did previously. 
In next stage we would like to precondition A^H with M^H on a sequence of 
coarser grids. This is what Calandra does on two levels and what we doon 
multiple levels. 
We currently have an implement in which we construct the hierarchy on A^h and 
M^h in Matlab, we read the hierarchy in PETSc, traverse the hierarchy and do 
SetOperators and do a lot more of dark magic and witch craft by combining 
preconditioners in a additive and multiplicative fashion. 
It would be lovely to obtain a more readable piece of code.    
I am not sure what kind of additional callbacks I need. My first guess here 
would be a multilevel extension of SetOperators allowing to define M^H a 
preconditioner for A^H on a sequence of coarser levels. But I currently fail to 
oversee the whole matter. 
An alternative is to build a fragile code on top of DMDA first and get back to 
you with more informed guesses on what kind of call backs I precisely need. I 
think I prefer to go with this option. 
Does this sound reasonable? 
Domenico. 


      From: Barry Smith <[email protected]>
 To: domenico lahaye <[email protected]> 
Cc: PETSc Users List <[email protected]>
 Sent: Thursday, July 21, 2016 5:49 AM
 Subject: Re: [petsc-users] Regarding ksp ex42 - Citations
   

> On Jul 18, 2016, at 1:41 AM, domenico lahaye <[email protected]> 
> wrote:
> 
> Dear Matthew, 
> 
>  I would like to place the FormJacobian statement in ex25.c in such a way 
>that I can view 
> the result on the different levels. Can you please point me to an example? 
> 
>  I would like to do above with Galerkin coarsening as well. So yes, I do 
>expect that I will need the 
> hooks attached to the different MG levels. I appreciate more pointers here as 
> well. 

  The thing is some parts of the solver may not be constructed on each level 
until the actual solve is performed so it may not be possible to view/change 
things before the solve starts. You can try calling KSPSetUp() and then do as 
Matt suggested

"You can always call

  
http://www.mcs.anl.gov/petsc/petsc-current/docs/manualpages/PC/PCMGGetSmoother.html

and then

  http://www.mcs.anl.gov/petsc/petsc-current/docs/manualpages/KSP/KSPGetPC.html

and then

  
http://www.mcs.anl.gov/petsc/petsc-current/docs/manualpages/PC/PCGetOperators.html

I would caution you against this, since it is very fragile in the code."

  When using SNES there is really no good time to call KSPSetUp() and then 
access the PCMGGetSmoother(). This is why PETSc is designed around callbacks, 
so rather than having you look over MG levels and get some object and modify 
it, you provide callbacks that SNES or KSP calls at the appropriate time with a 
single object and then your callback function does what you want it to do. If 
there are additional callbacks you think we should add please let us know.

  Barry




> 

>    Thanks, Domenico.  
> 
> 
> From: Matthew Knepley <[email protected]>
> 
> 
> To: domenico lahaye <[email protected]> 
> Cc: PETSc Users List <[email protected]>
> Sent: Monday, July 18, 2016 8:16 AM
> Subject: Re: [petsc-users] Regarding ksp ex42 - Citations
> 
> On Mon, Jul 18, 2016 at 12:59 AM, domenico lahaye <[email protected]> 
> wrote:
> Thanks for all the pointers. 
> 
> I am happy to switch to ksp/examples/tutorials/ex25.c in a first instance as 
> you suggest.
> 
>    I am still stuck with the same issue as before though. I am trying to 
>extract the hierarchy 
>    of coarser grid matrices and the intergrid transfer operators from the 
>DMDA data structure. I would 
>    like to modify these operators and define a multigrid cycle with the 
>modified operators. 
> 
>    Given A^h (Helmholtz) and M^h (shifted Laplace), I would like to define a 
>multigrid cycle involving 
>    both A^H and M^H. Can I rely on the multilevel DMDA structure to construct 
>A^H and M^H for me 
>    in a set-up phase, plug them into a user-defined context, and plug them 
>back out in a solve phase? 
> 
> If you are not using -pc_mg_galerkin, then the FormJacobian is called 
> separately on each level to rediscretize the operator.
> The only thing that changes is the DMDA that is passed to the call. If you 
> need more information, there are hooks to
> attach different contexts to each MG level. Do you need this?
> 
>  Thanks,
> 
>      Matt
>  
> Thanks, Domenico. 
> 
> 
> From: Matthew Knepley <[email protected]>
> To: Barry Smith <[email protected]> 
> Cc: domenico lahaye <[email protected]>; "[email protected]" 
> <[email protected]>
> Sent: Sunday, July 17, 2016 2:29 PM
> Subject: Re: [petsc-users] Regarding ksp ex42 - Citations
> 
> On Sat, Jul 16, 2016 at 10:11 PM, Barry Smith <[email protected]> wrote:
> 
> > On Jul 14, 2016, at 12:21 PM, domenico lahaye <[email protected]> 
> > wrote:
> >
> > Dear PETSc team,
> >
> > 1) I am looking into ks/examples/tutorials/ex42.c I am still new to the 
> > DMDA structure
> >    and likely not giving it as much time as it deserves. However, I do not 
> >see immediately
> >    what function is responsible for calling PCMGSetSmoother and 
> >PCMGSetResidual.
> >
> >      I tried to call PCMGGetCoarseSolve(pc, &kcpc) and subsequently
> >      KSPGetOperators (kspc, ... ) to check how the coarse grid operator is 
> >defined
> >      after calling DMCoarsenHierarchy, but that failed.
> >
> >      I am solving Helmholtz with shifted Laplace, and managed to exploit 
> >DMDA to perform
> >      a multigrid solve on the preconditioner. In a next stage I want to 
> >implement the deflation
> >      using DMDA as well.
> >
> > 2) On http://www.mcs.anl.gov/petsc/documentation/referencing.html I see
> >
> > @Misc{petsc-web-page,
> >            author = {Satish Balay and Shrirang Abhyankar and Mark~F. Adams 
> >and Jed Brown and Peter Brune
> >                      and Kris Buschelman and Lisandro Dalcin and Victor 
> >Eijkhout and William~D. Gropp
> >                      and Dinesh Kaushik and Matthew~G. Knepley
> >                      and Lois Curfman McInnes and Karl Rupp and Barry~F. 
> >Smith
> >                      and Stefano Zampini and Hong Zhang and Hong Zhang},
> >            title =  {{PETS}c {W}eb page},
> >            url =    {http://www.mcs.anl.gov/petsc},
> >            howpublished = {\url{http://www.mcs.anl.gov/petsc}},
> >            year = {2016}
> >          }
> >
> >
> >
> > Is the last author mentioned twice intentionally?
> >
> > 3) On 
> > http://www.mcs.anl.gov/petsc/publications/petscapps-bib.html#OpenFOAM%202.2.1
> >  I see
> >
> > @misc{OpenFOAM
> > ,
> >
> >
> > title =      "OpenFOAM",
> >
> > howpublished  =      "\url{http://www.openfoam.com}";,
> >
> > url  =      {http://www.openfoam.com},
> >
> > note  =      "OpenFOAM is a free, open source CFD software package. It 
> > allows PETSc linear algebra and solvers to be used underneath.",
> >
> > key  =      "OpenFOAM 2.2.1"
> >
> > }
> >
> >
> > Do you have more information on the use of PETSc within OpenFoam?
> 
>  Very good question. It seems that this citation is wrong or no longer valid; 
>I have removed it from the PETSc repository. I could find no mention of PETSc 
>usage in the OpenFoam and its third party packages. I think we should not have 
>been listing this citation.
> 
> This suggests that people are using it with OpenFOAM: 
> http://powerlab.fsb.hr/ped/kturbo/OpenFOAM/slides/PatersonNuTTS2009.pdf
> 
> In fact, they use PETSc in the dynamic overset grid implementation for 
> OpenFOAM, which I think is an approved extension:
> 
>  
>http://web.student.chalmers.se/groups/ofw5/Abstracts/DavidBogerAbstractOFW5.pdf
> 
>      Matt
>  
> 
>    Barry
> 
> >
> > 4) @matt in response to a question he raised in Vienna
> >
> > MIPSE is a BEM solver. Details are on:
> > http://www.g2elab.grenoble-inp.fr/plateforms/mipse-modeling-of-interconnected-power-systems-632862.kjsp?RH=G2ELAB_R-MAGE
> >
> > Cheers, Domenico Lahaye.
> 
> >
> 
> 
> 
> 
> -- 
> 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
> 
> 
> 
> 
> 
> -- 
> 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
> 
> 


  

Reply via email to