Could Not GetMaterialProperty in Kernel

[FanZhangchen]

Check these boxes if you have followed the posting rules.

• Q&A General is the most appropriate section for my question
• I have consulted the posting Guidelines on the Discussions front page
• I have searched the Discussions forum and my question has not been asked before
• I have searched the MOOSE website and the documentation does not answer my question
• I have formatted my post following the posting guidelines (screenshots as a last resort, triple back quotes around pasted text)

Question

Hi,

I have met a problem I could not get material property from a material subroutine. I tried to print out the output of the material property with MooseWarning, and it has some values inside the quadrature point. However, when I tried to use ElementAverageValue to determine whether the kernel got the material property, I found it is zero and does not change over time. So I wonder if I might make some mistakes in the kernel or material subroutine. Could you give me some advice? Thank you.

Here is the material subroutine that I declared the material property:

_edge_dislocation_increment(declareProperty<std::vector<Real>>("edge_dislocation_increment")),
    _edge_dislocation_increment_old(
        getMaterialPropertyOld<std::vector<Real>>("edge_dislocation_increment")),

    _screw_dislocation_increment(declareProperty<std::vector<Real>>("screw_dislocation_increment")),
    _screw_dislocation_increment_old(
        getMaterialPropertyOld<std::vector<Real>>("screw_dislocation_increment"))

And here is the code in kernel

_edge_dislocation_increment(
        getMaterialProperty<std::vector<Real>>("edge_dislocation_increment")),
    _screw_dislocation_increment(
        getMaterialProperty<std::vector<Real>>("screw_dislocation_increment")),

And is there any test I could use to find out where leads to the problems?

Best,

Zhangchen

[GiudGiud]

Hello

ElementAverageValue only works with variables
https://mooseframework.inl.gov/source/postprocessors/ElementAverageValue.html

For material properties you would work with this one:
https://mooseframework.inl.gov/source/postprocessors/ElementAverageMaterialProperty.html

This looks fine.
Can you check the header too for the declarations of _edge_dislocation_increment and _screw_dislocation_increment in both the material and the kernel?

Guillaume

[FanZhangchen]

I have checked it using Exodus output, and it is also zero. And in the calculation, the material property should contribute to generate some dislocation in the kernel part and I did not find any generation of dislocation in the Exodus. So I think it might something wrong in my code.

But I have a question here

I used a MaterialStdVectorAux, so should it be a vector?

[GiudGiud]

MaterialStdVectorAux only outputs one component at a time. You are looking at component 0

[FanZhangchen]

Thank you for your correction. I changed the index to the other component, and some are not zero which is correct for my understanding. But it is not the problem in my code. Could you please see my kernel part code if the _edge_dislocation_increment is correctly called in it?

Real
ConservativeAdvectionSchmid::negSpeedQp()
{
  Real edge_sign;

  switch (_dislo_sign)
  {
    case DisloSign::positive:
      edge_sign = 1.0;
      break;
    case DisloSign::negative:
      edge_sign = -1.0;
      break;
  }

  _velocity.resize(3, 0.0);

  // Find dislocation velocity based on slip systems index and dislocation character
  switch (_dislo_character)
  {
    case DisloCharacter::edge:
      for (const auto j : make_range(LIBMESH_DIM))
      {
        _velocity[j] =
            _edge_slip_direction[_qp][_slip_sys_index * LIBMESH_DIM + j]; // edge direction
      }
      break;
    case DisloCharacter::screw:
      for (const auto j : make_range(LIBMESH_DIM))
      {
        _velocity[j] =
            _screw_slip_direction[_qp][_slip_sys_index * LIBMESH_DIM + j]; // screw direction
      }
      break;
  }

  for (const auto j : make_range(LIBMESH_DIM))
  {
    _velocity[j] *= _dislo_velocity[_qp][_slip_sys_index]; // velocity value
    _velocity[j] *= edge_sign;                             // positive or negative dislocation
  }

  return -_grad_test[_i][_qp] * RealVectorValue(_velocity[0], _velocity[1], _velocity[2]);
}

Real
ConservativeAdvectionSchmid::computeQpResidual()
{
  // This is the no-upwinded version
  // It gets called via Kernel::computeResidual()
  _statis_stored_dislocation.resize(12, 0.0);
  _statis_stored_dislocation_increment.resize(12, 0.0);
  switch (_dislo_character)
  {
    case DisloCharacter::edge:
      _statis_stored_dislocation[_slip_sys_index] =
          _edge_dislocation_increment[_qp][_slip_sys_index]; // edge ssd
      break;
    case DisloCharacter::screw:
      _statis_stored_dislocation[_slip_sys_index] =
          _screw_dislocation_increment[_qp][_slip_sys_index]; // screw ssd
      break;
  }

  switch (_is_ssd_inclued)
  {
    case SSDInclude::yes:
      _statis_stored_dislocation_increment[_slip_sys_index] = _statis_stored_dislocation[_slip_sys_index];
      break;
    case SSDInclude::no:
      _statis_stored_dislocation_increment[_slip_sys_index] = 0.0;
      break;
  }

  return negSpeedQp() * _u[_qp]+ _statis_stored_dislocation_increment[_slip_sys_index];
}

[GiudGiud]

This looks fine to me but I know very little on this
Can you describe the larger picture? which field? which application?
and I ll tag someone who will know more

[FanZhangchen]

Here is the formulation I want to implement. A dislocation density field-based kernel describes the evolution of the dislocation gliding (the transport term), rotation, and source-sink terms. The kernel I mentioned includes the gliding term and the source term. The rotation term is updated in another kernel. The source-sink term is updated explicitly in the material kernel. That's what I want to simulate.
I got inspiration from Nicolo Grilli.