Add new energy terms to the AC equation

[YXY101676]

Dear all,
I want to add new energy terms to the AC equation, but I'm having trouble understanding the existing code.

In the ComputePolycrystalElasticityTensor.C file, the derivative of the elastic modulus with respect to the order parameter, __elastic_tensor(_op_num), is computed, which is an array of the number of active order parameters at the integration point. What I don't understand is the parameter created in the PolycrystalElasticDrivingForceAction.C file, MaterialPropertyName D_stiff_name =derivativePropertyNameFirst(_elasticity_tensor, var_name), can call the derivative of the current kernels variable needed in _D_elastic_tensor(_op_num); it might be due to some misunderstanding of code, and I appreciate your help very much.

[GiudGiud]

Hello

For future reference it's better to copy paste text than to screenshot it. From a screenshot I can't copy paste to explain each line.

derivativePropertyNameFirst gives you the name of the material property that is the derivative of 'elasticity_tensor_name' with regards to var_name. Var_name is the name of the variable for that order parameter.
It does not actually compute that derivative here. That derivative (= that material property) is computed by a Material object, but it is declared with that same name.

Then a kernel is created, and the D_tensor is set to this material property.

[YXY101676]

Dear GiudGiud
I'm very sorry for the late reply, I had some minor health issues earlier.And I'm sorry for asking questions in the form of screenshots. I won't do it again in the future. I still have some confusion about the in this file.

void
ComputePolycrystalElasticityTensor::computeQpElasticityTensor()
{
  // Get list of active order parameters from grain tracker
  const auto & op_to_grains = _grain_tracker.getVarToFeatureVector(_current_elem->id());

  // Calculate elasticity tensor
  _elasticity_tensor[_qp].zero();
  Real sum_h = 0.0;
  for (MooseIndex(op_to_grains) op_index = 0; op_index < op_to_grains.size(); ++op_index)
  {
    auto grain_id = op_to_grains[op_index];
    if (grain_id == FeatureFloodCount::invalid_id)
      continue;

    // Interpolation factor for elasticity tensors
    Real h = (1.0 + std::sin(libMesh::pi * ((*_vals[op_index])[_qp] - 0.5))) / 2.0;

    // Sum all rotated elasticity tensors
    _elasticity_tensor[_qp] += _grain_tracker.getData(grain_id) * h;
    sum_h += h;
  }

  const Real tol = 1.0e-10;
  sum_h = std::max(sum_h, tol);
  _elasticity_tensor[_qp] /= sum_h;

  // Calculate elasticity tensor derivative: Cderiv = dhdopi/sum_h * (Cop - _Cijkl)
  for (MooseIndex(_op_num) op_index = 0; op_index < _op_num; ++op_index)
    (*_D_elastic_tensor[op_index])[_qp].zero();

  for (MooseIndex(op_to_grains) op_index = 0; op_index < op_to_grains.size(); ++op_index)
  {
    auto grain_id = op_to_grains[op_index];
    if (grain_id == FeatureFloodCount::invalid_id)
      continue;

    Real dhdopi = libMesh::pi * std::cos(libMesh::pi * ((*_vals[op_index])[_qp] - 0.5)) / 2.0;
    RankFourTensor & C_deriv = (*_D_elastic_tensor[op_index])[_qp];

    C_deriv = (_grain_tracker.getData(grain_id) - _elasticity_tensor[_qp]) * dhdopi / sum_h;

    // Convert from XPa to eV/(xm)^3, where X is pressure scale and x is length scale;
    C_deriv *= _JtoeV * (_length_scale * _length_scale * _length_scale) * _pressure_scale;
  }
}

Among them, the feature ID vector op_to_grains obtained through the getVarToFeatureVector function, does the order of the feature IDs correspond the order of the parameter values:_vals?
How is his order determined? I didn't find the sorting method of _vals, which is the order parameter value, in the FeatureFlood.C file.

[GiudGiud]

you can look at the GrainTracker code for the definition of getVarToFeatureVector which calls the FeatureFloodCount. There you can see the var to feature map being created in the updateFieldInfo

It's a map indexed by feature id, containing vectors indexed by variable index, which contain the feature id

  std::map<dof_id_type, std::vector<unsigned int>> _entity_var_to_features;

There must be a reason for that design, I think maybe a distinction between local ids and other feature ids