|
Size: 8864
Comment:
|
Size: 7847
Comment:
|
| Deletions are marked like this. | Additions are marked like this. |
| Line 56: | Line 56: |
| As part of the release of FEBio2 I am working on a new file format for the input files. This new format defines the Geometry in terms of named element sets, where an element set groups elements of the same type and material. Multiple named element sets can be defined. The structure is very similar to the Abaqus format in terms of element definitions. For example: {{{ <Elements type="hex8" mat="1" name="Part01"> <elem id="1">1,2,3,4,5,6,7,8</elem> <elem id="2">9,10,11,12,13,14,15,16</elem> </Elements> <Elements type="quad4" mat="2" name="Part02"> <elem id="3">17,18,19,20</elem> </Elements> }}} A similar structure can be added for surfaces and node sets. A specific case study might be helpful in determining the specifics of this capability. -- ["aerdemir"] [[DateTime(2013-12-20T09:20:59Z)]] This is great initiative. Will it be possible to add the same element(node/surface) to different sets? Will set information be available in the output file? We will provide a test problem. |
This page prioritizes and provides specifications for feature requests associated with FEBio development.
Target Outcome
Implementation of analysis and pre- & post-processing related features in FEBio to accommodate simulations conducted using Open Knee(s)
Priority List for Implementation
- In situ strain
- Element, node, and surface set definitions
- Connector elements for joint coordinate system
- Penetration based contact
- Spring elements with wrapping
- Shell elements for cartilage
Features Related to Constitutive Modeling
In Situ Strain
Description
The zero force reference lengths (or "slack length") of the ligamentous knee structures have been shown to be important contributors to overall joint mechanics. As they are difficult to measure, ligament slack lengths are a commonly targeted parameter during optimization of specimen-specific joint level kinetic-kinematic response. Regardless of the level of refinement in the modeling approach, whether continuum or spring based, a parameter based representation facilitates these iterative studies.
Ideally, this behavior could be defined either along the ligament line of action or locally within a given element. While the local mesh coordinate frames could be used to approximate a ligament's line of action (if hexahedral elements are used), it would also be convenient to incorporate ligament wrapping, without needing to remesh to reflect this behavior (if possible).
Test Problem
The test problem will be developed using the following:
- Geometry/Mesh: a 1 by 1 by 10 mm mesh with fiber direction defined along the 10 mm length.
- Boundary Conditions: a ramp displacement profile (+/- 2.5 mm load-unload) applied to one end of the mesh along the fiber direction (see figure below). The other end is fixed.
- Material Model: a fiber based model, e.g. transversely isotropic Mooney-Rivlin.
Sensitivity: fiber direction in situ strain values ranging -0.2 to +0.2, in 0.1 increments.
- Output: force-displacement response of the loaded end of the mesh.
- For application in Open Knee(s) simulations, implementation in both implicit static and implicit dynamic analyses.
ImageLink(FEBio_insitu_test.png, width=600, alt=Experimentation Workflow)
Estimated Completion
April, 2014
Progress
See ["Febio/InSituStrain"].
Features Related to Pre-/Post-Processing
Set Definitions for Elements, Nodes, and Surfaces
Description
The ability to define node, element, or surface sets could add convenience to both the pre- as well as post-processing of FEBio analyses. Often, models are made up of multiple components while the output(s) of interest may be limited to a specific component, or an even smaller region of interest. In terms of pre-processing, element sets could be used to assign material properties or request specific types of output for a given region. For post-processing, instead of searching across all elements (or nodes) in a model, and cross-referencing for specific element numbers, one could simply extract the region of interest by name.
Test Problem
Estimated Completion
September, 2014
Progress
See ["Febio/SetDefinitions"].
Features Related to Rigid Body Kinematics Representations
Local Coordinate Systems
Connector Elements for Joint Coordinate Systems
Description
Joint level simulations, especially in the knee, often rely on application and/or description of kinetic-kinematic response in commonly accepted joint coordinate systems (e.g. Grood and Suntay, JBME, 1983). This requires adoption of moving local coordinate systems that are assigned to a given body, e.g. the femur and tibia, to track overall rigid body motions as well as a means to "connect" two coordinate frames. In the case of Abaqus, we often use what's called "connector" elements to setup such frames. Their convenience is evident during model setup, prescription of joint level boundary conditions, as well as post-processing of the model results, where the connector outputs can be directly translated into clinically accepted descriptions of motion and/or loading.
In a Grood and Suntay convention, the following vector can be used to describe the position of an embedded tibial coordinate frame with respect to the femoral frame:
H = S1*e1 + S2*e2 + S3*e3
where e1, e2 and e3 are unit vectors along each of corresponding Si (i=1-3) magnitudes. e1 can be though of as the femoral flexion (FE) axis, while e3 is the internal-external (IE) rotation axis in the tibia and e2 is the common perpendicular between the two, i.e. the "floating axis."
In practice, all of the above can be combined to view the "connections" between two rigid bodies as a series of cylindrical joints:
If implemented in this way, the rotations, displacements and reactions about each of the cylindrical axes can be used to describe or apply the desired joint kinetics. For robustness, the embedded clinical axes (IE for the tibia or "T" frame above and FE for the femur or "F" frame) should have the capability to be defined within body specific local coordinate frames, which may or may not be the same as the global (model) coordinate frame. Essentially, this approach results in follower loads and/or kinematics that are a function of the relative motion between the two bodies.
For reference, the yellow lines in the following represent the cylindrical connectors implemented in a joint level analysis (frames were setup to describe both tibiofemoral and patellofemoral articulations). Displacements, rotations, and reactions (load and moment) for each joint can be specified or extracted in this setup. A "cylindrical" connector elements, which constrains motion between two nodes to a displacement and rotation about the primary axis (the yellow lines), were utilized.
Test Problem
To accomplish this feature request, we anticipate setting up a test problem with a known input-output relationship. This test problem could act as a surrogate for joint level simulations and could be as simple as a set of linear springs between two coordinate frames.
Estimated Completion
Late 2014
Progress
See ["Febio/RigidBodyMotions"].
FEBio has the capability to connect rigid bodies in a parent-child relationship, which effectively defines joints between rigid bodies. We are looking into the possibility of expanding this capability to include local rigid body representations. We are finding some issues with the applications of moments on connected rigid bodies, but hopefully once this issue is resolved we hope to make good progress on this task.
Features Related to Surrogate Modeling
Penetration Based Contact
Spring Elements with Wrapping
Shell Elements for Contact Problems
Features Related to Python Scripting
Open Knee(s) will require a scripting interface to streamline modeling and simulation workflows and for cloud computing. At this moment, Python is used to develop in-house code for building new models, changing template models, and post-processing results. [https://simtk.org/home/pyfebio PyFEbio] and planned scripting development by FEBio team will likely be helpful. In regard to modeling & simulation on the cloud using FEBio, a prototype is planned, see ["Specifications/CloudComputingPrototype"].