libmesh-users — General information for libmesh users

[Libmesh-users] Syncing ghosting between two meshes

[Alexander L. <ale...@gm...>]

In MOOSE we often have two meshes, a reference (un-displaced) and a
displaced mesh. We want to be able to sync ghosting between the two meshes.
Currently I am running into issues when I am running a displaced problem
with AMR.

I first call the reference EquationSystems::reinit which coarsens,
constricts the mesh, and then refines. Now when I call the displaced
EquationSystems::reinit, during coarsening we call DofMap::distribute_dofs
which calls through to our ghosting functors. We set up a proxy ghosting
functor which essentially loops over the ghosting functors and elements of
the reference mesh, determining what elements were ghosted on the reference
mesh **and then** ghosts the corresponding element IDs on the displaced
mesh. This works great except when we have AMR. The problem is that the
mesh constriction of the reference mesh has deleted its inactive elements
and then renumbered. We are calling distribute dofs on the displaced mesh
**before** we've done the same constriction, so we have an out-of-sync
correspondence between the reference and displaced element numbering.

Does anyone have a suggestion for a good solution here? What's the best way
to sync_ghosting()?

Re: [Libmesh-users] [RB] Simplex method in the SCM

[David K. <dav...@ak...>]

On Wed, Mar 20, 2019 at 6:59 AM <ss...@pu...> wrote:

> Hello, David.
>
>
>
> First of all, thank you for your kind reply to the last question.
>
>
>
> This time, I have a simple question in the SCM code.
>
>
>
> From “rb_scm_evaluation.C,” I knew the SCM in libMesh uses the glpk
> package for the simplex method to solve the LP.
>
> Here I would like to know if this code is based on either a primal or dual
> simplex method.
>
>
>
> I guess the answer to this is the primal simplex method, which is the
> default setting of the glpk package, is this correct?
>

Yes, that's correct.

David

[Libmesh-users] [RB] Simplex method in the SCM

[<ss...@pu...>]

Re: [Libmesh-users] KSP convergence reason - DIVERGED_INDEFINITE_PC

[Renato P. <re...@gm...>]

Hi Roy,

I am still not able to get it to work.
I tried matrix ordering, varied solver and PC types.

I would think the problem is when the constrains are applied...
The final matrix is probably not nice.
How can I debug this?

Renato

On Fri, Mar 15, 2019 at 3:36 PM Renato Poli <re...@gm...> wrote:

> Thanks.
>
> Do you see any sense in adding a SCALAR variable and "add_constrain_row"
> to it instead of using an existing DOF as reference?
> If that works, it would be nicer from the coding perspective.
> Would it be numerically more stable?
>
> Renato
>
> On Thu, Mar 14, 2019 at 6:04 PM Stogner, Roy H <roy...@ic...>
> wrote:
>
>>
>> On Thu, 14 Mar 2019, Renato Poli wrote:
>>
>> > How do I change the dof ordering options?
>>
>> "-pc_factor_mat_ordering_type string" with a string from
>>
>> https://www.mcs.anl.gov/petsc/petsc-current/docs/manualpages/Mat/MatOrderingType.html#MatOrderingType
>>
>> >       Add a SCALAR variable to use as a Lagrange multiplier?
>> >
>> > This sounds like a much cleaner solution.
>> > I could not understand how to do that in libmesh so far.
>> > It is probably time to put some more effort here...
>> >
>> > I see I must add a Kp_alpha matrix. Do I need the Kalpha_p as well?
>>
>> Yes; the Kalpha_p ends up being what looks most like the actual
>> constraint equation.
>>
>> ...
>>
>> Except you don't have a constraint *equation* here, you have
>> constraint *equations*.  You wouldn't want a SCALAR lagrange
>> multiplier, you'd want to add a LAGRANGE variable subdomain-restricted
>> to boundary elements along the constrained domain boundary... this is
>> sounding like more trouble than it's worth unless you can't get the
>> directly constrained solves to converge.
>> ---
>> Roy
>>
>

Re: [Libmesh-users] KSP convergence reason - DIVERGED_INDEFINITE_PC

[Renato P. <re...@gm...>]

Thanks.

Do you see any sense in adding a SCALAR variable and "add_constrain_row" to
it instead of using an existing DOF as reference?
If that works, it would be nicer from the coding perspective.
Would it be numerically more stable?

Renato

On Thu, Mar 14, 2019 at 6:04 PM Stogner, Roy H <roy...@ic...>
wrote:

>
> On Thu, 14 Mar 2019, Renato Poli wrote:
>
> > How do I change the dof ordering options?
>
> "-pc_factor_mat_ordering_type string" with a string from
>
> https://www.mcs.anl.gov/petsc/petsc-current/docs/manualpages/Mat/MatOrderingType.html#MatOrderingType
>
> >       Add a SCALAR variable to use as a Lagrange multiplier?
> >
> > This sounds like a much cleaner solution.
> > I could not understand how to do that in libmesh so far.
> > It is probably time to put some more effort here...
> >
> > I see I must add a Kp_alpha matrix. Do I need the Kalpha_p as well?
>
> Yes; the Kalpha_p ends up being what looks most like the actual
> constraint equation.
>
> ...
>
> Except you don't have a constraint *equation* here, you have
> constraint *equations*.  You wouldn't want a SCALAR lagrange
> multiplier, you'd want to add a LAGRANGE variable subdomain-restricted
> to boundary elements along the constrained domain boundary... this is
> sounding like more trouble than it's worth unless you can't get the
> directly constrained solves to converge.
> ---
> Roy
>

Re: [Libmesh-users] [RB] Inner product assembly in RB example 5

[David K. <dav...@ak...>]

On Fri, Mar 15, 2019 at 3:07 AM <ss...@pu...> wrote:

> Hello, David.
>
>
>
> I have a question about the inner product assembly in RB example 5.
>
>
>
> According to equations about the RB method, the inner product assembly
> (•,•)_{V} in the RB method is constructed in the same equation as A
> assembly a(•,•;mu), with the constant parameter mu’.
>
> In other words,  the inner product assembly should be computed as
> (•,•)_{V} = a(•,•;mu’), but the inner product assembly in the RB example 5
> is not.
>
>
>
> Why does not the inner product assembly of the RB example 5 code include
> coefficient matrix C_{ijkl}, which is used in A assembly?
>
>
>
> I look forward to hearing from you.
>


In practice the exact choice of inner product doesn't matter too much
unless you're really trying to compute a rigorous error bound, since then
you need to be careful about the way the inner product is defined in order
to make sure your error bound is rigorous. In the libMesh examples we're
not trying to generate a rigorous error bound since that involves extra
complications (e.g. SCM in some cases), and so instead we just compute an
approximate bound which is usually sufficient in practice anyway. With that
goal in mind, the simpler inner product defined in the example is
sufficient. But of course if you can define the inner product however you
like for your own cases.

Best,
David

Re: [Libmesh-users] Configuring libMesh with Vtk

[Simone R. <sim...@gm...>]

I had a similar issue with libMesh not using the specified VTK installation.
This problem was solved by configuring VTK with MPI, using the VTK configuration option

-D VTK_Group_MPI:BOOL=ON

I hope it helps,

Simone


On Mar 15, 2019, at 11:22, John Peterson <jwp...@gm...> wrote:

> On Fri, Mar 15, 2019 at 10:17 AM Nikrouz <nik...@gm...> wrote:
> 
>> Dear all,
>> 
>> When I want to run FEMsystem example No.2, it is asked me to configure
>> libMesh with --enable vtk. I have configured libMesh(opt and dbg) by
>> these commands but I faced same error.
>> 
>> What Should I do? Thanks for your consideration!
>> 
> 
> Most likely configuring with VTK failed for some reason. You can look at
> the config.log file to find out exactly why, although it can be hard to
> find the right information because there's a lot of info there. Libmesh's
> configure also prints a summary at the end so you can see what features are
> enabled/disabled before continuing to build in an incorrect configuration.
> 
> -- 
> John
> 
> _______________________________________________
> Libmesh-users mailing list
> Lib...@li...
> https://lists.sourceforge.net/lists/listinfo/libmesh-users

Re: [Libmesh-users] Configuring libMesh with Vtk

[John P. <jwp...@gm...>]

On Fri, Mar 15, 2019 at 10:17 AM Nikrouz <nik...@gm...> wrote:

> Dear all,
>
> When I want to run FEMsystem example No.2, it is asked me to configure
> libMesh with --enable vtk. I have configured libMesh(opt and dbg) by
> these commands but I faced same error.
>
> What Should I do? Thanks for your consideration!
>

Most likely configuring with VTK failed for some reason. You can look at
the config.log file to find out exactly why, although it can be hard to
find the right information because there's a lot of info there. Libmesh's
configure also prints a summary at the end so you can see what features are
enabled/disabled before continuing to build in an incorrect configuration.

-- 
John

[Libmesh-users] Configuring libMesh with Vtk

[Nikrouz <nik...@gm...>]

Dear all,

When I want to run FEMsystem example No.2, it is asked me to configure 
libMesh with --enable vtk. I have configured libMesh(opt and dbg) by 
these commands but I faced same error.

What Should I do? Thanks for your consideration!

*/dbg:/*

*/../LIBMESH/configure \/**/
/**/--prefix=$HOME/sfw/linux/libmesh/1.2.1/1.2.1-debug \/**/
/**/    --with-methods=dbg \/**/
/**/    PETSC_DIR=$HOME/sfw/petsc/3.10.0 \/**/
/**/    PETSC_ARCH=linux-debug \/**/
/**/    CC=/usr/bin/mpicc \/**/
/**/    CXX=/usr/bin/mpicxx \/**/
/**/    FC=/usr/bin/mpif90 \/**/
/**/    F77=/usr/bin/mpif90 \/**/
/**/    --enable-vtk 
--with-vtk-include=/opt/visit/2.13.3/linux-x86_64/include/vtk/vtk-6.1 
--with-vtk-lib=/opt/visit/2.13.3/linux-x86_64/lib    \/**/
/**/    --enable-exodus \/**/
/**/    --enable-triangle \/**/
/**/    --disable-boost \/**/
/**/    --disable-openmp \/**/
/**/    --disable-perflog \/**/
/**/    --disable-pthreads \/**/
/**/    --disable-strict-lgpl \/**/
/**/    --disable-glibcxx-debugging/*

*/make/*

*/make install/*

*/
/*

*/../LIBMESH/configure \/**/
/**/--prefix=$HOME/sfw/linux/libmesh/1.2.1/1.2.1-opt \/**/
/**/    --with-methods=opt \/**/
/**/    PETSC_DIR=$HOME/sfw/petsc/3.10.0 \/**/
/**/    PETSC_ARCH=linux-opt \/**/
/**/    CC=/usr/bin/mpicc \/**/
/**/    CXX=/usr/bin/mpicxx \/**/
/**/    FC=/usr/bin/mpif90 \/**/
/**/    F77=/usr/bin/mpif90 \/**/
/**/    --enable-vtk 
--with-vtk-include=/opt/visit/2.13.3/linux-x86_64/include/vtk/vtk-6.1 
--with-vtk-lib=/opt/visit/2.13.3/linux-x86_64/lib    \/**/
/**/    --enable-exodus \/**/
/**/    --enable-triangle \/**/
/**/    --disable-boost \/**/
/**/    --disable-openmp \/**/
/**/    --disable-perflog \/**/
/**/    --disable-pthreads \/**/
/**/    --disable-strict-lgpl \/**/
/**/    --disable-glibcxx-debugging/*

*/make/*

*/make install/*








opt:

[Libmesh-users] [RB] Inner product assembly in RB example 5

[<ss...@pu...>]

Re: [Libmesh-users] question on nedelec elements

[Povolotskyi, M. <mpo...@pu...>]

Thank you, Paul.
If I want to have periodic boundary conditions for my application on a regular grid, can I do the following:

  1.  Find corresponding edges on the periodic sides
  2.  Get DOF numbers that correspond to those edges
  3.  Define DOF map constraints.

What do you think? Can it work?
(I have done something similar in 2004 with Lagrange elements because at that time periodic boundary conditions were not implemented in libmesh.)

Thank you,
Michael.

Sent from Mail<https://go.microsoft.com/fwlink/?LinkId=550986> for Windows 10

From: Paul T. Bauman<mailto:ptb...@gm...>
Sent: Thursday, March 14, 2019 9:07 PM
To: Povolotskyi, Mykhailo<mailto:mpo...@pu...>
Cc: Stogner, Roy H<mailto:roy...@ic...>; lib...@li...<mailto:lib...@li...>
Subject: Re: [Libmesh-users] question on nedelec elements

No I'm sorry they're not. The reason BCs/projection/periodic BCs wasn't immediately trivial is, mathematically, we can only enforce continuity of the tangential components of the solution and IIRC the was a pain to do consistently between 2D and 3D (at least enough that it wasn't something I could do in an afternoon or two, which is all I had once the elements were deployed and we could solve the problems of interest on that project).

I know there's some interest from some others as well, but I'm happy to give pointers to the places where the implementation of all these pieces are needed if someone has the time.

On Thu, Mar 14, 2019 at 4:32 PM Michael Povolotskyi <mpo...@pu...<mailto:mpo...@pu...>> wrote:

Hello Paul,

One more question, please. Are periodic boundary conditions supported for Nedelec?

Michael.
On 03/14/2019 03:28 PM, Paul T. Bauman wrote:


On Thu, Mar 14, 2019 at 3:14 PM Stogner, Roy H <roy...@ic...<mailto:roy...@ic...>> wrote:

On Thu, 14 Mar 2019, Michael Povolotskyi wrote:

> Thank you,

No, thank Paul; reading further down the code it appears that I'm
wrong, and Paul *did* add some kind of vector-valued variable field
support to the Dirichlet code.

vector_fe_ex2/laplace_system.C seems to be our only example of it's
use.

Unfortunately, though, it's not there for Nedelec. What's needed is the constraint enforcement for HCurl which I never got time to implement. :( So for Nedelec, penalty is the only way for Dirichlet boundary conditions right now. (It's also why refinement/coarsening won't work for Nedelec because I never got time to implement projection for those elements either. :( )

---
Roy


_______________________________________________
Libmesh-users mailing list
Lib...@li...<mailto:Lib...@li...>
https://lists.sourceforge.net/lists/listinfo/libmesh-users

Re: [Libmesh-users] question on nedelec elements

[Paul T. B. <ptb...@gm...>]

No I'm sorry they're not. The reason BCs/projection/periodic BCs wasn't
immediately trivial is, mathematically, we can only enforce continuity of
the tangential components of the solution and IIRC the was a pain to do
consistently between 2D and 3D (at least enough that it wasn't something I
could do in an afternoon or two, which is all I had once the elements were
deployed and we could solve the problems of interest on that project).

I know there's some interest from some others as well, but I'm happy to
give pointers to the places where the implementation of all these pieces
are needed if someone has the time.

On Thu, Mar 14, 2019 at 4:32 PM Michael Povolotskyi <mpo...@pu...>
wrote:

> Hello Paul,
>
> One more question, please. Are periodic boundary conditions supported for
> Nedelec?
> Michael.
> On 03/14/2019 03:28 PM, Paul T. Bauman wrote:
>
>
>
> On Thu, Mar 14, 2019 at 3:14 PM Stogner, Roy H <roy...@ic...>
> wrote:
>
>>
>> On Thu, 14 Mar 2019, Michael Povolotskyi wrote:
>>
>> > Thank you,
>>
>> No, thank Paul; reading further down the code it appears that I'm
>> wrong, and Paul *did* add some kind of vector-valued variable field
>> support to the Dirichlet code.
>>
>> vector_fe_ex2/laplace_system.C seems to be our only example of it's
>> use.
>>
>
> Unfortunately, though, it's not there for Nedelec. What's needed is the
> constraint enforcement for HCurl which I never got time to implement. :( So
> for Nedelec, penalty is the only way for Dirichlet boundary conditions
> right now. (It's also why refinement/coarsening won't work for Nedelec
> because I never got time to implement projection for those elements either.
> :( )
>
>
>> ---
>> Roy
>>
>>
>> _______________________________________________
>> Libmesh-users mailing list
>> Lib...@li...
>> https://lists.sourceforge.net/lists/listinfo/libmesh-users
>>
>
>

Re: [Libmesh-users] KSP convergence reason - DIVERGED_INDEFINITE_PC

[Stogner, R. H <roy...@ic...>]

On Thu, 14 Mar 2019, Renato Poli wrote:

> How do I change the dof ordering options?

"-pc_factor_mat_ordering_type string" with a string from
https://www.mcs.anl.gov/petsc/petsc-current/docs/manualpages/Mat/MatOrderingType.html#MatOrderingType

>       Add a SCALAR variable to use as a Lagrange multiplier?
> 
> This sounds like a much cleaner solution.
> I could not understand how to do that in libmesh so far.
> It is probably time to put some more effort here...
> 
> I see I must add a Kp_alpha matrix. Do I need the Kalpha_p as well?

Yes; the Kalpha_p ends up being what looks most like the actual
constraint equation.

...

Except you don't have a constraint *equation* here, you have
constraint *equations*.  You wouldn't want a SCALAR lagrange
multiplier, you'd want to add a LAGRANGE variable subdomain-restricted
to boundary elements along the constrained domain boundary... this is
sounding like more trouble than it's worth unless you can't get the
directly constrained solves to converge.
---
Roy

Re: [Libmesh-users] question on nedelec elements

[Michael P. <mpo...@pu...>]

Hello Paul,

One more question, please. Are periodic boundary conditions supported 
for Nedelec?

Michael.
On 03/14/2019 03:28 PM, Paul T. Bauman wrote:
>
>
> On Thu, Mar 14, 2019 at 3:14 PM Stogner, Roy H 
> <roy...@ic... <mailto:roy...@ic...>> wrote:
>
>
>     On Thu, 14 Mar 2019, Michael Povolotskyi wrote:
>
>     > Thank you,
>
>     No, thank Paul; reading further down the code it appears that I'm
>     wrong, and Paul *did* add some kind of vector-valued variable field
>     support to the Dirichlet code.
>
>     vector_fe_ex2/laplace_system.C seems to be our only example of it's
>     use.
>
>
> Unfortunately, though, it's not there for Nedelec. What's needed is 
> the constraint enforcement for HCurl which I never got time to 
> implement. :( So for Nedelec, penalty is the only way for Dirichlet 
> boundary conditions right now. (It's also why refinement/coarsening 
> won't work for Nedelec because I never got time to implement 
> projection for those elements either. :( )
>
>     ---
>     Roy
>
>
>     _______________________________________________
>     Libmesh-users mailing list
>     Lib...@li...
>     <mailto:Lib...@li...>
>     https://lists.sourceforge.net/lists/listinfo/libmesh-users
>

Re: [Libmesh-users] KSP convergence reason - DIVERGED_INDEFINITE_PC

[Renato P. <re...@gm...>]

Hi Roy,
Thanks for the reply.

On Wed, Mar 13, 2019 at 1:22 PM Stogner, Roy H <roy...@ic...>
wrote:

>
> On Wed, 13 Mar 2019, Renato Poli wrote:
>
> > In the same run (other timesteps), I also see DIVERGED_INDEFINITE_MAT.
> > In many timesteps it converges. It happens sometimes...
> > I am using LU preconditioners.
>
> Built-in PETSc LU?  If so then you might try MUMPS or you might try
> different dof ordering options; I've seen each of those fix LU
> failures in the past.
>

How do I change the dof ordering options?
I want to try this one before switching to MUMPS.



> > I have a 2D circumference inside the domain (petroleum wellbore).
> > I need to set a Neumann BC (total oil rate), but the pressure must be
> constant in the circumference.
>
> That... sounds like it'll be well-defined even in the discrete case
> (N-1 constraints for strong enforcement of that constant, 1 summed BC
> for total flow rate) but it couldn't hurt to check what the matrix
> conditioning looks like.
>

Agreed.


>
> > Similar to a distributed total force in a rigid plate - for mechanical
> solvers.
> >
> > My approach:
> > 1) select a DOF for the circumference.
> > 2) tie all other DOFs in the circumference to this one with
> "add_constrain_row".
>
> Darcy flow, using one LAGRANGE variable for pressure I assume?
>

Yes.


>
> > Can you see another way to do that?
>
> Add a SCALAR variable to use as a Lagrange multiplier?
>

This sounds like a much cleaner solution.
I could not understand how to do that in libmesh so far.
It is probably time to put some more effort here...

I see I must add a Kp_alpha matrix. Do I need the Kalpha_p as well?
My conditions are: p1=alpha , p2=alpha , p3=alpha , p4=alpha and so on.
How the last equation looks like?
I can imagine something like: p1 - p2 + p3 - p4 = 0
But that does not look right ...



>
> We don't have any examples corresponding to your case precisely but
> systems_of_equations_ex3 and ex5 might be helpful.
> ---
> Roy
>

Thanks upfront,
Renato

Re: [Libmesh-users] question on nedelec elements

[Vikram G. <vik...@gm...>]

Hello Michael,
                    If you want to estimate the error incurred due to
the use of the penalty method in a specific functional (say Q(u)), you
can do so by computing epsilon*Q( du/depsilon ). Here 1/epsilon is the
penalty we are setting. The function du/depsilon is the the derivative
of the solution with respect to epsilon.

If you are using FEMSystem, the quantity Q( du/depsilon ) can be
computed automatically using the
system.forward_qoi_parameter_sensitivity function.

For an example of its use, see adjoints_ex2.C and just replace
system.adjoint_qoi_parameter_sensitivity function with
system.forward_qoi_parameter_sensitivity function. You will also need
to store the penalty parameter in a parameter_vector as in L-shaped.h
and L-shaped.C.

The theory behind this is a Taylor series expansion for Q in terms of
epsilon about epsilon = 0, which is our non-penalized 'true'
functional.

Thanks.
Vikram Garg

vikramvgarg.github.io/

On Thu, Mar 14, 2019 at 2:12 PM Michael Povolotskyi <mpo...@pu...> wrote:
>
> Thank you Vikram,
>
> I'm solving the electromagnetic wave equation using Newmark system.
>
> What are forward_sensitivity_derivatives that you are talking about?
>
> Michael.
>
>
>
> On 03/14/2019 03:08 PM, Vikram Garg wrote:
> > If you are worried about accuracy issues due to the use of penalties,
> > then there are ways of quantifying these pretty well using
> > forward_sensitivity_derivatives, when taken with respect the penalty.
> >
> > Thanks.
> > Vikram Garg
> >
> > vikramvgarg.github.io/
> >
> > On Thu, Mar 14, 2019 at 2:03 PM Michael Povolotskyi <mpo...@pu...> wrote:
> >> Thank you,
> >>
> >> the penalty method is what I'm currently doing.
> >>
> >> Michael.
> >>
> >>
> >> On 03/14/2019 03:00 PM, Stogner, Roy H wrote:
> >>> On Thu, 14 Mar 2019, Michael Povolotskyi wrote:
> >>>
> >>>> is it possible to apply dirichlet boundary conditions for Nedelec elements?
> >>> I don't believe so - the former predate the latter and at quick glance
> >>> the code seems hardcoded to expect scalar variable fields.
> >>>
> >>> You might be stuck using a penalty method as a workaround.
> >>> ---
> >>> Roy
> >>
> >>
> >> _______________________________________________
> >> Libmesh-users mailing list
> >> Lib...@li...
> >> https://lists.sourceforge.net/lists/listinfo/libmesh-users
>

Re: [Libmesh-users] question on nedelec elements

[Paul T. B. <ptb...@gm...>]

On Thu, Mar 14, 2019 at 3:14 PM Stogner, Roy H <roy...@ic...>
wrote:

>
> On Thu, 14 Mar 2019, Michael Povolotskyi wrote:
>
> > Thank you,
>
> No, thank Paul; reading further down the code it appears that I'm
> wrong, and Paul *did* add some kind of vector-valued variable field
> support to the Dirichlet code.
>
> vector_fe_ex2/laplace_system.C seems to be our only example of it's
> use.
>

Unfortunately, though, it's not there for Nedelec. What's needed is the
constraint enforcement for HCurl which I never got time to implement. :( So
for Nedelec, penalty is the only way for Dirichlet boundary conditions
right now. (It's also why refinement/coarsening won't work for Nedelec
because I never got time to implement projection for those elements either.
:( )


> ---
> Roy
>
>
> _______________________________________________
> Libmesh-users mailing list
> Lib...@li...
> https://lists.sourceforge.net/lists/listinfo/libmesh-users
>

Re: [Libmesh-users] question on nedelec elements

[Stogner, R. H <roy...@ic...>]

On Thu, 14 Mar 2019, Michael Povolotskyi wrote:

> Thank you,

No, thank Paul; reading further down the code it appears that I'm
wrong, and Paul *did* add some kind of vector-valued variable field
support to the Dirichlet code.

vector_fe_ex2/laplace_system.C seems to be our only example of it's
use.
---
Roy

Re: [Libmesh-users] question on nedelec elements

[Michael P. <mpo...@pu...>]

Thank you Vikram,

I'm solving the electromagnetic wave equation using Newmark system.

What are forward_sensitivity_derivatives that you are talking about?

Michael.



On 03/14/2019 03:08 PM, Vikram Garg wrote:
> If you are worried about accuracy issues due to the use of penalties,
> then there are ways of quantifying these pretty well using
> forward_sensitivity_derivatives, when taken with respect the penalty.
>
> Thanks.
> Vikram Garg
>
> vikramvgarg.github.io/
>
> On Thu, Mar 14, 2019 at 2:03 PM Michael Povolotskyi <mpo...@pu...> wrote:
>> Thank you,
>>
>> the penalty method is what I'm currently doing.
>>
>> Michael.
>>
>>
>> On 03/14/2019 03:00 PM, Stogner, Roy H wrote:
>>> On Thu, 14 Mar 2019, Michael Povolotskyi wrote:
>>>
>>>> is it possible to apply dirichlet boundary conditions for Nedelec elements?
>>> I don't believe so - the former predate the latter and at quick glance
>>> the code seems hardcoded to expect scalar variable fields.
>>>
>>> You might be stuck using a penalty method as a workaround.
>>> ---
>>> Roy
>>
>>
>> _______________________________________________
>> Libmesh-users mailing list
>> Lib...@li...
>> https://lists.sourceforge.net/lists/listinfo/libmesh-users

Re: [Libmesh-users] question on nedelec elements

[Vikram G. <vik...@gm...>]

If you are worried about accuracy issues due to the use of penalties,
then there are ways of quantifying these pretty well using
forward_sensitivity_derivatives, when taken with respect the penalty.

Thanks.
Vikram Garg

vikramvgarg.github.io/

On Thu, Mar 14, 2019 at 2:03 PM Michael Povolotskyi <mpo...@pu...> wrote:
>
> Thank you,
>
> the penalty method is what I'm currently doing.
>
> Michael.
>
>
> On 03/14/2019 03:00 PM, Stogner, Roy H wrote:
> > On Thu, 14 Mar 2019, Michael Povolotskyi wrote:
> >
> >> is it possible to apply dirichlet boundary conditions for Nedelec elements?
> > I don't believe so - the former predate the latter and at quick glance
> > the code seems hardcoded to expect scalar variable fields.
> >
> > You might be stuck using a penalty method as a workaround.
> > ---
> > Roy
>
>
>
> _______________________________________________
> Libmesh-users mailing list
> Lib...@li...
> https://lists.sourceforge.net/lists/listinfo/libmesh-users

Re: [Libmesh-users] question on nedelec elements

[Michael P. <mpo...@pu...>]

Thank you,

the penalty method is what I'm currently doing.

Michael.


On 03/14/2019 03:00 PM, Stogner, Roy H wrote:
> On Thu, 14 Mar 2019, Michael Povolotskyi wrote:
>
>> is it possible to apply dirichlet boundary conditions for Nedelec elements?
> I don't believe so - the former predate the latter and at quick glance
> the code seems hardcoded to expect scalar variable fields.
>
> You might be stuck using a penalty method as a workaround.
> ---
> Roy

Re: [Libmesh-users] question on nedelec elements

[Stogner, R. H <roy...@ic...>]

On Thu, 14 Mar 2019, Michael Povolotskyi wrote:

> is it possible to apply dirichlet boundary conditions for Nedelec elements?

I don't believe so - the former predate the latter and at quick glance
the code seems hardcoded to expect scalar variable fields.

You might be stuck using a penalty method as a workaround.
---
Roy

[Libmesh-users] question on nedelec elements

[Michael P. <mpo...@pu...>]

Hello,

is it possible to apply dirichlet boundary conditions for Nedelec elements?

Thank you,

Michael.

Re: [Libmesh-users] KSP convergence reason - DIVERGED_INDEFINITE_PC

[Stogner, R. H <roy...@ic...>]

On Wed, 13 Mar 2019, Renato Poli wrote:

> In the same run (other timesteps), I also see DIVERGED_INDEFINITE_MAT.
> In many timesteps it converges. It happens sometimes...
> I am using LU preconditioners.

Built-in PETSc LU?  If so then you might try MUMPS or you might try
different dof ordering options; I've seen each of those fix LU
failures in the past.

> I have a 2D circumference inside the domain (petroleum wellbore).
> I need to set a Neumann BC (total oil rate), but the pressure must be constant in the circumference.

That... sounds like it'll be well-defined even in the discrete case
(N-1 constraints for strong enforcement of that constant, 1 summed BC
for total flow rate) but it couldn't hurt to check what the matrix
conditioning looks like.

> Similar to a distributed total force in a rigid plate - for mechanical solvers.
> 
> My approach:
> 1) select a DOF for the circumference.
> 2) tie all other DOFs in the circumference to this one with "add_constrain_row".

Darcy flow, using one LAGRANGE variable for pressure I assume?

> Can you see another way to do that?

Add a SCALAR variable to use as a Lagrange multiplier?

We don't have any examples corresponding to your case precisely but
systems_of_equations_ex3 and ex5 might be helpful.
---
Roy

Re: [Libmesh-users] KSP convergence reason - DIVERGED_INDEFINITE_PC

[Renato P. <re...@gm...>]

Well ...
In the same run (other timesteps), I also see DIVERGED_INDEFINITE_MAT.
In many timesteps it converges. It happens sometimes...
I am using LU preconditioners.

I have a 2D circumference inside the domain (petroleum wellbore).
I need to set a Neumann BC (total oil rate), but the pressure must be
constant in the circumference.
Similar to a distributed total force in a rigid plate - for mechanical
solvers.

My approach:
1) select a DOF for the circumference.
2) tie all other DOFs in the circumference to this one with
"add_constrain_row".

Can you see another way to do that?
I am in try-and-try approach already...

Renato

On Wed, Mar 13, 2019 at 10:34 AM Stogner, Roy H <roy...@ic...>
wrote:

>
> On Tue, 12 Mar 2019, Renato Poli wrote:
>
> > I see the message below, but I cannot identify the reason.
> > I know it is related to constrain_rows" I use to tie together the
> pressure
> > in a boundary.
> >
> >  0 KSP Residual norm 8.180571722215e+07
> >  1 KSP Residual norm 4.475923747576e+03
> >  2 KSP Residual norm 4.475912845013e+03
> > # Debug[1:0]:     Linear solver convergence/divergence reason:
> > DIVERGED_INDEFINITE_PC
> >
> > What that means?
> > Any suggestion on possible causes?
>
> IIRC that usually means you don't have an invertible preconditioner,
> which unless you were setting up a separate preconditioner means you
> don't have an invertible Jacobian.
> ---
> Roy
>