You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
In order to simplify the addition of this, I'm working on adding a material-specific QuadratureFunction and QuadratureSpace into MFEM. After this is in there, we can start refactoring various parts of the code to work with these classes and finally get multi-material support with the initial caveat that they're the same class of models aka ECMech only or UMAT only and no mixing of the two. It's possible this might complicate things as well once ECMech gets native J2 and Barlat yld2004-18p models added to it. Once those are added, we'll probably also want to revisit and decide if a further restriction on only allowing crystal models to operate with crystal models is wanted or if we'll allow mixing of the two. I do see a benefit of mixing the two models, if you imagine having the J2 model surround the crystal material or have it on like the boundaries... Although, we'll get into some very fun issues related to load balancing with that mixing of things...
One thing that will need to be modified outside the physics classes is the options class/parsing as things will be more complicated. We'll need to allow multiply supplied crystal types, models, and property/state files. We'll have to add in a phase map file for the serial mesh. This phase map will get mapped to the mesh attributes after the initial mesh attributes/grain IDs are used to instantiate everything. Afterwards, we'll map the phase IDs onto the mesh attributes. If only MFEM supported multiple attributes for mesh element attributes this would be easier... One good thing is we can save the grain IDs later on to the data collections so we'll have them there.
The text was updated successfully, but these errors were encountered:
In order to simplify the addition of this, I'm working on adding a material-specific
QuadratureFunction
andQuadratureSpace
into MFEM. After this is in there, we can start refactoring various parts of the code to work with these classes and finally get multi-material support with the initial caveat that they're the same class of models aka ECMech only or UMAT only and no mixing of the two. It's possible this might complicate things as well once ECMech gets native J2 and Barlat yld2004-18p models added to it. Once those are added, we'll probably also want to revisit and decide if a further restriction on only allowing crystal models to operate with crystal models is wanted or if we'll allow mixing of the two. I do see a benefit of mixing the two models, if you imagine having the J2 model surround the crystal material or have it on like the boundaries... Although, we'll get into some very fun issues related to load balancing with that mixing of things...One thing that will need to be modified outside the physics classes is the options class/parsing as things will be more complicated. We'll need to allow multiply supplied crystal types, models, and property/state files. We'll have to add in a phase map file for the serial mesh. This phase map will get mapped to the mesh attributes after the initial mesh attributes/grain IDs are used to instantiate everything. Afterwards, we'll map the phase IDs onto the mesh attributes. If only MFEM supported multiple attributes for mesh element attributes this would be easier... One good thing is we can save the grain IDs later on to the data collections so we'll have them there.
The text was updated successfully, but these errors were encountered: