Review pyomeca: future directions

[mitkof6]

Dear authors,

Thanks a lot for the excelent documentation and setting up everything in accordance with the software best practices.

I want to better understand your future directions and vision about this project.

The API and the use cases seem nice, however, in terms of added value it does not bring much to the user except basic operations such as reading, writing, filtering and plotting. I would find it very useful, if this framework goes a step forward and provide functions for processing and extracting meaningful clinical outputs from the raw data. For example, it would be very nice if you provide common utilities for extracting the kinematics and kinetics ensembles per gait cycle, or calculate cadence, speed, etc.

On the other hand, by looking at the repositories under pyomeca it seems that you are working on some nice packages that try to manipulate c3d files or interface with OpenSim. Is pyomeca only related to the features that were described in the publication or is it going to be something bigger where you will provide additional modules in the future? Please indicate your vision about this project and things you plan to support in the future. Are the projects under pyomeca intended for this publication or they will be published in the future?

[romainmartinez]

Thanks a lot for the excellent documentation and setting up everything in accordance with the software best practices.

We would like to thank you for those kind words.

The API and the use cases seem nice, however, in terms of added value it does not bring much to the user except basic operations such as reading, writing, filtering and plotting.

While these features may seem basic, they remain necessary and useful in the daily workflow of a biomechanical researcher.
We realized that different labs and developers/students within the same lab waste valuable time writing functions that perform these tasks.
Every lab needs these features and, by offering a single, sufficiently efficient and flexible implementation, pyomeca standardizes these procedures and avoids writing those functions that sometimes have nothing to do with sciences.

pyomeca also offers non-trivial functionalities, which are — in our opinion — useful to many researchers:

• rigid body mechanics: Euler angles to/from homogeneous matrices and homogeneous matrices to/from markers
• normalization: time and amplitude normalization
• fft, onsets and outliers detection

We have some ideas for functions that could extend pyomeca, particularly concerning the construction of kinematic models such as algorithms to find axes/centre of rotation or joint angles.

I would find it very useful, if this framework goes a step forward and provide functions for processing and extracting meaningful clinical outputs from the raw data. For example, it would be very nice if you provide common utilities for extracting the kinematics and kinetics ensembles per gait cycle, or calculate cadence, speed, etc.

We agree and we plan to add more "high-level" modules that extract clinical variables.
As of today, we believe pyomeca is a solid foundation for more advanced research implementations.
For example, we plan to add modules to compute ergonomic variables (kinematics, emg and musculoskeletal) as well as support for inertial sensors.
Being in a research lab, pyomeca's development is feature-based.
We develop software solutions to meet our research needs, and we wish to promote and share these solutions with the community in high quality libraries for use in research and education.
As for gait analysis, Philip Dixon — who is a new professor in our laboratory — has developed BiomechZoo, a Matlab toolbox specifically designed for gait analysis.
After some discussion, he plans to translate his toolbox in Python to support an open-source language and take advantage of pyomeca's development.
Being a GUI, BiomechZoo could handle the visual and be sufficient for practitioners and non-developer users, while the backend would be managed with pyomeca.

On the other hand, by looking at the repositories under pyomeca it seems that you are working on some nice packages that try to manipulate c3d files or interface with OpenSim. Is pyomeca only related to the features that were described in the publication or is it going to be something bigger where you will provide additional modules in the future?

Please indicate your vision about this project and things you plan to support in the future. Are the projects under pyomeca intended for this publication or they will be published in the future?

We are indeed developing several libraries in parallel with pyomeca.
We are inspired by the UNIX philosophy for the architecture and interaction of our programs.

As such, we:

• design each program to do one thing well
• expect the output of every program to become the input to another, as yet unknown, program.
  In other words, we would like to build libraries that do one thing and do it well and we write them to work together.
  We emphasize simple, short, clear, modular and flexible code that can be easily maintained and repurposed by third party developers.

As opposed to a more monolithic design, the benefits of this approach are:

• easier maintenance
• easier to scale
• smaller code base
• stronger support and communication for smaller and parallel teams
• technology variety. Some of our libraries are written in C++, other in python

Let's take our ezc3d library as an example.
It has one and only one function: opening and writing c3d files.
Although this sounds basic, it is absolutely necessary in our workflow.
Other libraries for reading c3d, such as BTK, have chosen to integrate other modules such as gait event detection (btkVerticalGroundReactionForceGaitEventDetector) or angle direction computation (btkWrenchDirectionAngleFilter).
In our humble opinion, this adds to the maintenance and dependency requirements, and should be offered in a separate library.

For this reason, rather than developing a massive biomechanics library, we have several small libraries that are interdependent as show in the following figure:

As we mentioned in the previous paragraph, pyomeca may eventually offer some "high-levels", clinical variables, but the main features will remain those described in this publication.
This publication is limited to pyomeca only.
Other publications are in progress for other projects (namely biorbd, biorbd-viz, BiorbdOptim and ezc3d) that target a different audience and different needs.

[mitkof6]

Hi @romainmartinez,

Thanks a lot for your detailed response. I agree with you and I like your arguments. Please iterate over the manuscript one more time and include some of the points in your response. In particular, please improve the statement of need mentioning your response to the question:

The API and the use cases seem nice, however, in terms of added value it does not bring much to the user except basic operations such as reading, writing, filtering and plotting.

In the summary, you can include your philosophy on having simple and powerful modules that are modular and easy to develop.

If you agree, it would be nice to have a conclusion section where you will outline your vision for this project and how it might evolve. It would be nice to mention how pyomeca will interact with other modules such as pyosim or biorbd-viz.

Thanks!