Creating a FEPermeability class

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts
  • ateshian
    Developer
    • Dec 2007
    • 1824

    Creating a FEPermeability class

    I would like to create a FEPermeability class which allows the definition of different constitutive relations for the permeability of the porous matrix in a biphasic/poroelastic material. The two member functions of this class would be

    //! permeability
    virtual void Permeability(double k[3][3], FEMaterialPoint& pt) = 0;

    //! tangent of permeability
    virtual tens4ds Tangent_Permeability(FEMaterialPoint& mp) = 0;

    which currently reside in FEPoroElastic. The reason for doing this is that the extension of FEBio to the modeling of solute transport will need to define a number of similar material classes, such as FEDiffusivity (for the diffusivity of solutes) and FESolubility (for their solubility) and we will need to be able to mix and match different choices of such material functions to describe a particular mixture.

    As suggested in a previous post, http://mrlforums.sci.utah.edu/forums...8&goto=newpost (related to a different topic, but with a suggestion relevant here), the structure of the input file could have the form

    <material id="1" type="poroelastic">
    <solid type="neo-Hookean>
    <!-- material parameters for neo-Hookean -->
    </solid>
    <permeability type="Holmes-Mow">
    <!-- permeability materials here -->
    </permeability>
    </material>

    This way, when we include solutes, we could define a material as follows:

    <material id="1" type="solid-solvent-solute">
    <solid type="neo-Hookean>
    <!-- material parameters for neo-Hookean -->
    </solid>
    <permeability type="Holmes-Mow">
    <!-- permeability materials here -->
    </permeability>
    <diffusivity type="referentially isotropic diffusivity">
    <!-- diffusivity materials here -->
    </diffusivity>
    <solubility type="constant solubility">
    <!-- solubility materials here -->
    </solubility>
    </material>

    For now, this structure would work for a single solute, but we would need to update it for multiple solutes.

    Gerard
  • maas
    Lead Code Developer
    • Nov 2007
    • 3400

    #2
    Hi Gerard,

    As you know, I am a fan of the nested material approach. I think it allows much more flexibility than the old approach. I have only one recommendation and that is in the "type", don't reference the property name again. So, use e.g.

    Code:
    <solubility type="constant">...</solubility>
    instead of

    Code:
    <solubility type="constant solubility">...</solubility>
    The reason is because I envision that many materials that we will be introducing will follow a similar pattern and for this reason I would like to formalize this kind of material structure a bit more. I am considering introducing the notion of a material attribute (in addition to material parameters). An attribute can be defined as a parameter, like

    Code:
    <solubility>1.0</solubility>
    which would be equivalent to,

    Code:
    <solubility type="constant">1.0</solubility>
    If each material attribute defines the "constant" type, it can use this shorthand notation. Only when it is not constant, you have to define the type explicitly. What do you think?

    Thanks,

    Steve.
    Department of Bioengineering, University of Utah
    Scientific Computing and Imaging institute, University of Utah

    Comment

    Working...
    X
    😀
    😂
    🥰
    😘
    🤢
    😎
    😞
    😡
    👍
    👎