[petsc-users] DMPlex. Apply Dirichlet boundary condition

[Josh L]

Hi,

My problem has an irregular domain and for the nodes I have to apply
boundary condition, I only know their node number in nature ordering.
How do I apply BC(zero out the corresponding entries in global Vec and Mat)
after DMPlexDistribute when it is all in global ordering?

If using DMLabel, how do I add those nodes to the label If I only have
their number in nature ordering?


Thanks,
Josh

Re: [petsc-users] Increasing norm with finer mesh

[Fande Kong]

Use -ksp_view to confirm the options are actually set.

Fande 

Sent from my iPhone

> On Oct 16, 2018, at 7:40 PM, Ellen M. Price  
> wrote:
> 
> Maybe a stupid suggestion, but sometimes I forget to call the
> *SetFromOptions function on my object, and then get confused when
> changing the options has no effect. Just a thought from a fellow grad
> student.
> 
> Ellen
> 
> 
>> On 10/16/2018 09:36 PM, Matthew Knepley wrote:
>> On Tue, Oct 16, 2018 at 9:14 PM Weizhuo Wang > > wrote:
>> 
>>I just tried both, neither of them make a difference. I got exactly
>>the same curve with either combination.
>> 
>> 
>> I have a hard time believing you. If you make the residual tolerance
>> much finer, your error will definitely change.
>> I run tests every day that do exactly this. You can run them too, since
>> they are just examples.
>> 
>>   Thanks,
>> 
>>  Matt
>>  
>> 
>>Thanks!
>> 
>>Wang weizhuo
>> 
>>On Tue, Oct 16, 2018 at 8:06 PM Matthew Knepley >> wrote:
>> 
>>On Tue, Oct 16, 2018 at 7:26 PM Weizhuo Wang
>>mailto:weizh...@illinois.edu>> wrote:
>> 
>>Hello again!
>> 
>>After some tweaking the code is giving right answers now.
>>However it start to disagree with MATLAB results
>>('traditional' way using matrix inverse) when the grid is
>>larger than 100*100. My PhD advisor and I suspects that the
>>default dimension of the Krylov subspace is 100 in the test
>>case we are running. If so, is there a way to increase the
>>size of the subspace?
>> 
>> 
>>1) The default subspace size is 30, not 100. You can increase
>>the subspace size using
>> 
>>   -ksp_gmres_restart n
>> 
>>2) The problem is likely your tolerance. The default solver
>>tolerance is 1e-5. You can change it using
>> 
>>   -ksp_rtol 1e-9
>> 
>>  Thanks,
>> 
>> Matt
>> 
>> 
>> 
>>Disagrees.png
>> 
>>Thanks!
>> 
>>Wang Weizhuo
>> 
>>On Tue, Oct 9, 2018 at 2:50 AM Mark Adams >> wrote:
>> 
>>To reiterate what Matt is saying, you seem to have the
>>exact solution on a 10x10 grid. That makes no sense
>>unless the solution can be represented exactly by your
>>FE space (eg, u(x,y) = x + y).
>> 
>>On Mon, Oct 8, 2018 at 9:33 PM Matthew Knepley
>>mailto:knep...@gmail.com>> wrote:
>> 
>>On Mon, Oct 8, 2018 at 9:28 PM Weizhuo Wang
>>>> wrote:
>> 
>>The code is attached in case anyone wants to
>>take a look, I will try the high frequency
>>scenario later.
>> 
>> 
>>That is not the error. It is superconvergence at the
>>vertices. The real solution is trigonometric, so your
>>linear interpolants or whatever you use is not going
>>to get the right value in between mesh points. You
>>need to do a real integral over the whole interval
>>to get the L_2 error.
>> 
>>  Thanks,
>> 
>> Matt
>> 
>> 
>>On Mon, Oct 8, 2018 at 7:58 PM Mark Adams
>>mailto:mfad...@lbl.gov>> wrote:
>> 
>> 
>> 
>>On Mon, Oct 8, 2018 at 6:58 PM Weizhuo Wang
>>>> wrote:
>> 
>>The first plot is the norm with the flag
>>-pc_type lu with respect to number of
>>grids in one axis (n), and the second
>>plot is the norm without the flag
>>-pc_type lu. 
>> 
>> 
>>So you are using the default PC w/o LU. The
>>default is ILU. This will reduce high
>>frequency effectively but is not effective
>>on the low frequency error. Don't expect
>>your algebraic error reduction to be at the
>>same scale as the residual reduction (what
>>KSP measures). 
>> 
>> 
>> 
>> 
>>-- 
>>Wang Weizhuo
>> 
>> 
>> 
>>-- 
>>What most experimenters take for granted before they
>>begin their experiments is infinitely more
>>interesting than any results to which their
>>  

Re: [petsc-users] Increasing norm with finer mesh

[Ellen M. Price]

Maybe a stupid suggestion, but sometimes I forget to call the
*SetFromOptions function on my object, and then get confused when
changing the options has no effect. Just a thought from a fellow grad
student.

Ellen


On 10/16/2018 09:36 PM, Matthew Knepley wrote:
> On Tue, Oct 16, 2018 at 9:14 PM Weizhuo Wang  > wrote:
> 
> I just tried both, neither of them make a difference. I got exactly
> the same curve with either combination.
> 
> 
> I have a hard time believing you. If you make the residual tolerance
> much finer, your error will definitely change.
> I run tests every day that do exactly this. You can run them too, since
> they are just examples.
> 
>   Thanks,
> 
>      Matt
>  
> 
> Thanks!
> 
> Wang weizhuo
> 
> On Tue, Oct 16, 2018 at 8:06 PM Matthew Knepley  > wrote:
> 
> On Tue, Oct 16, 2018 at 7:26 PM Weizhuo Wang
> mailto:weizh...@illinois.edu>> wrote:
> 
> Hello again!
> 
> After some tweaking the code is giving right answers now.
> However it start to disagree with MATLAB results
> ('traditional' way using matrix inverse) when the grid is
> larger than 100*100. My PhD advisor and I suspects that the
> default dimension of the Krylov subspace is 100 in the test
> case we are running. If so, is there a way to increase the
> size of the subspace?
> 
> 
> 1) The default subspace size is 30, not 100. You can increase
> the subspace size using
> 
>        -ksp_gmres_restart n
> 
> 2) The problem is likely your tolerance. The default solver
> tolerance is 1e-5. You can change it using
> 
>        -ksp_rtol 1e-9
> 
>   Thanks,
> 
>      Matt
>  
> 
> 
> Disagrees.png
> 
> Thanks!
> 
> Wang Weizhuo
> 
> On Tue, Oct 9, 2018 at 2:50 AM Mark Adams  > wrote:
> 
> To reiterate what Matt is saying, you seem to have the
> exact solution on a 10x10 grid. That makes no sense
> unless the solution can be represented exactly by your
> FE space (eg, u(x,y) = x + y).
> 
> On Mon, Oct 8, 2018 at 9:33 PM Matthew Knepley
> mailto:knep...@gmail.com>> wrote:
> 
> On Mon, Oct 8, 2018 at 9:28 PM Weizhuo Wang
>  > wrote:
> 
> The code is attached in case anyone wants to
> take a look, I will try the high frequency
> scenario later.
> 
> 
> That is not the error. It is superconvergence at the
> vertices. The real solution is trigonometric, so your
> linear interpolants or whatever you use is not going
> to get the right value in between mesh points. You
> need to do a real integral over the whole interval
> to get the L_2 error.
> 
>   Thanks,
> 
>      Matt
>  
> 
> On Mon, Oct 8, 2018 at 7:58 PM Mark Adams
> mailto:mfad...@lbl.gov>> wrote:
> 
> 
> 
> On Mon, Oct 8, 2018 at 6:58 PM Weizhuo Wang
>  > wrote:
> 
> The first plot is the norm with the flag
> -pc_type lu with respect to number of
> grids in one axis (n), and the second
> plot is the norm without the flag
> -pc_type lu. 
> 
> 
> So you are using the default PC w/o LU. The
> default is ILU. This will reduce high
> frequency effectively but is not effective
> on the low frequency error. Don't expect
> your algebraic error reduction to be at the
> same scale as the residual reduction (what
> KSP measures). 
>  
> 
> 
> 
> -- 
> Wang Weizhuo
> 
> 
> 
> -- 
> 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
> 
> https://www.cse.buffalo.edu/~knepley/
> 
> 

Re: [petsc-users] Increasing norm with finer mesh

[Matthew Knepley]

On Tue, Oct 16, 2018 at 9:14 PM Weizhuo Wang  wrote:

> I just tried both, neither of them make a difference. I got exactly the
> same curve with either combination.
>

I have a hard time believing you. If you make the residual tolerance much
finer, your error will definitely change.
I run tests every day that do exactly this. You can run them too, since
they are just examples.

  Thanks,

 Matt


> Thanks!
>
> Wang weizhuo
>
> On Tue, Oct 16, 2018 at 8:06 PM Matthew Knepley  wrote:
>
>> On Tue, Oct 16, 2018 at 7:26 PM Weizhuo Wang 
>> wrote:
>>
>>> Hello again!
>>>
>>> After some tweaking the code is giving right answers now. However it
>>> start to disagree with MATLAB results ('traditional' way using matrix
>>> inverse) when the grid is larger than 100*100. My PhD advisor and I
>>> suspects that the default dimension of the Krylov subspace is 100 in the
>>> test case we are running. If so, is there a way to increase the size of the
>>> subspace?
>>>
>>
>> 1) The default subspace size is 30, not 100. You can increase the
>> subspace size using
>>
>>-ksp_gmres_restart n
>>
>> 2) The problem is likely your tolerance. The default solver tolerance is
>> 1e-5. You can change it using
>>
>>-ksp_rtol 1e-9
>>
>>   Thanks,
>>
>>  Matt
>>
>>
>>>
>>> [image: Disagrees.png]
>>>
>>> Thanks!
>>>
>>> Wang Weizhuo
>>>
>>> On Tue, Oct 9, 2018 at 2:50 AM Mark Adams  wrote:
>>>
 To reiterate what Matt is saying, you seem to have the exact solution
 on a 10x10 grid. That makes no sense unless the solution can be represented
 exactly by your FE space (eg, u(x,y) = x + y).

 On Mon, Oct 8, 2018 at 9:33 PM Matthew Knepley 
 wrote:

> On Mon, Oct 8, 2018 at 9:28 PM Weizhuo Wang 
> wrote:
>
>> The code is attached in case anyone wants to take a look, I will try
>> the high frequency scenario later.
>>
>
> That is not the error. It is superconvergence at the vertices. The
> real solution is trigonometric, so your
> linear interpolants or whatever you use is not going to get the right
> value in between mesh points. You
> need to do a real integral over the whole interval to get the L_2
> error.
>
>   Thanks,
>
>  Matt
>
>
>> On Mon, Oct 8, 2018 at 7:58 PM Mark Adams  wrote:
>>
>>>
>>>
>>> On Mon, Oct 8, 2018 at 6:58 PM Weizhuo Wang 
>>> wrote:
>>>
 The first plot is the norm with the flag -pc_type lu with respect
 to number of grids in one axis (n), and the second plot is the norm 
 without
 the flag -pc_type lu.

>>>
>>> So you are using the default PC w/o LU. The default is ILU. This
>>> will reduce high frequency effectively but is not effective on the low
>>> frequency error. Don't expect your algebraic error reduction to be at 
>>> the
>>> same scale as the residual reduction (what KSP measures).
>>>
>>>

>>
>> --
>> Wang Weizhuo
>>
>
>
> --
> 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
>
> https://www.cse.buffalo.edu/~knepley/
> 
>

>>>
>>> --
>>> Wang Weizhuo
>>>
>>
>>
>> --
>> 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
>>
>> https://www.cse.buffalo.edu/~knepley/
>> 
>>
>
>
> --
> Wang Weizhuo
>


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

https://www.cse.buffalo.edu/~knepley/ 

Re: [petsc-users] Increasing norm with finer mesh

[Dave May]

On Wed, 17 Oct 2018 at 03:15, Weizhuo Wang  wrote:

> I just tried both, neither of them make a difference. I got exactly the
> same curve with either combination.
>

Try using right preconditioning.

https://www.mcs.anl.gov/petsc/petsc-current/docs/manualpages/KSP/KSPSetPCSide.html


Use the options:

-ksp_type gmres -ksp_pc_side right -ksp_rtol 1e-12

Or;

-ksp_type fgmres  -ksp_rtol 1e-12

Fgmres does right preconditioning my default



> Thanks!
>
> Wang weizhuo
>
> On Tue, Oct 16, 2018 at 8:06 PM Matthew Knepley  wrote:
>
>> On Tue, Oct 16, 2018 at 7:26 PM Weizhuo Wang 
>> wrote:
>>
>>> Hello again!
>>>
>>> After some tweaking the code is giving right answers now. However it
>>> start to disagree with MATLAB results ('traditional' way using matrix
>>> inverse) when the grid is larger than 100*100. My PhD advisor and I
>>> suspects that the default dimension of the Krylov subspace is 100 in the
>>> test case we are running. If so, is there a way to increase the size of the
>>> subspace?
>>>
>>
>> 1) The default subspace size is 30, not 100. You can increase the
>> subspace size using
>>
>>-ksp_gmres_restart n
>>
>> 2) The problem is likely your tolerance. The default solver tolerance is
>> 1e-5. You can change it using
>>
>>-ksp_rtol 1e-9
>>
>>   Thanks,
>>
>>  Matt
>>
>>
>>>
>>> [image: Disagrees.png]
>>>
>>> Thanks!
>>>
>>> Wang Weizhuo
>>>
>>> On Tue, Oct 9, 2018 at 2:50 AM Mark Adams  wrote:
>>>
 To reiterate what Matt is saying, you seem to have the exact solution
 on a 10x10 grid. That makes no sense unless the solution can be represented
 exactly by your FE space (eg, u(x,y) = x + y).

 On Mon, Oct 8, 2018 at 9:33 PM Matthew Knepley 
 wrote:

> On Mon, Oct 8, 2018 at 9:28 PM Weizhuo Wang 
> wrote:
>
>> The code is attached in case anyone wants to take a look, I will try
>> the high frequency scenario later.
>>
>
> That is not the error. It is superconvergence at the vertices. The
> real solution is trigonometric, so your
> linear interpolants or whatever you use is not going to get the right
> value in between mesh points. You
> need to do a real integral over the whole interval to get the L_2
> error.
>
>   Thanks,
>
>  Matt
>
>
>> On Mon, Oct 8, 2018 at 7:58 PM Mark Adams  wrote:
>>
>>>
>>>
>>> On Mon, Oct 8, 2018 at 6:58 PM Weizhuo Wang 
>>> wrote:
>>>
 The first plot is the norm with the flag -pc_type lu with respect
 to number of grids in one axis (n), and the second plot is the norm 
 without
 the flag -pc_type lu.

>>>
>>> So you are using the default PC w/o LU. The default is ILU. This
>>> will reduce high frequency effectively but is not effective on the low
>>> frequency error. Don't expect your algebraic error reduction to be at 
>>> the
>>> same scale as the residual reduction (what KSP measures).
>>>
>>>

>>
>> --
>> Wang Weizhuo
>>
>
>
> --
> 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
>
> https://www.cse.buffalo.edu/~knepley/
> 
>

>>>
>>> --
>>> Wang Weizhuo
>>>
>>
>>
>> --
>> 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
>>
>> https://www.cse.buffalo.edu/~knepley/
>> 
>>
>
>
> --
> Wang Weizhuo
>

Re: [petsc-users] Increasing norm with finer mesh

[Weizhuo Wang]

I just tried both, neither of them make a difference. I got exactly the
same curve with either combination.

Thanks!

Wang weizhuo

On Tue, Oct 16, 2018 at 8:06 PM Matthew Knepley  wrote:

> On Tue, Oct 16, 2018 at 7:26 PM Weizhuo Wang 
> wrote:
>
>> Hello again!
>>
>> After some tweaking the code is giving right answers now. However it
>> start to disagree with MATLAB results ('traditional' way using matrix
>> inverse) when the grid is larger than 100*100. My PhD advisor and I
>> suspects that the default dimension of the Krylov subspace is 100 in the
>> test case we are running. If so, is there a way to increase the size of the
>> subspace?
>>
>
> 1) The default subspace size is 30, not 100. You can increase the subspace
> size using
>
>-ksp_gmres_restart n
>
> 2) The problem is likely your tolerance. The default solver tolerance is
> 1e-5. You can change it using
>
>-ksp_rtol 1e-9
>
>   Thanks,
>
>  Matt
>
>
>>
>> [image: Disagrees.png]
>>
>> Thanks!
>>
>> Wang Weizhuo
>>
>> On Tue, Oct 9, 2018 at 2:50 AM Mark Adams  wrote:
>>
>>> To reiterate what Matt is saying, you seem to have the exact solution on
>>> a 10x10 grid. That makes no sense unless the solution can be represented
>>> exactly by your FE space (eg, u(x,y) = x + y).
>>>
>>> On Mon, Oct 8, 2018 at 9:33 PM Matthew Knepley 
>>> wrote:
>>>
 On Mon, Oct 8, 2018 at 9:28 PM Weizhuo Wang 
 wrote:

> The code is attached in case anyone wants to take a look, I will try
> the high frequency scenario later.
>

 That is not the error. It is superconvergence at the vertices. The real
 solution is trigonometric, so your
 linear interpolants or whatever you use is not going to get the right
 value in between mesh points. You
 need to do a real integral over the whole interval to get the L_2 error.

   Thanks,

  Matt


> On Mon, Oct 8, 2018 at 7:58 PM Mark Adams  wrote:
>
>>
>>
>> On Mon, Oct 8, 2018 at 6:58 PM Weizhuo Wang 
>> wrote:
>>
>>> The first plot is the norm with the flag -pc_type lu with respect to
>>> number of grids in one axis (n), and the second plot is the norm without
>>> the flag -pc_type lu.
>>>
>>
>> So you are using the default PC w/o LU. The default is ILU. This will
>> reduce high frequency effectively but is not effective on the low 
>> frequency
>> error. Don't expect your algebraic error reduction to be at the same 
>> scale
>> as the residual reduction (what KSP measures).
>>
>>
>>>
>
> --
> Wang Weizhuo
>


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

 https://www.cse.buffalo.edu/~knepley/
 

>>>
>>
>> --
>> Wang Weizhuo
>>
>
>
> --
> 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
>
> https://www.cse.buffalo.edu/~knepley/
> 
>


-- 
Wang Weizhuo

Re: [petsc-users] Increasing norm with finer mesh

[Matthew Knepley]

On Tue, Oct 16, 2018 at 7:26 PM Weizhuo Wang  wrote:

> Hello again!
>
> After some tweaking the code is giving right answers now. However it start
> to disagree with MATLAB results ('traditional' way using matrix inverse)
> when the grid is larger than 100*100. My PhD advisor and I suspects that
> the default dimension of the Krylov subspace is 100 in the test case we are
> running. If so, is there a way to increase the size of the subspace?
>

1) The default subspace size is 30, not 100. You can increase the subspace
size using

   -ksp_gmres_restart n

2) The problem is likely your tolerance. The default solver tolerance is
1e-5. You can change it using

   -ksp_rtol 1e-9

  Thanks,

 Matt


>
> [image: Disagrees.png]
>
> Thanks!
>
> Wang Weizhuo
>
> On Tue, Oct 9, 2018 at 2:50 AM Mark Adams  wrote:
>
>> To reiterate what Matt is saying, you seem to have the exact solution on
>> a 10x10 grid. That makes no sense unless the solution can be represented
>> exactly by your FE space (eg, u(x,y) = x + y).
>>
>> On Mon, Oct 8, 2018 at 9:33 PM Matthew Knepley  wrote:
>>
>>> On Mon, Oct 8, 2018 at 9:28 PM Weizhuo Wang 
>>> wrote:
>>>
 The code is attached in case anyone wants to take a look, I will try
 the high frequency scenario later.

>>>
>>> That is not the error. It is superconvergence at the vertices. The real
>>> solution is trigonometric, so your
>>> linear interpolants or whatever you use is not going to get the right
>>> value in between mesh points. You
>>> need to do a real integral over the whole interval to get the L_2 error.
>>>
>>>   Thanks,
>>>
>>>  Matt
>>>
>>>
 On Mon, Oct 8, 2018 at 7:58 PM Mark Adams  wrote:

>
>
> On Mon, Oct 8, 2018 at 6:58 PM Weizhuo Wang 
> wrote:
>
>> The first plot is the norm with the flag -pc_type lu with respect to
>> number of grids in one axis (n), and the second plot is the norm without
>> the flag -pc_type lu.
>>
>
> So you are using the default PC w/o LU. The default is ILU. This will
> reduce high frequency effectively but is not effective on the low 
> frequency
> error. Don't expect your algebraic error reduction to be at the same scale
> as the residual reduction (what KSP measures).
>
>
>>

 --
 Wang Weizhuo

>>>
>>>
>>> --
>>> 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
>>>
>>> https://www.cse.buffalo.edu/~knepley/
>>> 
>>>
>>
>
> --
> Wang Weizhuo
>


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

https://www.cse.buffalo.edu/~knepley/ 

Re: [petsc-users] Increasing norm with finer mesh

[Weizhuo Wang]

Hello again!

After some tweaking the code is giving right answers now. However it start
to disagree with MATLAB results ('traditional' way using matrix inverse)
when the grid is larger than 100*100. My PhD advisor and I suspects that
the default dimension of the Krylov subspace is 100 in the test case we are
running. If so, is there a way to increase the size of the subspace?

[image: Disagrees.png]

Thanks!

Wang Weizhuo

On Tue, Oct 9, 2018 at 2:50 AM Mark Adams  wrote:

> To reiterate what Matt is saying, you seem to have the exact solution on a
> 10x10 grid. That makes no sense unless the solution can be represented
> exactly by your FE space (eg, u(x,y) = x + y).
>
> On Mon, Oct 8, 2018 at 9:33 PM Matthew Knepley  wrote:
>
>> On Mon, Oct 8, 2018 at 9:28 PM Weizhuo Wang 
>> wrote:
>>
>>> The code is attached in case anyone wants to take a look, I will try the
>>> high frequency scenario later.
>>>
>>
>> That is not the error. It is superconvergence at the vertices. The real
>> solution is trigonometric, so your
>> linear interpolants or whatever you use is not going to get the right
>> value in between mesh points. You
>> need to do a real integral over the whole interval to get the L_2 error.
>>
>>   Thanks,
>>
>>  Matt
>>
>>
>>> On Mon, Oct 8, 2018 at 7:58 PM Mark Adams  wrote:
>>>


 On Mon, Oct 8, 2018 at 6:58 PM Weizhuo Wang 
 wrote:

> The first plot is the norm with the flag -pc_type lu with respect to
> number of grids in one axis (n), and the second plot is the norm without
> the flag -pc_type lu.
>

 So you are using the default PC w/o LU. The default is ILU. This will
 reduce high frequency effectively but is not effective on the low frequency
 error. Don't expect your algebraic error reduction to be at the same scale
 as the residual reduction (what KSP measures).


>
>>>
>>> --
>>> Wang Weizhuo
>>>
>>
>>
>> --
>> 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
>>
>> https://www.cse.buffalo.edu/~knepley/
>> 
>>
>

-- 
Wang Weizhuo

Re: [petsc-users] Gauss quadrature for triangle or tetrahedral element and Nature ordering

[Matthew Knepley]

On Tue, Oct 16, 2018 at 12:31 PM Josh L  wrote:

> Hi,
>
> Does anyone use PETSc to calculate the value determinant, basis function
> and the derivative of basis function at Gauss integration point?
>
> For quadrilateral element, I use PetscDTGaussQuadrature to get the
> location of integration point, and then use DMPlexComputeCellGeometryFEM to
> get the value of determinant.
>
> But I don't know how to do it for triangle element, and don't know how to
> use PETSc to calculate basis function and it's derivative?
>
> Is there anyway to get the mapping between nature ordering and global
> ordering for vertex number?
>

The reason that it is a little disjointed is that we are in the process of
converting from what I had previously done:


https://www.mcs.anl.gov/petsc/petsc-current/docs/manualpages/DMPLEX/DMPlexComputeCellGeometryFEM.html

to something which is much more flexible and nice


https://www.mcs.anl.gov/petsc/petsc-master/docs/manualpages/DM/DMFieldCreateFEGeom.html

You get the DMField object from

  PetscErrorCode DMGetCoordinateField(DM dm, DMField *field)

which is sadly not documented yet, but just gives back the right thing. If
the DMField stuff looks too new, you can just use the
old code until the documentation catches up. Otherwise, feel free to mail
DMField questions. The reason for DMField is that
you can have very general things that can evaluate themselves (particles,
Fourier bases, etc.) instead of just FEM.

  Thanks,

Matt


> Thanks,
> Josh
>
>

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

https://www.cse.buffalo.edu/~knepley/ 

[petsc-users] Gauss quadrature for triangle or tetrahedral element and Nature ordering

[Josh L]

Hi,

Does anyone use PETSc to calculate the value determinant, basis function
and the derivative of basis function at Gauss integration point?

For quadrilateral element, I use PetscDTGaussQuadrature to get the location
of integration point, and then use DMPlexComputeCellGeometryFEM to get the
value of determinant.

But I don't know how to do it for triangle element, and don't know how to
use PETSc to calculate basis function and it's derivative?

Is there anyway to get the mapping between nature ordering and global
ordering for vertex number?


Thanks,
Josh

Re: [petsc-users] Fwd: Interpolation in staggered grid

[Matthew Knepley]

On Tue, Oct 16, 2018 at 3:57 AM Anton Popov  wrote:

> Hi Manuel,
>
> you might consider useful taking a look at this code
> https://bitbucket.org/bkaus/lamem, which is a multi-DMDA staggered grid
> implementation.
>
> Also, as Matt pointed out, there is a direct PETSc support for staggered
> grids (DMSTAG), recently contributed by Patrick Sanan.
>
> Anton is right, LaMeM is a great example. Did you also have a look at SNES
ex30? It is staggered grid FV and works in parallel.

  Thanks,

Matt

> Thanks,
>
> Anton
>
> On 15.10.2018 23:22, Manuel Valera wrote:
>
>
> Thanks Matthew, i have made some progress but i am still unsure on how to
> proceed to make the DMDAs work as intended, i will try to lay out what i am
> trying now:
>
> I was able to port the interpolation into the DMDA model but it works only
> in serial runs, and it becomes unstable for more than one processor running,
>
> What i do is roughly this:
>
>- Calculate density at a cell-centered DMDA object, using a local
>vector so i can access the ghost rows (indices -1 and max+1)
>- Interpolate into a face-centered DMDA object for velocities, using
>also a local vector.
>
> Doing this i get the right results using the same interpolation i used for
> my non-petsc implementation of the model, as long as i use only one
> processor but the doubts i have are:
>
>- How to use the local vectors properly: Is operating on them the
>recommended course in this case?
>- How can i access the ghost indices in the global vector so i can
>then communicate GlobalToLocal? would this be a better strategy?
>- I feel is wrong to interpolate a cell-centered based vector into a
>face-centered based vector, using the indices of the latter, what strategy
>would work best in this case?
>
> I also tried opening a global vector with a different DA layout than the
> one created (opening global density on the velocities DMDA layout) and this
> introduced an error in the GlobalToLocal, LocalToLocal, LocalToGlobal
> communication, something didn't happen if i used the local versions of
> these vectors instead,
>
> Thanks for your help,
>
> Manuel
>
>
>
>
>
> On Sat, Oct 6, 2018 at 4:45 AM Matthew Knepley  wrote:
>
>> On Fri, Oct 5, 2018 at 6:49 PM Manuel Valera  wrote:
>>
>>> Hello,
>>>
>>> I'm trying to do a simple variable interpolation, from a cell center to
>>> a face in a staggered grid, my model data management is done with DMDAs,
>>> with two different DMs one for each cell position,
>>>
>>> I already did this task on a fortran only version of the model using the
>>> 4 closest neighbors of the scalars (cell center) to be interpolated at the
>>> velocity site (cell face), i did it using a loop over the domain, somehow
>>> this easy task is not translating into the DMDA framework,
>>>
>>
>> Its not clear to me what problem you are having. We have done this
>> before. For example,
>>
>>
>> https://www.mcs.anl.gov/petsc/petsc-current/src/snes/examples/tutorials/ex30.c.html
>>
>> I would note that the development version of PETSc now has DMStag which
>> supports staggered grid discretizations directly.
>>
>>   Thanks,
>>
>> Matt
>>
>>
>>> I'm not sure what I'm doing wrong or not aware of a easier way Petsc may
>>> have for this task, if you could point out an easier strategy or an example
>>> I would be grateful,
>>>
>>> Thanks,
>>>
>>>
>>>
>>>
>>>
>>
>> --
>> 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
>>
>> https://www.cse.buffalo.edu/~knepley/
>> 
>>
>
>

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

https://www.cse.buffalo.edu/~knepley/ 

Re: [petsc-users] Fwd: Interpolation in staggered grid

[Anton Popov]

Hi Manuel,

you might consider useful taking a look at this code 
https://bitbucket.org/bkaus/lamem, which is a multi-DMDA staggered grid 
implementation.


Also, as Matt pointed out, there is a direct PETSc support for staggered 
grids (DMSTAG), recently contributed by Patrick Sanan.


Thanks,

Anton


On 15.10.2018 23:22, Manuel Valera wrote:


Thanks Matthew, i have made some progress but i am still unsure on how 
to proceed to make the DMDAs work as intended, i will try to lay out 
what i am trying now:


I was able to port the interpolation into the DMDA model but it works 
only in serial runs, and it becomes unstable for more than one 
processor running,


What i do is roughly this:

  * Calculate density at a cell-centered DMDA object, using a local
vector so i can access the ghost rows (indices -1 and max+1)
  * Interpolate into a face-centered DMDA object for velocities, using
also a local vector.

Doing this i get the right results using the same interpolation i used 
for my non-petsc implementation of the model, as long as i use only 
one processor but the doubts i have are:


  * How to use the local vectors properly: Is operating on them the
recommended course in this case?
  * How can i access the ghost indices in the global vector so i can
then communicate GlobalToLocal? would this be a better strategy?
  * I feel is wrong to interpolate a cell-centered based vector into a
face-centered based vector, using the indices of the latter, what
strategy would work best in this case?

I also tried opening a global vector with a different DA layout than 
the one created (opening global density on the velocities DMDA layout) 
and this introduced an error in the GlobalToLocal, LocalToLocal, 
LocalToGlobal communication, something didn't happen if i used the 
local versions of these vectors instead,


Thanks for your help,

Manuel





On Sat, Oct 6, 2018 at 4:45 AM Matthew Knepley > wrote:


On Fri, Oct 5, 2018 at 6:49 PM Manuel Valera mailto:mvaler...@sdsu.edu>> wrote:

Hello,

I'm trying to do a simple variable interpolation, from a cell
center to a face in a staggered grid, my model data management
is done with DMDAs, with two different DMs one for each cell
position,

I already did this task on a fortran only version of the model
using the 4 closest neighbors of the scalars (cell center) to
be interpolated at the velocity site (cell face), i did it
using a loop over the domain, somehow this easy task is not
translating into the DMDA framework,


Its not clear to me what problem you are having. We have done this
before. For example,


https://www.mcs.anl.gov/petsc/petsc-current/src/snes/examples/tutorials/ex30.c.html

I would note that the development version of PETSc now has DMStag
which supports staggered grid discretizations directly.

  Thanks,

    Matt

I'm not sure what I'm doing wrong or not aware of a easier way
Petsc may have for this task, if you could point out an easier
strategy or an example I would be grateful,

Thanks,






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

https://www.cse.buffalo.edu/~knepley/