Mass lumping in Moose

126 views
Skip to first unread message

marco.delchini

unread,
May 25, 2015, 12:54:42 PM5/25/15
to moose...@googlegroups.com
Hello all,

can someone explain to me how the lumping of the mass matrix is done in Moose? I know the mass matrix is not explicitly built in Moose, but I cannot figure out how it is done and in which function it is done.

Thanks,
Marco

Andrs, David

unread,
May 26, 2015, 10:00:56 AM5/26/15
to moose...@googlegroups.com
Go look at TimeDerivative::computeJacobian()​.
​If you are running an explicit time integrator, your Jacobian will be your mass matrix.​


Thanks,
Marco

--
You received this message because you are subscribed to the Google Groups "moose-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to moose-users...@googlegroups.com.
Visit this group at http://groups.google.com/group/moose-users.
To view this discussion on the web visit https://groups.google.com/d/msgid/moose-users/120df113-07dc-4b91-86ab-ce4293209932%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Ragusa, Jean C

unread,
May 26, 2015, 10:09:33 AM5/26/15
to <moose-users@googlegroups.com>
Is that Jacobian consistent with the residual?

Thanks. 

Jean C. Ragusa
---
Sent from a handheld device. 

Andrs, David

unread,
May 26, 2015, 10:12:25 AM5/26/15
to moose...@googlegroups.com
On Tue, May 26, 2015 at 8:09 AM, Ragusa, Jean C <jean....@tamu.edu> wrote:
Is that Jacobian consistent with the residual?

​It is not (IIRC).
--
David​

 

Ragusa, Jean C

unread,
May 26, 2015, 10:46:57 AM5/26/15
to moose...@googlegroups.com

Thanks. That’s what I thought, too.

 

For people following the conservation on the list:

 

The residual is contains the action of the mass matrix on _u_dot but the way it is computed, it is the action of the unlumped mass matrix.

 

I think only the Jacobian is lumped, so there is a little inconsistency between the residual and the associated jacobian.

 

So, a quick follow-up: when explicit time stepping is used and lumping is chosen (and one has a time derivative kernel is linear with respect to the solution variable),  should one expect more than 1 nonlinear solve per time step increment?

 

Thanks

--jean

Andrs, David

unread,
May 26, 2015, 11:15:02 AM5/26/15
to moose...@googlegroups.com
On Tue, May 26, 2015 at 8:46 AM, Ragusa, Jean C <jean....@tamu.edu> wrote:

Thanks. That’s what I thought, too.

 

For people following the conservation on the list:

 

The residual is contains the action of the mass matrix on _u_dot but the way it is computed, it is the action of the unlumped mass matrix.

 

I think only the Jacobian is lumped, so there is a little inconsistency between the residual and the associated jacobian.

 

So, a quick follow-up: when explicit time stepping is used and lumping is chosen (and one has a time derivative kernel is linear with respect to the solution variable),  should one expect more than 1 nonlinear solve per time step increment?


I do not know what is the case for lumping.  If it is on, the best solve_type you can use is PJFNK. This ​may or may not give you more than 1 NL-iteration, try playing with l_tol param.

If lumping is off, you should be able to use solve_type=NEWTON (and LINEAR as well), which might give you faster run-time, but of course, you won't get the "benefits" of lumping.

Note that in both cases you will be using the same amount of memory for the Jacobian matrix (the optimization has not been implemented yet).

--
David

 

Marco Delchini

unread,
May 26, 2015, 12:46:05 PM5/26/15
to moose-users
Why is the mass matrix not lumped when the boolean 'lumping' is set to true in the input file? What is the logic behind it?

Also, I am writing a function to lump the mass matrix and I have a few questions:
  1. in the TimeDerivative kernel, the function ComputeQpResidual returns the value _phi[_i][_qp]*_u_dot[_qp]. My understanding is that _u_dot[_qp] = \sum_j \phi[_j][_qp]*dU/dt)_j where U_j are the nodal values of the solution U. Am I correct?
  2. In order to compute the lumped mass matrix terms, it would be easier if I had access to dU/dt)_j. Is it doable? Also, my understanding is that the term dU/dt)_j is computed from a time_integrator function (BDF2.C, rk-2.C, ....). Am I correct?
Thanks,
Marco


For more options, visit https://groups.google.com/d/optout.



--
DELCHINI Marc-Olivier
Graduate Student
Texas A&M University

Marco Delchini

unread,
May 26, 2015, 1:37:49 PM5/26/15
to moose-users
Can I use '_var.nodalSlnDot()' to initialize a variable in the constructor?

Marco

Cody Permann

unread,
May 26, 2015, 2:47:50 PM5/26/15
to moose-users
You may initialize a _reference_ to a "VariableValue" in the constructor but it must be a reference so that it maintains up to date values for each element. Additionally we do have an interface that you should use instead of calling these "MooseVariable" methods directly. Take a look at the methods available in "MooseVariableInterface", in this case you should call "dot()":

Cody


Andrs, David

unread,
May 26, 2015, 3:10:46 PM5/26/15
to moose...@googlegroups.com
On Tue, May 26, 2015 at 10:46 AM, Marco Delchini <marco.d...@gmail.com> wrote:
Why is the mass matrix not lumped when the boolean 'lumping' is set to true in the input file? What is the logic behind it?

Lumping is done then _lumping == true.​ ​Look at the code again...
 

Also, I am writing a function to lump the mass matrix and I have a few questions:
  1. in the TimeDerivative kernel, the function ComputeQpResidual returns the value _phi[_i][_qp]*_u_dot[_qp]. My understanding is that _u_dot[_qp] = \sum_j \phi[_j][_qp]*dU/dt)_j where U_j are the nodal values of the solution U. Am I correct?
​Correct.​
 
  1. In order to compute the lumped mass matrix terms, it would be easier if I had access to dU/dt)_j. Is it doable? Also, my understanding is that the term dU/dt)_j is computed from a time_integrator function (BDF2.C, rk-2.C, ....). Am I correct?
​To get the nodal values, we have coupledNodalValue()​, but we do not provide coupledNodalDot. In case you use TRAP, FIRST quadrature rule, coupledDot() should have the nodal values of u_dot.

 

Marco Delchini

unread,
May 26, 2015, 4:49:36 PM5/26/15
to moose-users
Lumping is done then _lumping == true.​ ​Look at the code again...
 The lumping is only done on the jacobian matrix whereas it should also be done on the mass matrix that is used to compute the residual.

I had a look at the class MooseVariableInterface and try to initialize a variable called '_u_dot_nodal' with 'dot()' that returns 'dUdt)_j' if the variable is a nodal variable. It returns _u_dot otherwise. When I output the values of 'u_dot_nodal' I get the values at the quadrature points. I would expect to get the values at the nodes instead. What am I missing here?

Marco

 

Cody Permann

unread,
May 26, 2015, 6:03:37 PM5/26/15
to moose...@googlegroups.com
Right, when you index into any of our VariableValue references, they are filled with values at the quadrature points since that's where we normally evaluate for computing the residual.

Cody

--
You received this message because you are subscribed to the Google Groups "moose-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to moose-users...@googlegroups.com.
Visit this group at http://groups.google.com/group/moose-users.

Andrew....@csiro.au

unread,
May 26, 2015, 6:20:38 PM5/26/15
to moose...@googlegroups.com

Hi,

 

I have implemented proper mass lumping in the “richards” module.  Viz

 

modules/richards/src/kernels/RichardsLumpedMassChange.C

 

It is probably more complicated than most people need, as this kernel can handle an arbitrary number of variables, which are called _ps_at_nodes.  Nevertheless, the code might act as a useful reference to other coders.

 

Wish-list:  I feel the lack of easily-available and efficient mass lumping in MOOSE is a real failing.  It seems like every month someone mentions it since it’s a standard way of getting round numerical difficulties.  It’d be fantastic if libmesh could provide this feature.

 

a

 

 

Ph: +61 7 3327 4497.  Fax: +61 7 3327 4666
Queensland Centre for Advanced Technologies
PO Box 883, Kenmore, Qld, 4069 
 

From: moose...@googlegroups.com [mailto:moose...@googlegroups.com] On Behalf Of Cody Permann
Sent: Wednesday, 27 May 2015 8:04 AM
To: moose...@googlegroups.com
Subject: Re: Mass lumping in Moose

 

Right, when you index into any of our VariableValue references, they are filled with values at the quadrature points since that's where we normally evaluate for computing the residual.

 

Cody

Andrs, David

unread,
May 26, 2015, 6:42:10 PM5/26/15
to moose...@googlegroups.com
On Tue, May 26, 2015 at 4:20 PM, <Andrew....@csiro.au> wrote:

Hi,

 

I have implemented proper mass lumping in the “richards” module.  Viz

 

modules/richards/src/kernels/RichardsLumpedMassChange.C

 

It is probably more complicated than most people need, as this kernel can handle an arbitrary number of variables, which are called _ps_at_nodes.  Nevertheless, the code might act as a useful reference to other coders.

 

Wish-list:  I feel the lack of easily-available and efficient mass lumping in MOOSE is a real failing.  It seems like every month someone mentions it since it’s a standard way of getting round numerical difficulties.  It’d be fantastic if libmesh could provide this feature.


​Two things Andy:

1) If I read your code correctly, you compute your own nodal values of u_dot in your kernel​. We do not currently provide those from MOOSE's interface, but that should not be hard to add. We already (by your request) provide nodal values of variables (I guess we just forgot about u_dot when we worked on it). 

2) In your kernel you return 0 for off-diagonal entries of the local mass matrix. As I was told by Rich, the off-diagonal items should be added to the diagonal ones, which is what we do in TimeDerivative kernel. So what is the story here?

--
David

 

Andrew....@csiro.au

unread,
May 26, 2015, 6:52:43 PM5/26/15
to moose...@googlegroups.com

(1) I don’t actually need _u_dot : i’d prefer to explicitly calculate \dot{mass} in the way i do in order to ensure mass conservation (my “mass” is a nonlinear function of “u”).  I know the nodal variables are available, but the code still looks crazily inefficient and complicated.

 

(2) I return zero because the mass at one node doesn’t depend on the variables at another node (which is the principal of mass lumping).  Your method of adding the off-diagonal entries to the diagonal ones achieves a similar goal, but your residual is not mass-lumped.

 

a

 

 

Ph: +61 7 3327 4497.  Fax: +61 7 3327 4666
Queensland Centre for Advanced Technologies
PO Box 883, Kenmore, Qld, 4069 
 

Marco Delchini

unread,
May 26, 2015, 9:07:30 PM5/26/15
to moose-users
Thanks Andrew for the information. I will have a look at it.

I agree with Andrew, the residual is not mass-lumped as it is currently implemented in Moose.

Marco


For more options, visit https://groups.google.com/d/optout.



--

Marco Delchini

unread,
May 26, 2015, 9:12:30 PM5/26/15
to moose-users
Andrew,

the function RichardLumpedMassChange.C, can only be used with forward and backward Euler. Am I correct?

Marco

Andrew....@csiro.au

unread,
May 26, 2015, 10:20:13 PM5/26/15
to moose...@googlegroups.com

yes, you are correct Marco (as far as i know anyway!).  i only use those in my work so it’s not a problem for me.

 

a

 

 

Ph: +61 7 3327 4497.  Fax: +61 7 3327 4666
Queensland Centre for Advanced Technologies
PO Box 883, Kenmore, Qld, 4069 
 

Andrs, David

unread,
May 27, 2015, 10:21:38 AM5/27/15
to moose...@googlegroups.com
On Tue, May 26, 2015 at 7:07 PM, Marco Delchini <marco.d...@gmail.com> wrote:
Thanks Andrew for the information. I will have a look at it.

I agree with Andrew, the residual is not mass-lumped as it is currently implemented in Moose.

Well, nobody claimed we mass-lump​ the residual. That was kind of the conclusion of the conversation between me and Jean early in this thread...
--
David

 

Marco Delchini

unread,
May 27, 2015, 10:27:18 AM5/27/15
to moose-users
Well, in that case, does it make sense to call it 'lumping' since you do not lump the mass matrix in the residual? It can be very confusing.

Marco


For more options, visit https://groups.google.com/d/optout.

Andrs, David

unread,
May 27, 2015, 10:28:32 AM5/27/15
to moose...@googlegroups.com
On Tue, May 26, 2015 at 8:20 PM, <Andrew....@csiro.au> wrote:

yes, you are correct Marco (as far as i know anyway!).  i only use those in my work so it’s not a problem for me.


​Hmmm, so when I offered you ​u_dot at nodes so you can have your kernel independent on the time integrator, you said you did not need it. This sounds like the opposite, man ;-) Sorry, I could not resist ;-D
​--
David​

 

Andrs, David

unread,
May 27, 2015, 10:34:38 AM5/27/15
to moose...@googlegroups.com
On Wed, May 27, 2015 at 8:27 AM, Marco Delchini <marco.d...@gmail.com> wrote:
Well, in that case, does it make sense to call it 'lumping' since you do not lump the mass matrix in the residual? It can be very confusing.

​The lumping capability is limited now. It can be only used for preconditioning as I wrote in one of my previous emails.
There is an open ticket in the issue tracker to finish lumping. So, it will stand to its name when the ticket is finished...
--
David

 

Marco Delchini

unread,
May 27, 2015, 12:48:08 PM5/27/15
to moose-users
David,

I believe you are referring to one of your previous reply in this conversation. I need the lumping of the mass matrix to be independent of the quadrature rule. I understand that by using TRAP and FIRST in my input file, and calling the coupledDot() in the constructor it will give me access to dU/dt)_j (the temporal derivative at the nodal value j). It will, however, also affect the other kernels of my input file unless you can choose a different quadrature rule for each kernel.

Having access to dU/dt)_j would be great since it would make the function work for most of the temporal integrators.

Marco


For more options, visit https://groups.google.com/d/optout.

Andrew....@csiro.au

unread,
May 27, 2015, 4:41:22 PM5/27/15
to moose...@googlegroups.com
Marco, you can only have one quadrature rule per variable (bummer).

a

________________________________________
From: moose...@googlegroups.com [moose...@googlegroups.com] on behalf of Marco Delchini [marco.d...@gmail.com]
Sent: Thursday, 28 May 2015 2:48 AM
To: moose-users
Subject: Re: Mass lumping in Moose

David,

I believe you are referring to one of your previous reply in this conversation. I need the lumping of the mass matrix to be independent of the quadrature rule. I understand that by using TRAP and FIRST in my input file, and calling the coupledDot() in the constructor it will give me access to dU/dt)_j (the temporal derivative at the nodal value j). It will, however, also affect the other kernels of my input file unless you can choose a different quadrature rule for each kernel.

Having access to dU/dt)_j would be great since it would make the function work for most of the temporal integrators.

Marco

On Wed, May 27, 2015 at 9:34 AM, Andrs, David <david...@inl.gov<mailto:david...@inl.gov>> wrote:
On Wed, May 27, 2015 at 8:27 AM, Marco Delchini <marco.d...@gmail.com<mailto:marco.d...@gmail.com>> wrote:
Well, in that case, does it make sense to call it 'lumping' since you do not lump the mass matrix in the residual? It can be very confusing.

​The lumping capability is limited now. It can be only used for preconditioning as I wrote in one of my previous emails.
There is an open ticket in the issue tracker to finish lumping. So, it will stand to its name when the ticket is finished...
--
David



Marco

On Wed, May 27, 2015 at 9:21 AM, Andrs, David <david...@inl.gov<mailto:david...@inl.gov>> wrote:
On Tue, May 26, 2015 at 7:07 PM, Marco Delchini <marco.d...@gmail.com<mailto:marco.d...@gmail.com>> wrote:
Thanks Andrew for the information. I will have a look at it.

I agree with Andrew, the residual is not mass-lumped as it is currently implemented in Moose.

Well, nobody claimed we mass-lump​ the residual. That was kind of the conclusion of the conversation between me and Jean early in this thread...
--
David



Marco

On Tue, May 26, 2015 at 5:52 PM, <Andrew....@csiro.au<mailto:Andrew....@csiro.au>> wrote:
(1) I don’t actually need _u_dot : i’d prefer to explicitly calculate \dot{mass} in the way i do in order to ensure mass conservation (my “mass” is a nonlinear function of “u”). I know the nodal variables are available, but the code still looks crazily inefficient and complicated.

(2) I return zero because the mass at one node doesn’t depend on the variables at another node (which is the principal of mass lumping). Your method of adding the off-diagonal entries to the diagonal ones achieves a similar goal, but your residual is not mass-lumped.

a


Ph: +61 7 3327 4497<tel:%2B61%207%203327%204497>. Fax: +61 7 3327 4666<tel:%2B61%207%203327%204666>
Queensland Centre for Advanced Technologies
PO Box 883, Kenmore, Qld, 4069

From: moose...@googlegroups.com<mailto:moose...@googlegroups.com> [mailto:moose...@googlegroups.com<mailto:moose...@googlegroups.com>] On Behalf Of Andrs, David
Sent: Wednesday, 27 May 2015 8:42 AM

To: moose...@googlegroups.com<mailto:moose...@googlegroups.com>
Subject: Re: Mass lumping in Moose

On Tue, May 26, 2015 at 4:20 PM, <Andrew....@csiro.au<mailto:Andrew....@csiro.au>> wrote:
Hi,

I have implemented proper mass lumping in the “richards” module. Viz

modules/richards/src/kernels/RichardsLumpedMassChange.C

It is probably more complicated than most people need, as this kernel can handle an arbitrary number of variables, which are called _ps_at_nodes. Nevertheless, the code might act as a useful reference to other coders.

Wish-list: I feel the lack of easily-available and efficient mass lumping in MOOSE is a real failing. It seems like every month someone mentions it since it’s a standard way of getting round numerical difficulties. It’d be fantastic if libmesh could provide this feature.

​Two things Andy:

1) If I read your code correctly, you compute your own nodal values of u_dot in your kernel​. We do not currently provide those from MOOSE's interface, but that should not be hard to add. We already (by your request) provide nodal values of variables (I guess we just forgot about u_dot when we worked on it).

2) In your kernel you return 0 for off-diagonal entries of the local mass matrix. As I was told by Rich, the off-diagonal items should be added to the diagonal ones, which is what we do in TimeDerivative kernel. So what is the story here?

--
David



a


Ph: +61 7 3327 4497<tel:%2B61%207%203327%204497>. Fax: +61 7 3327 4666<tel:%2B61%207%203327%204666>
Queensland Centre for Advanced Technologies
PO Box 883, Kenmore, Qld, 4069

From: moose...@googlegroups.com<mailto:moose...@googlegroups.com> [mailto:moose...@googlegroups.com<mailto:moose...@googlegroups.com>] On Behalf Of Cody Permann
Sent: Wednesday, 27 May 2015 8:04 AM
To: moose...@googlegroups.com<mailto:moose...@googlegroups.com>
Subject: Re: Mass lumping in Moose

Right, when you index into any of our VariableValue references, they are filled with values at the quadrature points since that's where we normally evaluate for computing the residual.

Cody

On Tue, May 26, 2015 at 2:49 PM Marco Delchini <marco.d...@gmail.com<mailto:marco.d...@gmail.com>> wrote:
Lumping is done then _lumping == true.​ ​Look at the code again...
The lumping is only done on the jacobian matrix whereas it should also be done on the mass matrix that is used to compute the residual.

I had a look at the class MooseVariableInterface and try to initialize a variable called '_u_dot_nodal' with 'dot()' that returns 'dUdt)_j' if the variable is a nodal variable. It returns _u_dot otherwise. When I output the values of 'u_dot_nodal' I get the values at the quadrature points. I would expect to get the values at the nodes instead. What am I missing here?

Marco


--
You received this message because you are subscribed to the Google Groups "moose-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to moose-users...@googlegroups.com<mailto:moose-users...@googlegroups.com>.
To view this discussion on the web visit https://groups.google.com/d/msgid/moose-users/CAPGU_kDw8ypUZburVCMFDZrJGb3VgGrR8JwSUCQ6HG7wm7JOig%40mail.gmail.com<https://groups.google.com/d/msgid/moose-users/CAPGU_kDw8ypUZburVCMFDZrJGb3VgGrR8JwSUCQ6HG7wm7JOig%40mail.gmail.com?utm_medium=email&utm_source=footer>.
For more options, visit https://groups.google.com/d/optout.
--
You received this message because you are subscribed to the Google Groups "moose-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to moose-users...@googlegroups.com<mailto:moose-users...@googlegroups.com>.
To view this discussion on the web visit https://groups.google.com/d/msgid/moose-users/CAK06EuWfODH5uustK3%2BeX1_2s_kaQtGUz_P4JCefCcLubDuHxA%40mail.gmail.com<https://groups.google.com/d/msgid/moose-users/CAK06EuWfODH5uustK3%2BeX1_2s_kaQtGUz_P4JCefCcLubDuHxA%40mail.gmail.com?utm_medium=email&utm_source=footer>.
For more options, visit https://groups.google.com/d/optout.
--
You received this message because you are subscribed to the Google Groups "moose-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to moose-users...@googlegroups.com<mailto:moose-users...@googlegroups.com>.
To view this discussion on the web visit https://groups.google.com/d/msgid/moose-users/57596E6532C9F54F9DF09BCDFE7B1D3AA25648F0%40exmbx06-cdc.nexus.csiro.au<https://groups.google.com/d/msgid/moose-users/57596E6532C9F54F9DF09BCDFE7B1D3AA25648F0%40exmbx06-cdc.nexus.csiro.au?utm_medium=email&utm_source=footer>.

For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "moose-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to moose-users...@googlegroups.com<mailto:moose-users...@googlegroups.com>.
To view this discussion on the web visit https://groups.google.com/d/msgid/moose-users/CADJmAN-PWMj-qjarwRu%2BCzCFCjsPaKDkiugjxJ%2B%2B0LO7EESaCw%40mail.gmail.com<https://groups.google.com/d/msgid/moose-users/CADJmAN-PWMj-qjarwRu%2BCzCFCjsPaKDkiugjxJ%2B%2B0LO7EESaCw%40mail.gmail.com?utm_medium=email&utm_source=footer>.
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "moose-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to moose-users...@googlegroups.com<mailto:moose-users...@googlegroups.com>.
To view this discussion on the web visit https://groups.google.com/d/msgid/moose-users/57596E6532C9F54F9DF09BCDFE7B1D3AA25649B6%40exmbx06-cdc.nexus.csiro.au<https://groups.google.com/d/msgid/moose-users/57596E6532C9F54F9DF09BCDFE7B1D3AA25649B6%40exmbx06-cdc.nexus.csiro.au?utm_medium=email&utm_source=footer>.

For more options, visit https://groups.google.com/d/optout.



--
DELCHINI Marc-Olivier
Graduate Student
Texas A&M University

--
You received this message because you are subscribed to the Google Groups "moose-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to moose-users...@googlegroups.com<mailto:moose-users...@googlegroups.com>.
To view this discussion on the web visit https://groups.google.com/d/msgid/moose-users/CAPGU_kC2ZFFQGu2DXqv4FUyzeHmeKXGq3KNAw7TMkB0MZP3V7A%40mail.gmail.com<https://groups.google.com/d/msgid/moose-users/CAPGU_kC2ZFFQGu2DXqv4FUyzeHmeKXGq3KNAw7TMkB0MZP3V7A%40mail.gmail.com?utm_medium=email&utm_source=footer>.

For more options, visit https://groups.google.com/d/optout.


--
You received this message because you are subscribed to the Google Groups "moose-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to moose-users...@googlegroups.com<mailto:moose-users...@googlegroups.com>.
To view this discussion on the web visit https://groups.google.com/d/msgid/moose-users/CADJmAN-N8Vm9NSdOumyZ4M9ZR3nEM8bu-UtLV2%3D24dnKi_mb_g%40mail.gmail.com<https://groups.google.com/d/msgid/moose-users/CADJmAN-N8Vm9NSdOumyZ4M9ZR3nEM8bu-UtLV2%3D24dnKi_mb_g%40mail.gmail.com?utm_medium=email&utm_source=footer>.

For more options, visit https://groups.google.com/d/optout.



--
DELCHINI Marc-Olivier
Graduate Student
Texas A&M University

--
You received this message because you are subscribed to the Google Groups "moose-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to moose-users...@googlegroups.com<mailto:moose-users...@googlegroups.com>.
To view this discussion on the web visit https://groups.google.com/d/msgid/moose-users/CAPGU_kDYoTbYe25dca4_kZRopQJ3Ck0msZNkQDxcrM4Kv93UEg%40mail.gmail.com<https://groups.google.com/d/msgid/moose-users/CAPGU_kDYoTbYe25dca4_kZRopQJ3Ck0msZNkQDxcrM4Kv93UEg%40mail.gmail.com?utm_medium=email&utm_source=footer>.

For more options, visit https://groups.google.com/d/optout.


--
You received this message because you are subscribed to the Google Groups "moose-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to moose-users...@googlegroups.com<mailto:moose-users...@googlegroups.com>.
To view this discussion on the web visit https://groups.google.com/d/msgid/moose-users/CADJmAN-AiWX5QpK3gPCusW6Lm7inkT7d3DRa5KHs%2BVEupFsG%2BA%40mail.gmail.com<https://groups.google.com/d/msgid/moose-users/CADJmAN-AiWX5QpK3gPCusW6Lm7inkT7d3DRa5KHs%2BVEupFsG%2BA%40mail.gmail.com?utm_medium=email&utm_source=footer>.

For more options, visit https://groups.google.com/d/optout.



--
DELCHINI Marc-Olivier
Graduate Student
Texas A&M University

--
You received this message because you are subscribed to the Google Groups "moose-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to moose-users...@googlegroups.com<mailto:moose-users...@googlegroups.com>.
To view this discussion on the web visit https://groups.google.com/d/msgid/moose-users/CAPGU_kCYmuRBhWoQm59vDQvq7p5nNNVUnQgg0aWhMEcKq%3DAigA%40mail.gmail.com<https://groups.google.com/d/msgid/moose-users/CAPGU_kCYmuRBhWoQm59vDQvq7p5nNNVUnQgg0aWhMEcKq%3DAigA%40mail.gmail.com?utm_medium=email&utm_source=footer>.

Andrs, David

unread,
Jun 12, 2015, 5:32:16 PM6/12/15
to moose...@googlegroups.com
For all interested parties in this, we recently merged a PR to enable consistent mass lumping, see https://github.com/idaholab/moose/pull/5232

Just FYI,
--
David

To unsubscribe from this group and stop receiving emails from it, send an email to moose-users...@googlegroups.com.
Reply all
Reply to author
Forward
0 new messages