Specifying a bound on a variable
john.m...@uconn.edu
Indeed my solver converges for some time (no complaints from analyzejacobian), but the angles themselves start diverging to +/- infinity all the while still satisfying the residual minimization . So the evolution is wrong and unphysical, since angles begin hopping around and the convergence problems appear.
John Peterson
Sebastian Schunert
--
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+unsubscribe@googlegroups.com.
Visit this group at https://groups.google.com/group/moose-users.
To view this discussion on the web visit https://groups.google.com/d/msgid/moose-users/4d018887-af82-4711-b529-e0b65cb051dd%40googlegroups.com.
Andrew....@csiro.au
(1) Use PETSc variational inequalities (eg SNESVINEWTONRSLS). I have had mixed luck with these in the past. For some particular models they worked OK and for others they made the nonlinear convergence super bad, and i couldn't fully understand why. That really made them unusable for "production runs" by my users who couldn't care less about linear algebra, etc. I'm pretty sure the PETSc team has significantly enhanced them recently, so you may have a much better experience than me. And part of the reason for suggesting this is that i'm hoping a MOOSE user will spend time trying this approach again and report back with recipes for success!
(2) A very easy approach is to override FEProblemBase, most specifically updateSolution. You can see a surprisingly well-documented example of this in modules/richards/src/base/RichardsMultiphaseProblem.C . That particular class puts a contraint u<=v where u and v are two Nonlinear Variables, but you just want -Pi<u<=Pi which will be slightly simpler.
a
From: 'Sebastian Schunert' via moose-users <moose...@googlegroups.com>
Sent: Wednesday, 25 July 2018 1:36 AM
To: moose...@googlegroups.com
Subject: Re: Specifying a bound on a variable
Why don't you just strip off multiples of 2 * pi before using them? This could be done in your specified kernels and if coupling them you can use a proxy AuxVar that is computed exactly like that.
Could that work?
2018-07-24 8:18 GMT-06:00 John Peterson <jwpet...@gmail.com>:
On Tuesday, July 24, 2018 at 7:47:13 AM UTC-6, john.m...@uconn.edu wrote:
Hello,
I've written something "simple" so far to solve a system of equations in spherical coordinates (LLG equations for micromagnetism). We require the solution vector to be normalized to one, so performing the calculations on the unit sphere is a natural way of solving the problem. It avoids having to use Constraints. It even reduces the number of nonlinear variables!
However, we have a number of residual terms that include \cos{\theta}, \sin{\phi} and so on. Note that since the angles aren't prescribed unique, the solver seems to find all sorts of possibilities (ex, \phi + 2 n \pi where n is integer still satisfies the residual).
Indeed my solver converges for some time (no complaints from analyzejacobian), but the angles themselves start diverging to +/- infinity all the while still satisfying the residual minimization . So the evolution is wrong and unphysical, since angles begin hopping around and the convergence problems appear.
Is there a trick to force these variables to be constrained (?) to their respective {0,2\pi}, {0, \pi} domains?
Or... is it back to cartesian drawing board with Constraints? Or another thought is that this could have to do with the timestepper, which I've played with and seem to get this regardless of what dt step size or scheme I use.
I wonder if Dampers would be a easy-to-implement solution to your problem? Perhaps by not allowing the full Newton step you may converge to a new solution that is "closer" to the current solution rather than being off by 2*pi?
Another idea might be to try adding a residual penalty term of some sort that gets "activated" when angles go outside the range (0,2pi) but is inactive otherwise.
--
John
--
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 https://groups.google.com/group/moose-users.
To view this discussion on the web visit https://groups.google.com/d/msgid/moose-users/4d018887-af82-4711-b529-e0b65cb051dd%40googlegroups.com.
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.
Visit this group at https://groups.google.com/group/moose-users.
To view this discussion on the web visit https://groups.google.com/d/msgid/moose-users/CACOt%3DcX3v5r3y0pmNibqA2t1CmQSM%3DeQAt__vSfjiXAN32UWLQ%40mail.gmail.com.
john.m...@uconn.edu
John Mangeri
--
You received this message because you are subscribed to a topic in the Google Groups "moose-users" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/moose-users/Kzimz-HcK2s/unsubscribe.
To unsubscribe from this group and all its topics, send an email to moose-users+unsubscribe@googlegroups.com.
Visit this group at https://groups.google.com/group/moose-users.
To view this discussion on the web visit https://groups.google.com/d/msgid/moose-users/b37daed5-b5ba-42a7-a76a-5dc9eaeca90e%40googlegroups.com.
Chris Green
john.m...@uconn.edu
On Tuesday, July 24, 2018 at 3:47:13 PM UTC+2, john.m...@uconn.edu wrote:
john.m...@uconn.edu
type = RandomIC
min = 0.0
max = 1.0
[../]
soln2 = 0.301538
soln1 = 46.605
soln2 = -0.6537
soln1 = 12.9174
soln2 = -6.85887
soln1 = 5.15262
soln2 = -1.90703
soln1 = 12.292
soln2 = -6.50531
soln1 = 4.3156
soln2 = -2.04323
soln1 = 4.61197
soln2 = -0.723839
soln1 = 4.01611
soln2 = -0.662192
soln1 = 12.6842
soln2 = -8.45721
soln1 = 13.798
soln2 = -8.48124
soln1 = 10.7664
soln2 = 9.01487
soln1 = 10.766
soln2 = 9.03845
soln1 = 10.9902
soln2 = -8.32971
soln1 = 10.1037
soln2 = -8.08512
soln1 = 3.55313
On Tuesday, July 24, 2018 at 3:47:13 PM UTC+2, john.m...@uconn.edu wrote:
Andrew....@csiro.au
// soln[0] is the value of the bounded variable at this node
// soln[1] is the value of the lower variable at this node
To check whether this works, you could use RichardsMultiphaseProblem verbatim, defining a Variable that initialises to 0, and just has a TimeKernel attached to it so it stays fixed at 0. That is your "lower_var". Then your "bounded_var" is your actual Variable that you're interested in bounding. You should always see that your bounded_var>=0.
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 john.m...@uconn.edu
Sent: Wednesday, 25 July 2018 8:58 PM
To: moose-users <moose...@googlegroups.com>
Subject: Re: Specifying a bound on a variable
You received this message because you are subscribed to the Google Groups "moose-users" group.
John Mangeri
Visit this group at https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgroups.google.com%2Fgroup%2Fmoose-users&data=02%7C01%7Cjohn.mangeri%40uconn.edu%7C9173a9696160459fcab308d5f287c816%7C17f1a87e2a254eaab9df9d439034b080%7C0%7C1%7C636681587373321704&sdata=r4SgcOM4k7Vo2nI57jv%2FtUxB7v%2BmkYQFcBGSlYz%2FOR4%3D&reserved=0.
To view this discussion on the web visit https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgroups.google.com%2Fd%2Fmsgid%2Fmoose-users%2F7ccdebc9-c66d-4b32-b818-128c30971363%2540googlegroups.com&data=02%7C01%7Cjohn.mangeri%40uconn.edu%7C9173a9696160459fcab308d5f287c816%7C17f1a87e2a254eaab9df9d439034b080%7C0%7C1%7C636681587373321704&sdata=WbqM%2Bb1HMqiL9D6CUJDIKFRXcdp8t%2FXY%2By739SNF70k%3D&reserved=0.
For more options, visit https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgroups.google.com%2Fd%2Foptout&data=02%7C01%7Cjohn.mangeri%40uconn.edu%7C9173a9696160459fcab308d5f287c816%7C17f1a87e2a254eaab9df9d439034b080%7C0%7C1%7C636681587373321704&sdata=6559wGAvANzEqK4Lxftt0FQo3SpRCWgFZKDtlP3%2BUEg%3D&reserved=0.
--
You received this message because you are subscribed to a topic in the Google Groups "moose-users" group.
To unsubscribe from this topic, visit https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgroups.google.com%2Fd%2Ftopic%2Fmoose-users%2FKzimz-HcK2s%2Funsubscribe&data=02%7C01%7Cjohn.mangeri%40uconn.edu%7C9173a9696160459fcab308d5f287c816%7C17f1a87e2a254eaab9df9d439034b080%7C0%7C1%7C636681587373321704&sdata=oqnpICFLQXx8IdhDVcPSQpJ8rToCrMHmoblSlEQYWQE%3D&reserved=0.
To unsubscribe from this group and all its topics, send an email to moose-users...@googlegroups.com.
Visit this group at https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgroups.google.com%2Fgroup%2Fmoose-users&data=02%7C01%7Cjohn.mangeri%40uconn.edu%7C9173a9696160459fcab308d5f287c816%7C17f1a87e2a254eaab9df9d439034b080%7C0%7C1%7C636681587373321704&sdata=r4SgcOM4k7Vo2nI57jv%2FtUxB7v%2BmkYQFcBGSlYz%2FOR4%3D&reserved=0.
To view this discussion on the web visit https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgroups.google.com%2Fd%2Fmsgid%2Fmoose-users%2Fc56ee36210084576bd8ba8e88a7c8a09%2540exch3-cdc.nexus.csiro.au&data=02%7C01%7Cjohn.mangeri%40uconn.edu%7C9173a9696160459fcab308d5f287c816%7C17f1a87e2a254eaab9df9d439034b080%7C0%7C1%7C636681587373321704&sdata=EyGjcjrzfeW0YR%2B66L2iAYDx5Cv6HDkjmbR%2BHn7BwsI%3D&reserved=0.
For more options, visit https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgroups.google.com%2Fd%2Foptout&data=02%7C01%7Cjohn.mangeri%40uconn.edu%7C9173a9696160459fcab308d5f287c816%7C17f1a87e2a254eaab9df9d439034b080%7C0%7C1%7C636681587373331705&sdata=1lKsZ9jqSc5mxmF3KgqelkIGS%2BfD7YEzNMHw7BV7ku0%3D&reserved=0.
john.m...@uconn.edu
FerretProblem::updateSolution(NumericVector<Number> & vec_solution, NumericVector<Number> & ghosted_solution)
{
bool updatedSolution =
false; // this gets set to true if we needed to enforce the bound at any node
unsigned int sys_num = getNonlinearSystemBase().number();
// For parallel procs i believe that i have to use local_nodes_begin, rather than just nodes_begin
// _mesh comes from SystemBase (_mesh = getNonlinearSystemBase().subproblem().mesh(), and
// subproblem is this object)
for (const auto & node : _mesh.getMesh().local_node_ptr_range())
{
// dofs[0] is the dof number of the polar variable at this node
// dofs[1] is the dof number of the azimuthal variable at this node
std::vector<dof_id_type> dofs(2);
dofs[0] = node->dof_number(sys_num, _polar_var_num, 0);
dofs[1] = node->dof_number(sys_num, _azimuthal_var_num, 0);
// soln[0] is the value of the polar variable at this node
// soln[1] is the value of the azimuthal variable at this node
std::vector<Number> soln(2);
vec_solution.get(dofs, soln);
if (soln[0] > libMesh::pi)
{
vec_solution.set(dofs[0], soln[0] - libMesh::pi); // polar var moved above pi so set back in range (0,pi)
updatedSolution = true;
}
}
// The above vec_solution.set calls potentially added "set" commands to a queue
// The following actions the queue (doing MPI commands if necessary), so
// vec_solution will actually be modified by this following command
vec_solution.close();
// if any proc updated the solution, all procs will know about it
_communicator.max(updatedSolution);
if (updatedSolution)
{
ghosted_solution = vec_solution;
ghosted_solution.close();
}
return updatedSolution;
}
soln[0] < 0.0? Just another else if loop or can updatedSolution be used simultaneously like that?Fande Kong
You may do something if solution is less than 0:
{
vec_solution.set(dofs[], -soln[]); // polar var moved above pi so set back in range (0,pi)
updatedSolution = true;
}
But I would like to reformulate the constraints into a regular nonlinear system of equations using NCP https://en.wikipedia.org/wiki/Nonlinear_complementarity_problem.
You can also try vinewtonssls, but it does not support matrix-free right now. There is an example:
moose/test/tests/auxkernels/bounds:
Fande,
Sent: Thursday, July 26, 2018 5:01:31 AM
To: moose-users
Subject: Re: Specifying a bound on a variable
FerretProblem::updateSolution(NumericVector<Number>
& vec_solution,
NumericVector<Number>
& ghosted_solution)
{
bool updatedSolution
=
false;
// this gets set to true if we needed to enforce the bound at any node
unsigned
int sys_num
= getNonlinearSystemBase().number();
// For parallel procs i believe that i have to use local_nodes_begin, rather than just nodes_begin
// _mesh comes from SystemBase (_mesh = getNonlinearSystemBase().subproblem().mesh(), and
// subproblem is this object)
for
(const
auto
& node
: _mesh.getMesh().local_node_ptr_range())
{
// dofs[0] is the dof number of the polar variable at this node
// dofs[1] is the dof number of the azimuthal variable at this node
std::vector<dof_id_type>
dofs(2);
dofs[]
= node->dof_number(sys_num,
_polar_var_num,
);
dofs[1]
= node->dof_number(sys_num,
_azimuthal_var_num,
);
// soln[0] is the value of the polar variable at this node
// soln[1] is the value of the azimuthal variable at this node
std::vector<Number>
soln(2);
vec_solution.get(dofs,
soln);
if
(soln[]
> libMesh::pi)
{
vec_solution.set(dofs[],
soln[]
- libMesh::pi);
// polar var moved above pi so set back in range (0,pi)
updatedSolution =
true;
}
}
// The above vec_solution.set calls potentially added "set" commands to a queue
// The following actions the queue (doing MPI commands if necessary), so
// vec_solution will actually be modified by this following command
vec_solution.close();
// if any proc updated the solution, all procs will know about it
_communicator.max(updatedSolution);
if
(updatedSolution)
{
ghosted_solution = vec_solution;
ghosted_solution.close();
}
return updatedSolution;
}
soln[]
< 0.0? Just another else if loop or can updatedSolution be used simultaneously like that?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.
To view this discussion on the web visit https://groups.google.com/d/msgid/moose-users/0000ddd3-fdff-4b96-af8c-b62fac3e70e2%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Andrew....@csiro.au
dofs[] = node->dof_number(sys_num, _polar_var_num, );
dofs[1] = node->dof_number(sys_num, _azimuthal_var_num, );
{
vec_solution.set(dofs[], soln[] - libMesh::pi); // polar var moved above pi so set back in range (0,pi)
updatedSolution = true;
}
dofs[0] = node->dof_number(sys_num, _polar_var_num, 0);
if (soln[0] >= libMesh::pi || soln[0] < 0)
{
vec_solution.set(dofs[0], soln[0] - math.floor(soln[0] / libMesh::pi) * libMesh::pi); // polar var moved above pi so set back in range (0,pi)
updatedSolution = true;
}
if (soln[1] >= libMesh::pi || soln[1] < 0)
{
vec_solution.set(dofs[1], soln[1] - math.floor(soln[1] / libMesh::pi) * libMesh::pi); // azimuthal var moved above pi so set back in range (0,pi)
updatedSolution = true;
}
If you use this approach, please check the "math.floor" stuff - i just guessed and might not be thinking properly about the end points (0 and Pi) and negative numbers.
a
Ph: +61 7 3327 4497. Fax: +61 7 3327 4666
Queensland Centre for Advanced Technologies
PO Box 883, Kenmore, Qld, 4069
Sent: Friday, 27 July 2018 2:49 AM
To: moose-users <moose...@googlegroups.com>
Subject: Re: Specifying a bound on a variable
You may do something if solution is less than 0:
if (soln[] <0)
{
vec_solution.set(dofs[], -soln[]); // polar var moved above pi so set back in range (0,pi)
updatedSolution = true;
}
But I would like to reformulate the constraints into a regular nonlinear system of equations using NCP https://en.wikipedia.org/wiki/Nonlinear_complementarity_problem.
You can also try vinewtonssls, but it does not support matrix-free right now. There is an example:
moose/test/tests/auxkernels/bounds:
../../../moose_test-opt -i bounds_test.i -snes_type vinewtonssls -snes_mf_operator 0
Fande,
Nonlinear complementarity problem - Wikipedia
en.wikipedia.org
In applied mathematics, a nonlinear complementarity problem (NCP) with respect to a mapping ƒ : R n → R n, denoted by NCPƒ, is to find a vector x ∈ R n such that ...
john.m...@uconn.edu
john.m...@uconn.edu
Fande Kong
Fande using the vinewtonssl and Bounds seemed to allow this constraint.Convergence is pretty terrible now but at least I don't get DIVERGED_LOCAL_MIN anymore and my order parameter can evolve
On Tuesday, 24 July 2018 15:47:13 UTC+2, john.m...@uconn.edu wrote:Hello,I've written something "simple" so far to solve a system of equations in spherical coordinates (LLG equations for micromagnetism). We require the solution vector to be normalized to one, so performing the calculations on the unit sphere is a natural way of solving the problem. It avoids having to use Constraints. It even reduces the number of nonlinear variables!However, we have a number of residual terms that include \cos{\theta}, \sin{\phi} and so on. Note that since the angles aren't prescribed unique, the solver seems to find all sorts of possibilities (ex, \phi + 2 n \pi where n is integer still satisfies the residual).
Indeed my solver converges for some time (no complaints from analyzejacobian), but the angles themselves start diverging to +/- infinity all the while still satisfying the residual minimization . So the evolution is wrong and unphysical, since angles begin hopping around and the convergence problems appear.Is there a trick to force these variables to be constrained (?) to their respective {0,2\pi}, {0, \pi} domains?Or... is it back to cartesian drawing board with Constraints? Or another thought is that this could have to do with the timestepper, which I've played with and seem to get this regardless of what dt step size or scheme I use.Best,John
--
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+unsubscribe@googlegroups.com.
Visit this group at https://groups.google.com/group/moose-users.
To view this discussion on the web visit https://groups.google.com/d/msgid/moose-users/6e2ada86-f3e3-4edb-a1c3-1e5b18c35515%40googlegroups.com.
John Mangeri
--
You received this message because you are subscribed to a topic in the Google Groups "moose-users" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/moose-users/Kzimz-HcK2s/unsubscribe.
To unsubscribe from this group and all its topics, send an email to moose-users+unsubscribe@googlegroups.com.
Visit this group at https://groups.google.com/group/moose-users.
To view this discussion on the web visit https://groups.google.com/d/msgid/moose-users/CAN5Wd-%2BFX9efC%2BiLUgn6Ygi%3DuQME5eifsWWD5ZsbR2momOTiuw%40mail.gmail.com.
Fande Kong
And that made things much better! Was having 20-30 nonlinear iterations; now I'm having 3-4!
To view this discussion on the web visit https://groups.google.com/d/msgid/moose-users/CAJC7Cwbg%2B1pabrcV39_PjuQkmd%3DKMYgEJeNQ66j%3D%2Bk6V%3DnBuWA%40mail.gmail.com.
Andrew....@csiro.au
John and/or Fande,
Is it possible to add something to the MOOSE docs for this? I'm not sure why my approach in RichardsMultiphaseProblem didn't work here (i can't write that without sounding petulant, but i don't mean to sound so!) and it would be really great to have something for future readers to follow, as i think bounding variables is relatively common.
a
From: moose...@googlegroups.com <moose...@googlegroups.com> on behalf of Fande Kong <fdko...@gmail.com>
Sent: Tuesday, 31 July 2018 2:37 AM
To: moose...@googlegroups.com
Subject: Re: Specifying a bound on a variable
On Mon, Jul 30, 2018 at 10:29 AM, John Mangeri <john.m...@uconn.edu> wrote:
And that made things much better! Was having 20-30 nonlinear iterations; now I'm having 3-4!
Cool. It would be great, if you could add some tests back to MOOSE so that I can continue supporting this solver.
Fande,
John
On Mon, Jul 30, 2018 at 6:20 PM, Fande Kong <fdko...@gmail.com> wrote:
On Mon, Jul 30, 2018 at 10:11 AM, <john.m...@uconn.edu> wrote:
Fande using the vinewtonssl and Bounds seemed to allow this constraint.
Convergence is pretty terrible now but at least I don't get DIVERGED_LOCAL_MIN anymore and my order parameter can evolve
Hi John,
Could you try vinewtonrsls instread of vinewtonssls? We found recently vinewtonrsls has a better convergence for some problems because it update the inactive unknowns only.
Fande,
On Tuesday, 24 July 2018 15:47:13 UTC+2, john.m...@uconn.edu wrote:
Hello,
I've written something "simple" so far to solve a system of equations in spherical coordinates (LLG equations for micromagnetism). We require the solution vector to be normalized to one, so performing the calculations on the unit sphere is a natural way of solving the problem. It avoids having to use Constraints. It even reduces the number of nonlinear variables!
However, we have a number of residual terms that include \cos{\theta}, \sin{\phi} and so on. Note that since the angles aren't prescribed unique, the solver seems to find all sorts of possibilities (ex, \phi + 2 n \pi where n is integer still satisfies the residual).
Indeed my solver converges for some time (no complaints from analyzejacobian), but the angles themselves start diverging to +/- infinity all the while still satisfying the residual minimization . So the evolution is wrong and unphysical, since angles begin hopping around and the convergence problems appear.
Is there a trick to force these variables to be constrained (?) to their respective {0,2\pi}, {0, \pi} domains?
Or... is it back to cartesian drawing board with Constraints? Or another thought is that this could have to do with the timestepper, which I've played with and seem to get this regardless of what dt step size or scheme I use.
Best,
John
--
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 https://groups.google.com/group/moose-users.
To view this discussion on the web visit https://groups.google.com/d/msgid/moose-users/6e2ada86-f3e3-4edb-a1c3-1e5b18c35515%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
--
You received this message because you are subscribed to a topic in the Google Groups "moose-users" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/moose-users/Kzimz-HcK2s/unsubscribe.
To unsubscribe from this group and all its topics, send an email to moose-users...@googlegroups.com.
Visit this group at https://groups.google.com/group/moose-users.
To view this discussion on the web visit https://groups.google.com/d/msgid/moose-users/CAN5Wd-%2BFX9efC%2BiLUgn6Ygi%3DuQME5eifsWWD5ZsbR2momOTiuw%40mail.gmail.com.
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.
Visit this group at https://groups.google.com/group/moose-users.
To view this discussion on the web visit https://groups.google.com/d/msgid/moose-users/CAJC7Cwbg%2B1pabrcV39_PjuQkmd%3DKMYgEJeNQ66j%3D%2Bk6V%3DnBuWA%40mail.gmail.com.
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.
Visit this group at https://groups.google.com/group/moose-users.
To view this discussion on the web visit https://groups.google.com/d/msgid/moose-users/CAN5Wd-Kx9Q4PCAz4Lq9DR6butSfeCby2nr6C%2BH_%2B1NwZcGj8kg%40mail.gmail.com.
