\hypertarget{pageFramework_secFrameworkConcept}{}\subsection{Introduction and basic concepts}\label{pageFramework_secFrameworkConcept}
In order to be able to transform different finite element Human Body Model (H\+B\+M) 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 P\+I\+P\+E\+R framework and are needed in any scaling or positioning process.


\begin{DoxyItemize}
\item {\bfseries  H\+B\+M interpretation and description\+:} there is typically nothing in the F\+E 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 F\+E 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 F\+E entities and anatomical entities is made through \hyperlink{pageFramework_secFrameworkMetadata}{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 P\+I\+P\+E\+R (Anatomy\+D\+B).
\item {\bfseries  what needs to be described and imported by P\+I\+P\+E\+R? } It depends on what you are trying to do but typically, not everything. A few pointers\+:
\begin{DoxyItemize}
\item For a simple geometrical transformation, only the F\+E node positions need to be updated. These can be easily read once P\+I\+P\+E\+R knows how they are stored in the F\+E 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 \hyperlink{pageMultiformatParser}{Multi Finite Element Format Parser}). Knowing where the nodes are in the F\+E input is also used to update their position at the end of the process. Basic geometry read for F\+E input files typically includes nodes and elements (to be able to display the model). This description only needs to be done once per F\+E solver.
\item 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.
\item 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.
\end{DoxyItemize}
\item {\bfseries  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 P\+I\+P\+E\+R model (or P\+I\+P\+E\+R H\+B\+M, \hyperlink{pageFramework_secFrameworkModel}{P\+I\+P\+E\+R Model}). It is build dynamically every time a F\+E H\+B\+M is imported. The P\+I\+P\+E\+R model can be accessed and updated by all modules and also by the scripting interface. It is not needed to export the F\+E model after each transformation (the P\+I\+P\+E\+R model just gets updated), and the P\+I\+P\+E\+R model can even be saved.
\item {\bfseries  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 P\+I\+P\+E\+R, 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 P\+I\+P\+E\+R framework and modules can help the user define the target with more specificity\+:
\begin{DoxyItemize}
\item the target can be augmented by using {\itshape a priori} knowledge such as anthropometric regressions, or spinal postural preferences
\item a target can be adjusted interactively by the user (e.\+g. visual positioning or visual section adjustment)
\end{DoxyItemize}
\end{DoxyItemize}

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 P\+I\+P\+E\+R framework can help using the same methods for different models, and help with the reproducibility of the transformation.\hypertarget{pageFramework_secFrameworkFiles}{}\subsection{P\+I\+P\+E\+R Files}\label{pageFramework_secFrameworkFiles}
This section provides information on the files used in P\+I\+P\+E\+R\+:
\begin{DoxyItemize}
\item {\bfseries Finite Element Model\+:} The Finite Element Model is the Human Body Model (H\+B\+M) in its original vendor format (e.\+g. \+: L\+S-\/\+D\+Y\+N\+A \copyright{}, Pam-\/\+Crash \copyright{}, R\+A\+D\+I\+O\+S\+S \copyright{}).
\item {\bfseries P\+I\+P\+E\+R Model\+:} The P\+I\+P\+E\+R model is the model saved by the P\+I\+P\+E\+R application in its own xml format. Two associated files constitute the P\+I\+P\+E\+R model\+:
\begin{DoxyEnumerate}
\item {\ttfamily .vtu} file\+: stores nodes and elements of the model in V\+T\+K Unstructured grid format.~\newline

\item {\ttfamily .pmd} file\+: stores other components of the P\+I\+P\+E\+R model in xml-\/based format.~\newline

\end{DoxyEnumerate}
\item {\bfseries P\+I\+P\+E\+R Project\+:} when a project is saved, the followings files are created\+:
\begin{DoxyEnumerate}
\item {\ttfamily .ppj} file\+: the piper project file. This xml-\/based file contains\+:
\begin{DoxyItemize}
\item Reference to the P\+I\+P\+E\+R model saved with the project
\item The description of target(s) for positioning if exists
\item The description of body dimensions(s) for personalizing if exists
\item Reference to environments files if exists
\end{DoxyItemize}
\item the P\+I\+P\+E\+R model ({\ttfamily .vtu} and {\ttfamily .pmd})
\end{DoxyEnumerate}
\end{DoxyItemize}


\begin{DoxyImage}
\includegraphics[width=0.8\textwidth]{app_different_files.png}
\caption{Overview of files manipulated by the P\+I\+P\+E\+R application}
\end{DoxyImage}
\hypertarget{pageFramework_secFrameworkModel}{}\subsection{P\+I\+P\+E\+R Model}\label{pageFramework_secFrameworkModel}
The P\+I\+P\+E\+R 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 F\+E model but only to capture the different types and anatomical entities that need to be transformed in the process. A P\+I\+P\+E\+R model contains both \hyperlink{pageFramework_secFrameworkGeometry}{Geometry} and specific \hyperlink{pageFramework_secFrameworkMetadata}{Metadata}.\hypertarget{pageFramework_secFrameworkGeometry}{}\subsubsection{Geometry}\label{pageFramework_secFrameworkGeometry}
The following components are defined to describe the geometry and the structure of the P\+I\+P\+E\+R Model\+:
\begin{DoxyItemize}
\item node components\+: correspond to nodes in the Finite Element Model.
\item element components\+: correspond to elements in the Finite Element Model with distinction between one-\/dimensional, two-\/dimensional and three-\/dimensional element type.
\item coordinate system\+: A local coordinate system defined in the P\+I\+P\+E\+R model.
\item group components\+: correspond to groups of nodes, groups of elements by type (1\+D/2\+D/3\+D) or groups of groups.
\end{DoxyItemize}\hypertarget{pageFramework_secFrameworkMetadata}{}\subsubsection{Metadata}\label{pageFramework_secFrameworkMetadata}
The metadata are used to describe anatomical structure and functional constraints of the finite element model.\hypertarget{pageFramework_secFrameworkMetadataEntity}{}\paragraph{Entity}\label{pageFramework_secFrameworkMetadataEntity}
An {\itshape 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 P\+I\+P\+E\+R anatomy database of entities (\hyperlink{pageAppendixEntity}{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 \href{http://sig.biostr.washington.edu/projects/fm}{\tt F\+M\+A ontology (http\+://sig.\+biostr.\+washington.\+edu/projects/fm)}.\hypertarget{pageFramework_secFrameworkMetadataJoint}{}\paragraph{Joint}\label{pageFramework_secFrameworkMetadataJoint}
A {\itshape 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\+:
\begin{DoxyItemize}
\item names of entities involved in the joint.
\item a coordinate system associated with each entity involved in the joint.
\item the definition of degree of freedom of the joint.
\end{DoxyItemize}

Notes\+: When joints between bones are defined as generalized joints in the H\+B\+M, it could be desirable to use the same definition in the metadata (same frames, etc).\hypertarget{pageFramework_secFrameworkMetadataAnatJoint}{}\paragraph{Anatomical Joint}\label{pageFramework_secFrameworkMetadataAnatJoint}
An {\itshape anatomical joint} is similar to a {\itshape joint}. It is defined by its name which must be in \hyperlink{pageAppendixJoint}{Appendix\+: List of joints} and its degree of freedom. From the name the following anatomical knowledge is deduced \+:
\begin{DoxyItemize}
\item the entities involved in the joint
\item the coordinate system associated with each entity are computed from landmarks (see \hyperlink{pageAppendixFrame}{Appendix\+: List of frames})
\end{DoxyItemize}\hypertarget{pageFramework_secFrameworkMetadataLandmark}{}\paragraph{Landmark}\label{pageFramework_secFrameworkMetadataLandmark}
A {\itshape 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\+:
\begin{DoxyItemize}
\item type point\+: defined by 3\+D coordinates.
\item type sphere\+: defined by the center of the least squares sphere deduced from a group of nodes.
\item type barycenter\+: defined by the barycenter of a group of nodes.
\end{DoxyItemize}

The naming of the landmark must respect the P\+I\+P\+E\+R anatomy Database of Landmark (\hyperlink{pageAppendixLandmark}{Appendix\+: List of landmarks}). Among others, the anatomy database is usefull\+:
\begin{DoxyItemize}
\item to know which entity (e.\+g. bone) the landmark should be associated with,
\item to compute anatomical frames (\hyperlink{pageAppendixFrame}{Appendix\+: List of frames}),
\item to compute \hyperlink{pageFramework_secFrameworkMetadataAnatJoint}{Anatomical Joint},
\item etc... If needed, the database could be extended (see \hyperlink{group__anatomyDB}{Anatomy Database}).
\end{DoxyItemize}\hypertarget{pageFramework_secFrameworkMetadataContact}{}\paragraph{Contact}\label{pageFramework_secFrameworkMetadataContact}
A {\itshape contact} is defined between two entities. the contact can be defined as a \char`\"{}sliding\char`\"{} contact or an \char`\"{}attached\char`\"{} contact.

Note\+: corresponding F\+E concepts would be sliding without separation and tied.\hypertarget{pageFramework_secFrameworkMetadataInteractiveControlPoint}{}\paragraph{Control Points}\label{pageFramework_secFrameworkMetadataInteractiveControlPoint}
It defines a set of control points to be used in the geometrical interpolation/morphing module (\hyperlink{modulekriging}{Kriging Module}).\hypertarget{pageFramework_secFrameworkMetadataParam}{}\paragraph{Model Parameter}\label{pageFramework_secFrameworkMetadataParam}
A {\itshape 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, ...\hypertarget{pageFramework_secFrameworkMetadataNamedMetadata}{}\paragraph{Named Metadata}\label{pageFramework_secFrameworkMetadataNamedMetadata}
A {\itshape named metadata} defines a set of model geometrical elements (nodes, 2d, 3d elements) and associates a {\itshape name} to it. It is used in specific modules such as \hyperlink{modulePhysPosiInter}{Pre-\/\+Positioning Module} or \hyperlink{moduleContourDeformation}{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.\hypertarget{pageFramework_secFrameworkModule}{}\subsection{Module}\label{pageFramework_secFrameworkModule}
\hypertarget{pageFramework_secFrameworkModuleIO}{}\subsubsection{Inputs/\+Outputs}\label{pageFramework_secFrameworkModuleIO}
A module provides a functionality in the P\+I\+P\+E\+R application. It has a well defined interface\+:
\begin{DoxyItemize}
\item the {\bfseries parameters} of its numerical methods
\item the {\bfseries metadata} it needs
\item the {\bfseries input} {\bfseries targets} it can load
\item the {\bfseries output} {\bfseries targets} it can produce
\item whether it can modify the model, only the nodes coordinates or the full geometry
\item the other {\bfseries input/output} it can deal with
\end{DoxyItemize}\hypertarget{pageFramework_secFrameworkModuleWorkflow}{}\subsubsection{Workflow}\label{pageFramework_secFrameworkModuleWorkflow}
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 \hyperlink{pageScripting_secScriptingBatch}{Batch mode}

A typical workflow is\+:
\begin{DoxyEnumerate}
\item import a H\+B\+M from its vendor format files (see \hyperlink{pageGui_secGuiMenuProject}{Project menu})
\item check and explore the imported model with the \hyperlink{modulecheck}{Check Module}
\item produce some anthropometric targets using the \hyperlink{moduleAnthropometricPersonalization}{Anthropo Module}
\item scale the H\+B\+M according to these targets using the \hyperlink{modulekriging}{Kriging Module}
\item position the H\+B\+M in an environment using the \hyperlink{modulePhysPosiInter}{Pre-\/\+Positioning Module} and produce bone positions and landmarks targets
\item deform the H\+B\+M using the \hyperlink{modulePhysPosiDeform}{Fine-\/\+Positioning Module} using the bone positions targets and update the model nodes position
\item or deform the H\+B\+M using the \hyperlink{moduleContourDeformation}{Contour Deformation Module} using the landmarks targets and update the model nodes position
\item check the element quality, and improve it if needed using the \hyperlink{modulemeshoptim}{Smoothing module}
\item export the H\+B\+M to its original vendor format files (see \hyperlink{pageGui_secGuiMenuProject}{Project menu})
\end{DoxyEnumerate}

At any time in his workflow, the user can run custom operations by \hyperlink{pageScripting_secScriptingScript}{Writing a script}\hypertarget{pageFramework_secFrameworkHistory}{}\subsection{Model history}\label{pageFramework_secFrameworkHistory}
In the \char`\"{}\+Model History\char`\"{} menu\+:
\begin{DoxyItemize}
\item the current model can be renamed
\item the baseline model (\char`\"{}the reference\char`\"{}) can be imported as the root of the history. This re-\/imports the F\+E model in the P\+I\+P\+E\+R application
\item the list of history content is provided with the current model in bold. The selection of another model in history makes it current.
\end{DoxyItemize}

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.~\newline
Be aware that when a new model is loaded (either by loading a new P\+I\+P\+E\+R project or by importing a new model), all the current history entries are deleted. Also, models cannot currently be deleted from the history.\hypertarget{pageFramework_secFrameworkTarget}{}\subsection{Target}\label{pageFramework_secFrameworkTarget}
