Transition to Open File Formats for OpenFEDEM

[oeysstra]

As part of our commitment to open-source principles and to enhance interoperability, we are proposing a transition from proprietary file formats to open file formats within OpenFEDEM. This transition will improve accessibility, flexibility, and integration with other tools and systems. The key changes we are considering include:

Model Input File Format: Transition from the proprietary .fmm format to the more widely used and readable YAML format.

Solver Results Format: Transition from the proprietary .frs format to the versatile and efficient HDF5 format.

STEP support: Enable import and export functionalities for STEP files, facilitating better integration with CAD and other engineering tools e.g. sensor specification and locations.

We believe these changes will bring significant benefits, including easier data manipulation, better version control, and broader compatibility with various software tools. We invite the community to share their thoughts, experiences, and suggestions on these proposed transitions. Your input is crucial to ensure that the changes meet the needs and expectations of our users and contributors.

[oeysstra]

Extending YAML Input Syntax in OpenFEDEM

OpenFEDEM already provides a Python API for script-based modeling and a YAML input syntax for the most commonly used features. Currently, the YAML format serves primarily as an import format, and any modifications outside the YAML file may result in corrupt relationships within the model.

I propose extending the features supported by the YAML file to cover all aspects currently managed by the proprietary .fmm file. This extension would potentially eliminate the need for the .fmm file, at least from the end user's perspective.
Benefits:

Simplification: Users would interact with a single, open format, simplifying the workflow and reducing the learning curve.
Transparency: YAML is human-readable, which enhances transparency and makes it easier to troubleshoot and modify models.
Interoperability: Improved compatibility with other tools and systems that support YAML.

Implementation Considerations:

• Completeness: Ensure that all features and capabilities currently handled by the .fmm file are fully supported by the YAML syntax.
• Validation: Develop robust validation mechanisms to prevent corrupt relationships and ensure model integrity.
• Backward Compatibility: Provide a migration path for existing .fmm files to be converted to the enhanced YAML format.

Call for Input:
We invite the community to share their thoughts and suggestions on this proposal. Specifically, we seek input on:

• Key Features: Which additional features should be prioritized for inclusion in the extended YAML syntax?
• Validation Strategies: Best practices for validating YAML files to maintain model integrity.
• Migration Tools: Ideas for tools or scripts to facilitate the conversion of .fmm files to the enhanced YAML format.

NOTE: Embedding Ai and LLM in any part of the solution will be easier, more robust and require less fine-tuning if the yaml feature set has feature parity with the .fmm syntax when it comes to the model definition.

[oeysstra]

Enhancing YAML Input Syntax with Mating Features in OpenFEDEM

Currently, the YAML syntax in OpenFEDEM supports translation and orientation of objects. To further enhance the usability and functionality of our modeling capabilities, we propose adding mating features. These features would allow for more intuitive assembly definitions and ensure that parts are positioned correctly relative to each other.

Proposal:
Introduce mating methods for revolute joints, prismatic joints, fixed joints etc.
When a joint is defined between two parts, the parts is moved accordingly to reflect the joint's constraints.
This functionality can potentially also be considered in the GUI as well. I guess this will require a more wizard type of modeling procedures.

Constraint Feedback:
Implement mechanisms to provide feedback to the user when the assembly is geometrically under-constrained or over-constrained.
Clearly report what constraints are missing or need adjustment to achieve a valid assembly.

Benefits:
Less modelling efforts.
Allow users to define more complex and accurate assemblies directly in the YAML file.

User Guidance:
Provide clear feedback on constraint issues, helping users to quickly identify and fix problems in their models.

Call for Input:
We seek the community's input on the following aspects:

[freeNastran]

Interested in HDF5 format. Where to start?
HDF5 1.12 + h5fortran from https://github.com/geospace-code/h5fortran?