Dyadic operations to construct symmetric 4th order tensor

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts
  • Huidong
    Junior Member
    • Dec 2023
    • 2

    Dyadic operations to construct symmetric 4th order tensor

    Hi there.

    I am using the dyadic operation to construct symmetric 4th order tensor.

    I have no doubt about FEBio's dyadic operation function: dyad1s(a): (a dyad1s a)_ijkl = a_ij a_kl

    But I have been confused about the dyadic operation function: dyad1s(a, b): (a dyad1s b)_ijkl = a_ij b_kl + b_ij a_kl

    Is it correct to do by this expression? dyad1s(a, b): (a dyad1s b)_ijkl = a_ij b_kl

    Thanks in advance.

    Regards,
    Huidong

  • ateshian
    Developer
    • Dec 2007
    • 1839

    #2
    Hi Huidong,

    In a strict sense, the (first) dyadic product of 2nd-order symmetric tensors, dyad1s(a, b): (a dyad1s b)_ijkl = a_ij b_kl, is not a symmetric fourth-order tensor (it satisfies two minor symmetries, since a_ij = a_ji and b_kl = b_lk) but it doesn't satisfy the major symmetry (c_ijkl ≠ c_klij). However, dyad1s(a, b): (a dyad1s b)_ijkl = a_ij b_kl + b_ij a_kl creates a fully symmetric 4th-order tensor, and that's usually what we see in the derivation of elasticity tensors.

    Note that FEBio has a class (tens4dmm) of 4-th order tensors with only two minor symmetries. This class allows you to evaluate the dyadic product that you mention (see tens4d.h and tens4d.cpp):
    // (a dyad1 b)_ijkl = a_ij b_kl
    inline tens4dmm dyad1mm(const mat3ds& a, const mat3ds& b)

    Best,

    Gerard

    Comment

    • Huidong
      Junior Member
      • Dec 2023
      • 2

      #3
      Thanks Gerard for your rapid reply.
      In that case, would it be more appropriate to define dyad1s(a, b): (a dyad1s b)_ijkl = (a_ij b_kl + b_ij a_kl)/2 ?

      Comment

      • ateshian
        Developer
        • Dec 2007
        • 1839

        #4
        In principle yes, but as I hinted above, when applied to the elasticity tensor calculation it turns out that the dyadic product is always given in the form currently implemented in the code (without the factor of 1/2). So it seemed computationally logical to remove the factor of 1/2.

        Best,

        Gerard

        Comment

        Working...
        X