New kernels to increase model flexibility #11830

itgreenquist · 2018-07-11T20:13:06Z

Introduces two new phase field kernels and modifies one existing kernel so that kappa and mu can be implemented as constants.
Also includes one new test which covers both new kernels, and documentation for the kernels.

Closes #11829

moosebuild · 2018-07-11T20:44:53Z

Job Documentation on 8ffa755 wanted to post the following:

View the site here

This comment will be updated on new commits.

itgreenquist · 2018-07-12T16:51:57Z

The test that failed in Test Intel is the new one I submitted in this PR. I've double checked and it passes consistently on my computer, fails consistently in Test Intel, and passes in Test debug.

@permcody, what does that mean? Should I modify the test?

permcody · 2018-07-12T17:40:51Z

Numerics are just different between machines, compilers, etc. Take a look closely at that exodiff and read it. What it tells you is which value is different and by how much. In this case the "gold" value and your value from the test are both very tiny (1e-9 or smaller). The problem is that relative differences at that scale tend to get magnified a bit. There are several solutions that can be applied to this problem.

Not all of these can be applied in all situations:

Solve to an even tighter tolerance
Adjust your comparison tolerances

Relative tolerance can be changed (See Exodiff tester parameters)
Absolute tolerance can be changed (values under which comparisons are ignored)

Avoid physics where the solution contains such tiny values (not always possible)
Don't compare fields that are not of interest (not always a good idea).
Skip specific compilers, or platforms (generally a bad idea)

I'd work with suggestion #1 or #2. Let me know if you need further guidance.

itgreenquist · 2018-07-25T13:02:40Z

@dschwen have you had a chance to look at this?

friedmud · 2018-07-30T16:53:02Z

Pinging @dschwen

dschwen · 2018-07-30T17:03:27Z

modules/phase_field/src/kernels/ACKappaFunction.C

+         term1;
+}
+
+Real ACKappaFunction::computeFg() // gradient energy term


This comment belongs in the header (with ///)

dschwen · 2018-07-30T17:04:55Z

modules/phase_field/src/kernels/ACBarrierFunction.C

+        (_u[_qp] * _u[_qp] + sum_eta_j2) * (*_vals[i])[_qp] * (*_vals[i])[_qp] * _gamma[_qp];
+  } // for (unsigned int i = 0; i < _n_eta; ++i)
+  return 0.25 + var_phase + eta_phase + eta_interface;
+} // Real ACBarrierFunction::calculate_f0()


These comments are not necessary for blocks that fit comfortably on the screen

dschwen · 2018-07-30T17:05:15Z

modules/phase_field/include/kernels/ACBarrierFunction.h

+  std::vector<const MaterialProperty<Real> *> _d2mudvardeta;
+
+private:
+  Real calculate_f0();


Naming convention

dschwen · 2018-07-30T17:05:57Z

modules/phase_field/include/kernels/ACBarrierFunction.h

+ * Several kernels use a material property called mu. If mu is not a constant,
+ * then this kernel will calculate the bulk AC term where mu is the derivative term.
+ * It currently only takes a single value for gamma.
+ **/


please move this directly above the class declaration

dschwen · 2018-07-30T17:07:19Z

modules/phase_field/doc/content/source/kernels/ACBarrierFunction.md

+It should not be necessary to use multiple $\gamma$'s in models with a non-constant
+$m$.
+
+### Inputs


You probably mean "Input Parameters". This section is not necessary, the parameter descriptions are extracted from the executable. Just make sure your addParam etc. calls have proper doc strings.

dschwen · 2018-07-30T17:08:51Z

modules/phase_field/src/kernels/ACBarrierFunction.C

+validParams<ACBarrierFunction>()
+{
+  InputParameters params = validParams<ACGrGrBase>();
+  params.addRequiredParam<MaterialPropertyName>("gamma", "The gamma value to use with the kernel");


That doc string is not useful at all! Please spell out the physical significance of gamma.

dschwen · 2018-07-30T17:09:19Z

modules/phase_field/src/kernels/ACBarrierFunction.C

+    case Residual:
+    {
+      return _dmudvar[_qp] * calculate_f0();
+    } // case Residual:


braces not needed here

dschwen · 2018-07-30T17:10:18Z

modules/phase_field/src/kernels/ACBarrierFunction.C

+    sum_eta_j2 = 0.0;
+    for (unsigned int j = i + 1; j < _n_eta; ++j)
+      sum_eta_j2 += (*_vals[j])[_qp] * (*_vals[j])[_qp];
+    eta_phase += 0.25 * (*_vals[i])[_qp] * (*_vals[i])[_qp] * (*_vals[i])[_qp] * (*_vals[i])[_qp] -


please use Utility::pow<> here

dschwen · 2018-07-30T17:13:59Z

modules/phase_field/src/kernels/ACKappaFunction.C

+    _kappa_name(getParam<MaterialPropertyName>("kappa_name")),
+    _dkappadvar(getMaterialPropertyDerivative<Real>(_kappa_name, _var_name)),
+    _d2kappadvar2(getMaterialPropertyDerivative<Real>(_kappa_name, _var_name, _var_name)),
+    _nv(coupledComponents("v")),


This is almost always called _op_num.

dschwen

See comments above

SudiptaBiswas · 2018-07-31T15:46:05Z

modules/phase_field/src/kernels/ACKappaFunction.C

+
+  Real grad_var2 = _grad_u[_qp] * _grad_u[_qp];
+  return sum_grad_etai2 + grad_var2;
+}


Wait!! Why is this sum over all the gradient variables? In general, kappa values corresponding to different coupled variables can be different, right?

The idea with the kernel is that you are using a functional kappa value instead of different kappas for each variable. It achieves a similar effect to using multiple kappas, but with transition regions. I can't think of a scenario where someone would want multiple functional kappas, but if they did they could try being selective on what variables to include in "v".

Here is what I am trying to understand, the gradient energy term is

and you are implementing its derivative w.r.t the order parameters. So, shouldn't the generic implementation be

instead of
?
It assumes same kappa function for all the coupled order parameters, cases such as polycrystal solidification can have different kappa functions.

That would be the most generic case, but

it would be a huge headache for me to rewrite the kernel

the UI for the kernel would be more complicated and the kernel harder to use

the feature would (almost) never be used,

in the rare case that it is needed, you can achieve the same effect by using the kernel multiple times with a single coupled eta each time, effectively doing the sum yourself.

I looked up a couple of polycrystal solidification papers and could not find one with multiple functional kappas. One used multiple constant kappas, and another used a single functional kappa. Can you send a link to one with multiple functional kappas? I'm curious about the scenario where that would be desirable.

I understand. I am working on something similar to what you have found and intended to implement some associated kernels (#11838). It's okay, I can work around it for now. I was curious to know why the kernel is not implemented in the generic form. Thanks for the clarification.

This kernel could be expanded in a later PR (even by you @SudiptaBiswas)

Yeah, I would work on it later.

SudiptaBiswas · 2018-07-31T16:16:19Z

modules/phase_field/src/kernels/ACKappaFunction.C

+ACKappaFunction::computeQpOffDiagJacobian(unsigned int jvar)
+{
+  const unsigned int i = mapJvarToCvar(jvar);
+  Real PreJac = 0.5 * _test[_i][_qp] * _phi[_j][_qp] * computeFg();


Naming convention (being pedantic)

SudiptaBiswas · 2018-07-31T16:19:23Z

modules/phase_field/include/kernels/ACKappaFunction.h

+  std::vector<const MaterialProperty<Real> *> _d2kappadvardv;
+
+private:
+  Real computeFg();


Probably the method names can be a little bit more informative! Just a suggestion.

friedmud · 2018-08-08T15:09:51Z

@SudiptaBiswas do you believe you've satisfied all the comments?

@dschwen can you take a second look here?

SudiptaBiswas · 2018-08-08T15:18:06Z

@friedmud I did not work in this PR, it's entirely @itgreenquist. I just had a few comments that we discussed. I will work on the expansion later in a separate PR.

itgreenquist · 2018-08-08T17:23:55Z

@friedmud I've addressed all of the comments.

friedmud · 2018-08-08T20:30:06Z

Ok - so we just need @dschwen to take a look and merge it then

itgreenquist changed the title ~~New kernels to increase model flexibility. Closes #11829~~ New kernels to increase model flexibility Jul 12, 2018

itgreenquist force-pushed the MooseKernels branch from 450f595 to 238dd4c Compare July 12, 2018 13:26

itgreenquist force-pushed the MooseKernels branch from 238dd4c to 53efde8 Compare July 13, 2018 13:39

permcody assigned dschwen Jul 13, 2018

dschwen reviewed Jul 30, 2018

View reviewed changes

dschwen requested changes Jul 30, 2018

View reviewed changes

SudiptaBiswas reviewed Jul 31, 2018

View reviewed changes

itgreenquist force-pushed the MooseKernels branch 2 times, most recently from 6beed4c to d49b510 Compare July 31, 2018 17:33

New kernels to increase model flexibility. Closes idaholab#11829

8ffa755

itgreenquist force-pushed the MooseKernels branch from d49b510 to 8ffa755 Compare July 31, 2018 17:41

friedmud added the PR: Ready for review/merge label Aug 8, 2018

dschwen approved these changes Aug 10, 2018

View reviewed changes

dschwen merged commit e5790f8 into idaholab:devel Aug 10, 2018

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

New kernels to increase model flexibility #11830

New kernels to increase model flexibility #11830

itgreenquist commented Jul 11, 2018

moosebuild commented Jul 11, 2018 •

edited

Loading

itgreenquist commented Jul 12, 2018

permcody commented Jul 12, 2018

itgreenquist commented Jul 25, 2018

friedmud commented Jul 30, 2018

dschwen Jul 30, 2018

dschwen Jul 30, 2018

dschwen Jul 30, 2018

dschwen Jul 30, 2018 •

edited

Loading

dschwen Jul 30, 2018

dschwen Jul 30, 2018

dschwen Jul 30, 2018

dschwen Jul 30, 2018

dschwen Jul 30, 2018

dschwen left a comment

SudiptaBiswas Jul 31, 2018

itgreenquist Jul 31, 2018

SudiptaBiswas Jul 31, 2018

itgreenquist Aug 1, 2018

SudiptaBiswas Aug 1, 2018

dschwen Aug 1, 2018

SudiptaBiswas Aug 1, 2018

SudiptaBiswas Jul 31, 2018

SudiptaBiswas Jul 31, 2018

friedmud commented Aug 8, 2018

SudiptaBiswas commented Aug 8, 2018

itgreenquist commented Aug 8, 2018

friedmud commented Aug 8, 2018

New kernels to increase model flexibility #11830

New kernels to increase model flexibility #11830

Conversation

itgreenquist commented Jul 11, 2018

moosebuild commented Jul 11, 2018 • edited Loading

itgreenquist commented Jul 12, 2018

permcody commented Jul 12, 2018

itgreenquist commented Jul 25, 2018

friedmud commented Jul 30, 2018

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

dschwen Jul 30, 2018 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

dschwen left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

friedmud commented Aug 8, 2018

SudiptaBiswas commented Aug 8, 2018

itgreenquist commented Aug 8, 2018

friedmud commented Aug 8, 2018

moosebuild commented Jul 11, 2018 •

edited

Loading

dschwen Jul 30, 2018 •

edited

Loading