Re: [petsc-users] Petsc with Windows

[Boris Kaus]

> This is probably a better choice than Cygwin going forward.
> 
> https://msdn.microsoft.com/en-us/commandline/wsl/about
> 
> I don't know to what extent PETSc users have experimented with this
> feature, but it should make it easier to build and distribute PETSc.
We have tried this in Mainz, and PETSc (with MUMPS/SUPERLU_DIST/mpich) compiles 
out of the box with the new command-line option under windows 10.
It’s not as fast as linux/mac, but does the job

This won’t make me give up my mac yet, but windows seems to head in the right 
direction.

Boris


___

Boris J.P. Kaus

Institute of Geosciences, 
Center for Computational Sciences & 
Center for Volcanoes and Atmosphere in Magmatic Open Systems
Johannes Gutenberg University of Mainz, Mainz, Germany
Office: 00-285
Tel:+49.6131.392.4527

http://www.geo-dynamics.eu
___

Re: [petsc-users] DMShellSetCreateRestriction

[Boris Kaus]

> Other suggestions on how to best integrate staggered finite differences 
> within the current PETSc framework are ofcourse also highly welcome. 
> Our current thinking was to pack it into a DMSHELL (which has the problem of 
> not having a restriction interface). 
> 
> 
> Using DMShell is the cleanest approach.
> 
> An alternative is to have you user code simply take control of all of the 
> configuration of the PCMG object. E.g. you call your user code which creates 
> the restriction operator, you pull out the PC and call PCMGSetRestriction() 
> on etc. This can be done easily performed in the context of linear problems. 
> For non-linear problems, you could jam this setup code inside your 
> ComputeJacobian function.
> 
> This is all possible, albeit clunky and kinda ugly. It works though if you 
> need something before Barry adds the required support in PCMG.
> 
that is indeed what we currently do, which does work. 
Yet, as you say, it is clunky and does not allow setting up things like FAS in 
an easy manner, or add new physics to the code in a straightforward manner.
Having a cleaner interface would be really nice.

Boris

> Cheers
>   Dave
> 
> 

Re: [petsc-users] DMShellSetCreateRestriction

[Boris Kaus]

Thanks - that would be great!

> On Mar 11, 2016, at 10:25 PM, Barry Smith <bsm...@mcs.anl.gov> wrote:
> 
> 
>  Boris,
> 
>We will add this support to the DMShell and its usage from PCMG within a 
> few days.
> 
>   Barry
> 
>> On Mar 11, 2016, at 3:39 PM, Boris Kaus <k...@uni-mainz.de> wrote:
>> 
>> 
>>> On Mar 11, 2016, at 8:53 PM, Matthew Knepley <knep...@gmail.com> wrote:
>>> 
>>> On Fri, Mar 11, 2016 at 12:26 PM, Dave May <dave.mayhe...@gmail.com> wrote:
>>> On 11 March 2016 at 18:11, anton <po...@uni-mainz.de> wrote:
>>> Hi team,
>>> 
>>> I'm implementing staggered grid in a PETSc-canonical way, trying to build a 
>>> custom DM object, attach it to SNES, that should later transfered it 
>>> further to KSP and PC.
>>> 
>>> Yet, the Galerking coarsening for staggered grid is non-symmetric. The 
>>> question is how possible is it that DMShellSetCreateRestriction can be 
>>> implemented and included in 3.7 release?
>>> 
>>> It's a little more work than just adding a new method within the DM and a 
>>> new APIs for DMCreateRestriction() and DMShellSetCreateRestriction().
>>> PCMG needs to be modified to call DMCreateRestriction(). 
>>> 
>>> Dave is correct. Currently, PCMG only calls DMCreateInterpolation(). We 
>>> would need to add a DMCreateRestriction() call.
>> The PCMG object already uses a restriction operator that is different from 
>> the interpolation parameter if it is specified with PCMGSetRestriction. 
>> For consistency, one would expect a similar DMCreateRestriction object, not? 
>> I realize that this is not relevant for FEM codes, but for staggered FD it 
>> makes quite some difference. 
>> 
>> Other suggestions on how to best integrate staggered finite differences 
>> within the current PETSc framework are ofcourse also highly welcome. 
>> Our current thinking was to pack it into a DMSHELL (which has the problem of 
>> not having a restriction interface). 
>> 
>> thanks,
>> Boris
>> 
>> 
>> 
>> 
>>>  Thanks,
>>> 
>>>Matt
>>> 
>>> Please, please.
>>> 
>>> Thanks,
>>> Anton
>>> 
>>> 
>>> -- 
>>> 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
>> 
> 

Re: [petsc-users] DMShellSetCreateRestriction

[Boris Kaus]

> On Mar 11, 2016, at 8:53 PM, Matthew Knepley  wrote:
> 
> On Fri, Mar 11, 2016 at 12:26 PM, Dave May  > wrote:
> On 11 March 2016 at 18:11, anton  > wrote:
> Hi team,
> 
> I'm implementing staggered grid in a PETSc-canonical way, trying to build a 
> custom DM object, attach it to SNES, that should later transfered it further 
> to KSP and PC.
> 
> Yet, the Galerking coarsening for staggered grid is non-symmetric. The 
> question is how possible is it that DMShellSetCreateRestriction can be 
> implemented and included in 3.7 release?
> 
> It's a little more work than just adding a new method within the DM and a new 
> APIs for DMCreateRestriction() and DMShellSetCreateRestriction().
> PCMG needs to be modified to call DMCreateRestriction(). 
> 
> Dave is correct. Currently, PCMG only calls DMCreateInterpolation(). We would 
> need to add a DMCreateRestriction() call.
The PCMG object already uses a restriction operator that is different from the 
interpolation parameter if it is specified with PCMGSetRestriction 
.
 
For consistency, one would expect a similar DMCreateRestriction object, not? I 
realize that this is not relevant for FEM codes, but for staggered FD it makes 
quite some difference. 

Other suggestions on how to best integrate staggered finite differences within 
the current PETSc framework are ofcourse also highly welcome. 
Our current thinking was to pack it into a DMSHELL (which has the problem of 
not having a restriction interface). 

thanks,
Boris




>   Thanks,
> 
> Matt
>  
> Please, please.
> 
> Thanks,
> Anton
> 
> 
> -- 
> 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

[petsc-users] PhD position on developing software to model hydrofracturing in geothermal systems

[Boris Kaus]

Dear PETSC-users,


I have an open PhD position in my group to develop codes to simulate 
hydrofracturing in visco-elasto-plastic rocks using massively parallel 
computers.
We will use PETSC for this, so in case you are interested or you know someone 
that might be interested please let them know.

A detailed description of the project, together with application instructions 
is given here

http://www.geowiss.uni-mainz.de/Illustrationen/Geophysics/CREEP-ESR12-Mainz_Bristol_final.pdf


thanks!

Boris 

___

Boris J.P. Kaus

Professor
Institute of Geosciences, 
Center for Computational Sciences  
Center for Volcanoes and Atmosphere in Magmatic Open Systems
Johannes Gutenberg University of Mainz, Mainz, Germany
J.J. Becherweg 21, 55099 Mainz, Germany.
Office: 00-285
Tel:+49.6131.392.4527

http://www.geo-dynamics.eu
___

[petsc-users] Galerkin multigrid coarsening

[Boris Kaus]

Hi,


While doing multigrid it is possible to explicitly set restriction and 
prolongation/interpolation operators in PETSC using PCMGSetRestriction and 
PCMGSetInterpolation.  In many cases, the restriction (R) and prolongation (P) 
operators are simply the transpose of each other (R=P’). 

Yet, in certain cases, for example variable viscosity Stokes with a staggered 
finite difference discretization, it is advantageous if they are different (see 
http://arxiv.org/pdf/1308.4605.pdf).

Accordding to the Wesseling textbook, Galerkin coarsening of the fine grid 
matrix is defined as:

Acoarse = R*A*P

Yet, as far as I can tell, PETSc seems to implement this as:

Acoarse = R*A*R’

even in the case that R is different from P’. 
Is there a way for PETSc to use the actually provided prolongation and 
restriction operators to compute the coarse grid approximation?

thanks!

Boris





___

Boris J.P. Kaus

Institute of Geosciences, 
Geocycles Research Center 
Center for Computational Sciences.
University of Mainz, Mainz, Germany
Office: 00-285
Tel:+49.6131.392.4527

http://www.geo-dynamics.eu
___