Interpolation function in strong form Vs. weak form #29427

ashishdhole · 2024-12-10T05:09:10Z

ashishdhole
Dec 10, 2024

Hello,

As moose solves the PDE in weak form. is it possible that the value of any additional driving force in the form of an interpolation function (like 3.eta_i.eta_j.Pz) is different when calculated in moose. If so is there any scaling rule I must follow?

Thanks.

GiudGiud · 2024-12-10T13:40:45Z

GiudGiud
Dec 10, 2024
Collaborator

Hello

is it possible that the value of any additional driving force in the form of an interpolation function (like 3.eta_i.eta_j.Pz) is different when calculated in moose.

I'm not sure I understand why it would be different?
You can output the contribution of a given kernel to check, using either the deprecated save_in method, or the "extra_vector_tags" options, then using a TagVectorAux to output the contribution to the residual to an auxiliary variable

5 replies

ashishdhole Dec 10, 2024
Author

in

in theory when the value of m =2, L=1, and k = 4 is used the residual should become zero with the corresponding value of Pz = 0.045 = ΔG_ij

i.e. interface energy, σ = (1/3) sqrt(2mk)
driving force for an interface Pd = σ/R # here R is the radius of curvature
based on this if R = 30 , σ = 1.3333 (based on the values of m and k mentioned above)
Pd = 0.04444

that means if Pz = 0.045 which is more than Pd, the interface should not move at all.

That is the driving foce (1st and third term in above equation) becomes equal to the pinning force (second term in above equation).

That is in theory. But when I am solving the PDE in MOOSE, even with Pz=1 the residual never becomes zero.

This should not happen.
The way I am writing these terms in moose kernel is as follows

  Real SumEtaj = 0.0;
  Real SumEtaj_G = 0.0;
  for (unsigned int i = 0; i < _op_num; ++i)
  {
    SumEtaj += (*_vals[i])[_qp] * (*_vals[i])[_qp];
    SumEtaj_G += (*_vals[i])[_qp];
  }

  Real g = _g[_qp];
  Real total = (_test[_i][_qp] * _mu[_qp] *
                (_u[_qp] * _u[_qp] * _u[_qp] - _u[_qp] + 3 * _u[_qp] * SumEtaj)) +
               (_grad_u[_qp] * _kappa[_qp] * _grad_test[_i][_qp]); //1st and 3rd term in above equation

  Real friction = _test[_i][_qp] * 3 * g * _u[_qp] * SumEtaj_G; //second term in above equation, Pz = g

The set of equations are correct that means the only possible explanation is that moose is not able to calculate the interpolation function (second term) value correctly.

Unless you think the equation is wrongly written in the kernel.

The same equation and corresponding values of constants were used in analytical model and an FDM model. Both these models shows the desired results except in moose.

GiudGiud Dec 10, 2024
Collaborator

//1st and 3rd term in above equation

shouldnt the 3rd term have a minus?

same for the second term?
since the first term has a + sign in both the equation and the implementation (keeping in mind you move it to the LHS so the sign in front of L disappears)

ashishdhole Dec 10, 2024
Author

I remember asking this question in my very early queries long time ago.

As you can see the way MOOSE implemented this equation has negative sign to the third term of equation, but if you look at the grain growth action kernel, there is no negative sign in ACInterface.

GrainGrowthAction = TimeDerivative + ACGrGrPoly + ACInterface

As for the second term I am putting the '-' sign in the final return

  Real SumEtaj = 0.0;
  Real SumEtaj_G = 0.0;
  for (unsigned int i = 0; i < _op_num; ++i)
  {
    SumEtaj += (*_vals[i])[_qp] * (*_vals[i])[_qp];
    SumEtaj_G += (*_vals[i])[_qp];
  }

  Real g = _g[_qp];
  Real total = (_test[_i][_qp] * _mu[_qp] *
                (_u[_qp] * _u[_qp] * _u[_qp] - _u[_qp] + 3 * _u[_qp] * SumEtaj)) +
               (_grad_u[_qp] * _kappa[_qp] * _grad_test[_i][_qp]); //1st and 3rd term in above equation

  Real friction = _test[_i][_qp] * 3 * g * _u[_qp] * SumEtaj_G; //second term in above equation, Pz = g

  const Real sgn = (total > 0) - (total < 0);

  return (total - sgn * friction);

GiudGiud Dec 10, 2024
Collaborator

As you can see the way MOOSE implemented this equation has negative sign to the third term of equation, but if you look at the grain growth action kernel, there is no negative sign in ACInterface.

This equation is written with the term on the LHS already. So they have the sign right for the equation they wrote, but your equation has a different sign

ashishdhole Dec 10, 2024
Author

I tried with minus sign. In that case even the normal grain growth does not work

with + sign in 3rd term

Framework Information:
MOOSE Version:           git commit 19f35c4703 on 2024-10-25
LibMesh Version:         
PETSc Version:           3.21.5
SLEPc Version:           3.21.1
Current Time:            Tue Dec 10 11:32:24 2024
Executable Timestamp:    Tue Dec 10 11:31:39 2024

Checkpoint:
  Wall Time Interval:      Every 3600 s
  User Checkpoint:         Outputs/checkpoint
  # Checkpoints Kept:      2
  Execute On:              TIMESTEP_END 

Parallelism:
  Num Processors:          4
  Num Threads:             1

Mesh: 
  Parallel Type:           replicated
  Mesh Dimension:          2
  Spatial Dimension:       2
  Nodes:                   
    Total:                 58081
    Local:                 14653
    Min/Max/Avg:           14360/14653/14520
  Elems:                   
    Total:                 14400
    Local:                 3600
    Min/Max/Avg:           3600/3600/3600
  Num Subdomains:          1
  Num Partitions:          4
  Partitioner:             metis

Nonlinear System:
  Num DOFs:                146410
  Num Local DOFs:          37270
  Num Constrained DOFs:    2410
  Local Constrained DOFs:  600
  Variables:               { "gr0" "gr1" "gr2" "gr3" "gr4" "gr5" "gr6" "gr7" "gr8" "gr9" } 
  Finite Element Types:    "LAGRANGE" 
  Approximation Orders:    "FIRST" 

Auxiliary System:
  Num DOFs:                58082
  Num Local DOFs:          14654
  Num Constrained DOFs:    482
  Local Constrained DOFs:  120
  Variables:               "bnds" { "unique_grains" "var_indices" } "phi" 
  Finite Element Types:    "LAGRANGE" "MONOMIAL" "LAGRANGE" 
  Approximation Orders:    "FIRST" "CONSTANT" "FIRST" 

Execution Information:
  Executioner:             Transient
  TimeStepper:             IterationAdaptiveDT
  TimeIntegrator:          BDF2
  Solver Mode:             Preconditioned JFNK
  PETSc Preconditioner:    hypre boomeramg 


Time Step 0, time = 0

Postprocessor Values:
+----------------+----------------+----------------+----------------+----------------+
| time           | DOFs           | avg_grain_vol  | g              | grain_tracker  |
+----------------+----------------+----------------+----------------+----------------+
|   0.000000e+00 |   0.000000e+00 |   1.000000e+02 |   0.000000e+00 |   1.000000e+02 |
+----------------+----------------+----------------+----------------+----------------+


Time Step 1, time = 0.1, dt = 0.1

Performing automatic scaling calculation

 0 Nonlinear |R| = 2.407867e+01
      0 Linear |R| = 2.407867e+01
      1 Linear |R| = 1.146862e+00
      2 Linear |R| = 9.927316e-02
      3 Linear |R| = 7.939899e-03
 1 Nonlinear |R| = 3.172691e+00
      0 Linear |R| = 3.172691e+00
      1 Linear |R| = 3.064988e-01
      2 Linear |R| = 5.739507e-02
      3 Linear |R| = 1.414087e-02
      4 Linear |R| = 2.370168e-03
 2 Nonlinear |R| = 2.885722e-01
      0 Linear |R| = 2.885722e-01
      1 Linear |R| = 3.185012e-02
      2 Linear |R| = 6.540664e-03
      3 Linear |R| = 1.411937e-03
      4 Linear |R| = 3.043319e-04
 3 Nonlinear |R| = 1.874856e-02
 Solve Converged!

Outlier Variable Residual Norms:
  gr0: 9.102239e-03
  gr1: 1.037014e-02

Postprocessor Values:
+----------------+----------------+----------------+----------------+----------------+
| time           | DOFs           | avg_grain_vol  | g              | grain_tracker  |
+----------------+----------------+----------------+----------------+----------------+
|   0.000000e+00 |   0.000000e+00 |   1.000000e+02 |   0.000000e+00 |   1.000000e+02 |
|   1.000000e-01 |   2.044920e+05 |   9.861869e+01 |   0.000000e+00 |   1.000000e+02 |
+----------------+----------------+----------------+----------------+----------------+

Steady-State Relative Differential Norm: 2.13711

with minus sign in 3rd term

Framework Information:
MOOSE Version:           git commit 19f35c4703 on 2024-10-25
LibMesh Version:         
PETSc Version:           3.21.5
SLEPc Version:           3.21.1
Current Time:            Tue Dec 10 11:34:59 2024
Executable Timestamp:    Tue Dec 10 11:34:48 2024

Checkpoint:
  Wall Time Interval:      Every 3600 s
  User Checkpoint:         Outputs/checkpoint
  # Checkpoints Kept:      2
  Execute On:              TIMESTEP_END 

Parallelism:
  Num Processors:          4
  Num Threads:             1

Mesh: 
  Parallel Type:           replicated
  Mesh Dimension:          2
  Spatial Dimension:       2
  Nodes:                   
    Total:                 58081
    Local:                 14653
    Min/Max/Avg:           14360/14653/14520
  Elems:                   
    Total:                 14400
    Local:                 3600
    Min/Max/Avg:           3600/3600/3600
  Num Subdomains:          1
  Num Partitions:          4
  Partitioner:             metis

Nonlinear System:
  Num DOFs:                146410
  Num Local DOFs:          37270
  Num Constrained DOFs:    2410
  Local Constrained DOFs:  600
  Variables:               { "gr0" "gr1" "gr2" "gr3" "gr4" "gr5" "gr6" "gr7" "gr8" "gr9" } 
  Finite Element Types:    "LAGRANGE" 
  Approximation Orders:    "FIRST" 

Auxiliary System:
  Num DOFs:                58082
  Num Local DOFs:          14654
  Num Constrained DOFs:    482
  Local Constrained DOFs:  120
  Variables:               "bnds" { "unique_grains" "var_indices" } "phi" 
  Finite Element Types:    "LAGRANGE" "MONOMIAL" "LAGRANGE" 
  Approximation Orders:    "FIRST" "CONSTANT" "FIRST" 

Execution Information:
  Executioner:             Transient
  TimeStepper:             IterationAdaptiveDT
  TimeIntegrator:          BDF2
  Solver Mode:             Preconditioned JFNK
  PETSc Preconditioner:    hypre boomeramg 


Time Step 0, time = 0

Postprocessor Values:
+----------------+----------------+----------------+----------------+----------------+
| time           | DOFs           | avg_grain_vol  | g              | grain_tracker  |
+----------------+----------------+----------------+----------------+----------------+
|   0.000000e+00 |   0.000000e+00 |   1.000000e+02 |   0.000000e+00 |   1.000000e+02 |
+----------------+----------------+----------------+----------------+----------------+


Time Step 1, time = 0.1, dt = 0.1

Performing automatic scaling calculation

 0 Nonlinear |R| = 6.437778e+01
      0 Linear |R| = 6.437778e+01
    Linear solve did not converge due to DIVERGED_NANORINF iterations 0
  Nonlinear solve did not converge due to DIVERGED_LINEAR_SOLVE iterations 0
 Solve Did NOT Converge!
Aborting as solve did not converge

Solve failed, cutting timestep.

Time Step 1, time = 0.05, dt = 0.05
 0 Nonlinear |R| = 6.437778e+01
      0 Linear |R| = 6.437778e+01
    Linear solve did not converge due to DIVERGED_NANORINF iterations 0
  Nonlinear solve did not converge due to DIVERGED_LINEAR_SOLVE iterations 0
 Solve Did NOT Converge!
Aborting as solve did not converge

with + sign my kernel behaves same as GrainGrowthAction (exactly same even the timesteps increment)

ashishdhole · 2024-12-10T20:21:29Z

ashishdhole
Dec 10, 2024
Author

@tonkmr Suggested I should use

Real total = (_mu[_qp] * (_u[_qp] * _u[_qp] * _u[_qp] - _u[_qp] + 3 * _u[_qp] * SumEtaj)) -
             (_kappa[_qp] * _second_u[_qp].tr());

instead of

  Real total = (_test[_i][_qp] * _mu[_qp] *
                (_u[_qp] * _u[_qp] * _u[_qp] - _u[_qp] + 3 * _u[_qp] * SumEtaj)) +
               (_grad_u[_qp] * _kappa[_qp] * _grad_test[_i][_qp]);

but then in residual when I am using

Real total = (_test[_i][_qp]  * _mu[_qp] * (_u[_qp] * _u[_qp] * _u[_qp] - _u[_qp] + 3 * _u[_qp] * SumEtaj)) -
             (_kappa[_qp] * _second_u[_qp].tr()) * _second_test[_i][_qp].tr();

It doesn't work
even with higher order element

0 replies

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Interpolation function in strong form Vs. weak form #29427

{{title}}

Replies: 2 comments 5 replies

{{title}}

{{title}}

{{editor}}'s edit

{{editor}}'s edit

{{title}}

{{title}}

{{editor}}'s edit

{{editor}}'s edit

{{title}}

{{title}}

{{title}}

{{editor}}'s edit

{{editor}}'s edit

Select a reply

Interpolation function in strong form Vs. weak form #29427

ashishdhole Dec 10, 2024

Replies: 2 comments · 5 replies

GiudGiud Dec 10, 2024 Collaborator

ashishdhole Dec 10, 2024 Author

GiudGiud Dec 10, 2024 Collaborator

ashishdhole Dec 10, 2024 Author

GiudGiud Dec 10, 2024 Collaborator

ashishdhole Dec 10, 2024 Author

ashishdhole Dec 10, 2024 Author

ashishdhole
Dec 10, 2024

Replies: 2 comments 5 replies

GiudGiud
Dec 10, 2024
Collaborator

ashishdhole Dec 10, 2024
Author

GiudGiud Dec 10, 2024
Collaborator

ashishdhole Dec 10, 2024
Author

GiudGiud Dec 10, 2024
Collaborator

ashishdhole Dec 10, 2024
Author

ashishdhole
Dec 10, 2024
Author