Introduction and basic concepts

In order to be able to transform different finite element Human Body Model (HBM) using the same methodology, different types of concepts were formulated and corresponding files format created. While this can be intimidating for new users, understanding at least the basic concepts is really beneficial to use the application. The basic concepts are not specific to the PIPER framework and are needed in any scaling or positioning process.

HBM interpretation and description: there is typically nothing in the FE format linking an entity to an anatomical structure. For example, while there are keywords indicating what an airbag or a spotwelt is, there is no keyword to indicate that something is a bone, a femur, or the head. Model authors make their best to use descriptive names but there is no standard for that either. It is therefore desirable to associate some of the FE entities to anatomical concepts as these are useful for scaling or positioning (e.g. a bone is not expected to deform during positioning to the contrary of the skin). This association between the FE entities and anatomical entities is made through Metadata and only needs to be done once for a given model. To try to standardize a little bit the names of the anatomical concepts, a database containing vocabulary and relationships between anatomical entities is also provided with PIPER (AnatomyDB).
what needs to be described and imported by PIPER? It depends on what you are trying to do but typically, not everything. A few pointers:
- For a simple geometrical transformation, only the FE node positions need to be updated. These can be easily read once PIPER knows how they are stored in the FE input format (typically a node number and coordinates). This is achieved using parsing rules that can be created and edited by the user to add functionality (see Multi Finite Element Format Parser). Knowing where the nodes are in the FE input is also used to update their position at the end of the process. Basic geometry read for FE input files typically includes nodes and elements (to be able to display the model). This description only needs to be done once per FE solver.
- For positioning, it seems desirable to describe the bones (so that they are not deformed) and their relationships (skeletal structure, joints). For scaling, it also seems desirable to describe the body structure such that the various body segments characteristics (length, section) can be updated separately.
- Overall, what needs to be described depends on each transformation module. Minimum requirements to be able to use a module are provided in the documentation of each module. The information is only defined once and shared between modules.
where is the data that is imported stored? What is imported is an anatomical interpretation of a Human Body Model including information required for positioning or scaling. As it is a model of its own, we called it a PIPER model (or PIPER HBM, PIPER Model). It is build dynamically every time a FE HBM is imported. The PIPER model can be accessed and updated by all modules and also by the scripting interface. It is not needed to export the FE model after each transformation (the PIPER model just gets updated), and the PIPER model can even be saved.
how is the transformation specified? For any transformation, it is needed to define a source and target. In broad terms, the target is what the user would like to obtain (a position, a stature, a specific dimension, ...). However broad terms are typically not sufficient to fully define the transformation. In PIPER, the target is a collection of various types of information (e.g. age, stature, anthropometric dimension, joint angle, bone position, control point position) that are used to specify and drive the model transformation. The target information is accessible by all modules and it can be saved to be reused later. The PIPER framework and modules can help the user define the target with more specificity:
- the target can be augmented by using a priori knowledge such as anthropometric regressions, or spinal postural preferences
- a target can be adjusted interactively by the user (e.g. visual positioning or visual section adjustment)

It must be noted that these various concepts are also present in previous scaling or positioning approaches in the literature but that they are not formulated explicitly (e.g. a morphing Matlab script reads a specific model and scale it to a target). By formulating them, it is hoped that the PIPER framework can help using the same methods for different models, and help with the reproducibility of the transformation.

PIPER Files

This section provides information on the files used in PIPER:

Finite Element Model: The Finite Element Model is the Human Body Model (HBM) in its original vendor format (e.g. : LS-DYNA ©, Pam-Crash ©, RADIOSS ©).
PIPER Model: The PIPER model is the model saved by the PIPER application in its own xml format. Two associated files constitute the PIPER model:
1. .vtu file: stores nodes and elements of the model in VTK Unstructured grid format.
2. .pmd file: stores other components of the PIPER model in xml-based format.
PIPER Project: when a project is saved, the followings files are created:
1. .ppj file: the piper project file. This xml-based file contains:
  - Reference to the PIPER model saved with the project
  - The description of target(s) for positioning if exists
  - The description of body dimensions(s) for personalizing if exists
  - Reference to environments files if exists
2. the PIPER model (.vtu and .pmd)

Overview of files manipulated by the PIPER application

PIPER Model

The PIPER model is composed of various components defined for their relevance in the positioning or scaling process. They do not aim to reproduce exactly the structure of the FE model but only to capture the different types and anatomical entities that need to be transformed in the process. A PIPER model contains both Geometry and specific Metadata.

Geometry

The following components are defined to describe the geometry and the structure of the PIPER Model:

node components: correspond to nodes in the Finite Element Model.
element components: correspond to elements in the Finite Element Model with distinction between one-dimensional, two-dimensional and three-dimensional element type.
coordinate system: A local coordinate system defined in the PIPER model.
group components: correspond to groups of nodes, groups of elements by type (1D/2D/3D) or groups of groups.

Metadata

The metadata are used to describe anatomical structure and functional constraints of the finite element model.

Entity

An entity defines an anatomical structure of the Human Body Model (bones, organs....). An entity corresponds to a set of group of elements (or group of groups) defined in the Finite Element Model. Naming of the entities must respect the PIPER anatomy database of entities (Appendix: List of entities), and the nature of the entity (skin, bone, ligament,...) and other information are deduced from this database. This dictionary is partially based on the FMA ontology (http://sig.biostr.washington.edu/projects/fm).

Joint

A joint can be used to describe the articulation between two entities. It is mainly used within the concept of positioning. An entity joint is defined by:

names of entities involved in the joint.
a coordinate system associated with each entity involved in the joint.
the definition of degree of freedom of the joint.

Notes: When joints between bones are defined as generalized joints in the HBM, it could be desirable to use the same definition in the metadata (same frames, etc).

Anatomical Joint

An anatomical joint is similar to a joint. It is defined by its name which must be in Appendix: List of joints and its degree of freedom. From the name the following anatomical knowledge is deduced :

the entities involved in the joint
the coordinate system associated with each entity are computed from landmarks (see Appendix: List of frames)

Landmark

A landmark is used to describe a specific anatomical location (that could be found in a reproducible manner by someone with anatomical knowledge). Three types of landmark can be defined:

type point: defined by 3D coordinates.
type sphere: defined by the center of the least squares sphere deduced from a group of nodes.
type barycenter: defined by the barycenter of a group of nodes.

The naming of the landmark must respect the PIPER anatomy Database of Landmark (Appendix: List of landmarks). Among others, the anatomy database is usefull:

to know which entity (e.g. bone) the landmark should be associated with,
to compute anatomical frames (Appendix: List of frames),
to compute Anatomical Joint,
etc... If needed, the database could be extended (see Anatomy Database).

Contact

A contact is defined between two entities. the contact can be defined as a "sliding" contact or an "attached" contact.

Note: corresponding FE concepts would be sliding without separation and tied.

Control Points

It defines a set of control points to be used in the geometrical interpolation/morphing module (Kriging Module).

Model Parameter

A parameter is a scalar value that corresponds to a property in the Finite Element model. It can be a material law parameter, a part property, a shell thickness, ...

Named Metadata

A named metadata defines a set of model geometrical elements (nodes, 2d, 3d elements) and associates a name to it. It is used in specific modules such as Pre-Positioning Module or Contour Deformation Module . This approach allows defining metadata that does not fit the definition of the previous subsections (e.g. not an anatomical landmark) but that a module can recognize through its name.

Module

Inputs/Outputs

A module provides a functionality in the PIPER application. It has a well defined interface:

the parameters of its numerical methods
the metadata it needs
the input targets it can load
the output targets it can produce
whether it can modify the model, only the nodes coordinates or the full geometry
the other input/output it can deal with

Workflow

To perform a complete task the user can run several modules in sequence, save intermediate results (targets or model) to work with later in the application or using the Batch mode

A typical workflow is:

import a HBM from its vendor format files (see Project menu)
check and explore the imported model with the Check Module
produce some anthropometric targets using the Anthropo Module
scale the HBM according to these targets using the Kriging Module
position the HBM in an environment using the Pre-Positioning Module and produce bone positions and landmarks targets
deform the HBM using the Fine-Positioning Module using the bone positions targets and update the model nodes position
or deform the HBM using the Contour Deformation Module using the landmarks targets and update the model nodes position
check the element quality, and improve it if needed using the Smoothing module
export the HBM to its original vendor format files (see Project menu)

At any time in his workflow, the user can run custom operations by Writing a script

Model history

In the "Model History" menu:

the current model can be renamed
the baseline model ("the reference") can be imported as the root of the history. This re-imports the FE model in the PIPER application
the list of history content is provided with the current model in bold. The selection of another model in history makes it current.

Each time the human body model is transformed (for positioning or personalizing), the transformed model is added in the history and is set as the current model.
Be aware that when a new model is loaded (either by loading a new PIPER project or by importing a new model), all the current history entries are deleted. Also, models cannot currently be deleted from the history.

Table of Contents