 |
PIPER
1.0.1
|
|
PIPER
1.0.1
|
The followings steps are typically required to import a Finite Element Human Body model (HBM) in the PIPER application:
Step 2 and Step 3 are detailed after the summary table below.
Summary of files needed to import a FE HBM and build the internal representation of the HBM (PIPER model)
| Contents | Format | Defined |
|---|---|---|
| Rules to parse the FE format (1) | .pfr (XML based) | once per FE format |
| Groups corresponding to anatomical or PIPER components | native FE format | once per HBM |
| Association between PIPER components and FE groups/entities | .pmr (XML based) | once per HBM |
(1) available pfr files are stored in the Piper/bin directory
The Model description file (xml based format with extension .pmr) is defined to:
If groups or FE entity are created specifically to be associated with these PIPER components, it is suggested to store them in separate include files of the FE format (see the example of the child model).
A typical overall structure of a model description file (.pmr) is shown below, with detailed descriptions of the components in the following subsections. The pmr file of the PIPER child model can also be used as an example.
Length units: m, dm, cm, mm
Mass unit: kg, dg, cg, mg
Age unit: year, month
The path of the main file to be imported to create the piper HBM need to be specified as follow. The path can be absolute or relative:
For the LSDyna and pamCrash FE formats, format rule files are provided with PIPER application, so only format name is required. The following format names are available;
If format rules required for parsing is not one of those provided with PIPER application, the format rule path (relative or absolute) can be specified:
Depending on the FE format of the input Human Body model, a FE component (nodes, groups, material...) is associated with an unique identifier which can be an integer or a name. To specify which FE component is involved in a association, the "keyword" element is used as follows (example considering LS-Dyna format and Pamcrash format):
In the first example, the FE component corresponding to the keyword *SET_SOLID (a group of solid elements in LS-Dyna) with an identifier equal to 10 is selected and used for the association rule. In the second one, the FE component corresponding to the keyword GROUP (a group in Pam-Crash) with an identifier name equal to groupname is selected and used for the association rule.
Entities are typically used to describe anatomical entities such as bones, skin, ligaments, etc. The list of available anatomical entities is provided in Appendix: List of entities .
The "entity" element defines association between group(s) of elements (or group(s) of part) in the FE Human Body Model and a Entity identified by name .
Example of "entity" element, the "entity" named Entity_1 is associated with FE components identified by:
The user has to first define group(s) of elements or a group(s) of parts in the Finite Element Model using their finite element pre-processor. All elements composing the anatomical entity must be included. For example, if the femur is modelled with 3d element for trabecular bone with an overlay of 2D elements for cortical bone, group(s) must include all 3D and 2D elements.
If 2D elements are included in the entity definition, normal orientation and topology must be carefully checked (the envelope should be closed, manifold, oriented coherently with normals pointing out). If this is not the case, the user can either modify their HBM or, as a workaround, add a part composed with null elements respecting these criteria to describe the outside boundary of the entity. The PIPER child model is an example of model with properly oriented normals.
If the original Finite Element format allows defining a group name, association between group and entity can be made in "auto" mode if the group name correspond to an entity name following PIPER dictionary.
To be able to use the auto mode, the group name must be parsed in the description of the rule to parse keyword corresponded to group in the considered FE format (Multi Finite Element Format Parser).
Example of "entity" element with "auto" mode: In this example, two FE group components identified by the keyword "kw_for_group_of_element3d" and ids 10 and 101 are considered and the name defined for each group is used to identified Entity to be associated with. If the group name identified by keyword "kw_for_group_of_element3d" and ids 10 is Left_femur, then this group is associated with Entity left femur.
Joints are typically used to articulate two bones with a robotic joint (which can match an anatomical convention or not).
To define a joint between two piper components, a frame is associated with each entity involved. This can be achieved using the "setFrame" element that identify the proper FE frame component using the "keyword" element. The "setDof" element is defined to specify degrees of freedom of the joint (relatively to frame defined for entity_1 of the frame).
Example 1:
In the example, a Joint named Joint_1 is defined between entity Entiyname1 and Entiyname2. Frame defined in the keyword "kw_frame" with id equal to 60010 is associated with Entiyname1 and Frame defined in the keyword "kw_frame" with id equal to 5050 is associated with Entiyname2. The degree of freedom of the joint are rotation relative to the X axis of the Entiyname1 frame and rotation relative to the Z axis of the Entiyname1 frame.
The global frame axis of the FE model can be used to define a joint frame (see example 2)
. Example 2:
In example, a Joint named Joint_1 is defined between entity Entiyname1 and Entiyname2. Frame defined in the keyword "kw_frame" and its orientation are identical to the global model frame (type="global"). The origin of the joint frame is defined by setting a node id. The degree of freedom of the joint are rotation relative to the X axis of the Entiyname1 frame and rotation relative to the Z axis of the Entiyname1 frame.
When springs or 6 d.o.f. joints are already used in the FE model to articulate bones, it is suggested to use that definition as the basis for the joint entity.
Landmarks are typically
The "landmark" element is used to associate FE groups of nodes and a Landmark identified by its name and type (point, barycenter, sphere). In the following example, a landmark with name Landmark_2 is defined by the group of node identified by the "keyword" element.
To define a landmark, the user has to define a group of nodes in the Finite Element Human Body Model in the Finite Element Model using their finite element pre-processor. The node number can also be used directly if only one node is needed.
If the original Finite Element format allows to define a group name, association between group and landmark can be made in "auto" mode if the group name correspond to an landmark name following the AnatomyDB definition for landmarks. To be able to use the auto mode, the group name must be parsed in the description of the rule to parse keyword corresponded to group in the considered FE format ( see Multi Finite Element Format Parser).
In order to describe a contact between entity1 and entity2, groups of nodes have to be defined to identify the contact region on both entities. In theory a contact is symmetric, but the way it is implemented in the Pre-Positioning Module it is not. entity1 shall be the entity which has its contact region always in contact.
Contacts are defined between groups of nodes. Their property includes a thickness parameter which can maintain the contact between the objects. An example of contact is provided below.
The parameter element is typically used for finite element parameters which are not described by nodes or elements (e.g. material properties, shell thickness).
The "hbm_parameter" element allows to gather parameters parsed with keyword format rules (PIPER Parameter operation) in a set. The parameternamesource corresponds to the name of the parameter defined in the rule to parse each keywords.
There is no specific model preparation for this element.
To define an ordered set of control points to be used as source control points in Kriging Module. Each set of control points must have a name (any unique string) and role ("source" or "target") attributes. There are several allowed formats for defining the coordinates of the control points, as shown on the example below: they can be defined either by a keyword or directly as a set of point coordinates, with or without IDs. Regardless of the coordinate definition, each set can also have a weight (Nugget) and a Skin/bone association parameters, as shown on the "control_points_2" set.
1.8.10 
