Comments
Comment #236 Kevin Logan @ 2026-08-04 10:02
I would like to thank Bernd Flemisch for his decision as well as the reviewers for their recommendation to publish the work. Thank you to Hamza Oukili for the thorough proofreading. I have corrected all highlighted errors and submitted the revised manuscript.
Comment #235 Bernd Flemisch @ 2026-07-28 10:23
I'd like to thank both reviewers for their evaluation of the revised manuscript. After incorporating the minor changes, the manuscript can be accepted for production.
Invited Review Comment #234 Hamza Oukili @ 2026-07-24 15:40
I thank the authors for revising the manuscript. The authors have addressed my main comments, and I believe the manuscript is now suitable for publication after minor revisions.
Line 5: “...in industry, e.g. for cooling chemical processes. should be "...in industry, e.g., for cooling chemical processes.","Missing comma after "e.g." (to match the correct usage in Line 3)."
Line 12: “To support researcher innovating control methods...,”. Typo: pluralize ""researchers"".
Line 41: “Some related tools are discussed in Section 1.2, ”. Missing period at the end of the sentence.
Lines 242, 252: “...context specific…”. Needs a hyphen here.
Lines 182, 306, 475: Replace “...a HDF5 file” with “....an HDF5 file”.
Line 338: “# here a custom PID controller is implemeted” should be “# Here a custom PID controller is implemented” Fix a typo.
Lines 281;302,…: sub packages / sub-package, subpackages or sub-packages. Pick one form and use it consistently throughout the paper.
Line 476: “...in a Master thesis project” should be”......in a Master's thesis project...”
Line 487: “...according to the RO-crate standard” should be “....according to the RO-Crate standard”, capitalization for Research Object Crate (RO-Crate).
Best,
Hamza Oukili
Invited Review Comment #232 Anonymous @ 2026-07-08 14:26
In my opinion, the manuscript is suitable for publication in its current form following the revisions that have been made.
Comment #226 Kevin Logan @ 2026-03-09 13:53
In the name of the authors, I would like to thank the reviewers for their comments. We have updated the software descriptor accordingly and made adjustments to the software repository for SOFIRpy. We hope that with these changes the submission meets with the approval of the reviewers and editor for publication.
Please find our detailed response to individual issues raised by the reviewers below.
## Review Comment #213
The FMI Standard, and what part of it are used within SOFIRpy should be discussed in more detail. I Example: Is it possible to couple system models with this approach, or only Controllers with Systems? How is time controlled within this coupling? (i. e. by using fixed integration step sizes).
*Thank you for highlighting that this is not clear. It is possible to couple system models using multiple FMUs and connecting their inputs/outputs. Furthermore, simulation and logging step sizes are declared for a simulation. Since each SimulationEntity implements it's own do_step() method and the defined time step is passed to that method, each entity progresses in time by the same step size and outputs get passed along the defined connections. SOFIRpy uses a class FMU that inherits from the general SimulationEntity class and uses the FMU2Slave class from FMI 2.0 to create a co-simulation FMU. We have added this information in lines 198-205.*
Is there a way to connect the stored results in HDF5 to specific version of the controllers source code? One suggestion would be to store it together with the code, i.e. using MLFlow (originating from machine learning applications)
*Thank you for the reference to MLFlow. The HDF5 file containing the results also contains the source code of the controllers as text as well as the class instances of the controllers used in the specific simulation pickled using cloud pickle. We have highlighted this in lines 149, 156, 214, 205-208.*
Meta data: Even given the goal of flexibility, a fixed minimum set of required Methadata would help the interoperability of this approach. (like date, subject, model version, controller version…)
*We agree that providing metadata helps interoprability and reusability of the approach. A minimum set of metadata as suggested are in fact already recorded. These mainly serve the purpose of recreating Run classes and so are used internally in the software itself. Further metadata, especially administrative metadata, is necessary for documenting the provenance of the data and automated discovery. These are not recorded by SOFIRpy by default, since the schemas, vocabularies or ontologies used are specific to the context in which SOFIRpy is used. We have clarified in lines 239-255 that a fixed minimum set of metadata are recorded with a focus on recreating simulation runs, but that further user-specific metadata would be necessary for ensuring full transparency. Since the recorded metadata are primarily intended for use within SOFIRpy itself, the use of standardized terms is not necessary. However, the further metadata for documentation and automated discovery would be used by other software and the used schemas, vocabularies and ontologies and would be context-specific. Here the use of standardized vocabularies and ontologies, e.g. metadata4ing, would be highly beneficial. However, this cannot be pre-determined by SOFIRpy. We have added a note in lines 485-487 stating that the creation of a metadataschema for describing SOFIRpy-created HDF5 files is a line of future development.*
For clarity 168 should include some hint to the goal of exporting form script (this is clear later, but points to the wrong direction)
*Thank you for raising this issue. We have included a clarification that this function is provided from within the code-based workflow.*
448 reads Government of the “Länder”, I am not sure if this is translated correctly
*This is the standard text for the funding acknowledgment as defined by the funder and was thus included unaltered in the manuscript.*
## Review Comment #215
1. Target Audience
The paper currently lists researchers, planners, and operators as potential users, but these groups have very different needs. Focus primarily on researchers, it is more realistic. The software doesn’t seem to focus on UI/UX.
*We have updated the text to focus on research and development engineers in academia and industry.*
2. Statement of Need
The current statement is generic and could apply to many tools. It should highlight the unique gaps SOFIRpy fills, mainly for Modelica.
*Thank you for highlighting this issue. We have included statements in lines 29-31 to stress the advantages of building on established modeling languages for physical systems (Modelica) and in lines 35-37 to emphasise the importance of an overarching workflow tool that provides methods for the entire workflow process of developing controllers for physical systems.*
Additionally, ensure consistency between Sections 1.1 and 1.2 regarding supported workflow steps, avoid implying that all five steps are fully covered Line 36 when only three are implemented.
*Thank you for drawing attention to this issue. We have clarified this in lines 49-51, referencing the section 'Scope' where it is further explained which of the workflow steps are directly addressed by SOFIRpy and where it supplies an framework for tying in existing tools.*
3. Proprietary Dependencies
The paper claims SOFIRpy “does not rely on proprietary dependencies,” yet mentions tools like Dymola (proprietary) for exporters. This ensures transparency and avoids misleading claims.
*Thank you for drawing attention to the fact that this isn't sufficiently clear. SOFIRpy itself does not depend on Dymola as a proprietary software. All functionalities of SOFIRpy can be used without using proprietary software, since the FMU export can be used with OpenModelica. SOFIRpy does however offer the functions to export FMUs with Dymola, as this is a common software for working with Modelica models. So the functions specifically written for Dymola within SOFIRpy do depend on proprietary software, even though the functionality is also available without dependence on proprietary software. We have clarified this in lines 187-191.*
4. Example Code Completeness
The PID controller example (lines 294–349) is incomplete, leaving essential methods unimplemented. Provide working implementations. These are short methods and completing them ensures users can understand the example.
*Thank you for raising this issue. Since the referenced example serves to give an overview of the entire workflow, we consider giving the full implementation of the PID class distracting to the reader. Instead, we have provided a link to the implementation of the PID controller in the SOFIRpy repository on GitHub.*
5. Installation Instructions
The installation section in the repository currently states only:
`pip install sofirpy`
Add in the repository Python version requirements, list dependencies, and note platform-specific considerations. A virtual environment setup guide would also improve onboarding.
*We have added a note linking to the requirement specification on the GitHub repository. As the dependencies are properly listed in the requirements file, no additional effort than pip installing is required for the user. We assume that most users are familiar with Python workflows including using virtual environments and will install from within one. Installation instructions for such a workflow are beyond the scope of this paper.*
6. Metadata Standardization
Lines 213–218 note that metadata is not standardized. Provide at least one default schema in an example or template following established standards (e.g., FAIR principles) while allowing customization. SOFIRpy claims RDM is its main strength providing one example schema is important.
*A minimum set of metadata as suggested are in fact already recorded. These mainly serve the purpose of recreating Run classes and so are used internally in the software itself. Further metadata, especially administrative metadata, is necessary for documenting the provenance of the data and automated discovery. These are not recorded by SOFIRpy by default, since the schemas, vocabularies or ontologies used are specific to the context in which SOFIRpy is used. We have clarified in lines 224-238 that a fixed minimum set of metadata are recorded with a focus on recreating simulation runs, but that further user-specific metadata would be necessary for ensuring full transparency. Since the recorded metadata are primarily intended for use within SOFIRpy itself, the use of standardized terms is not necessary. However, the further metadata for documentation and automated discovery would be used by other software and the used schemas, vocabularies and ontologies and would be context-specific. Here the use of standardized vocabularies and ontologies, e.g. metadata4ing, would be highly beneficial. However, this cannot be pre-determined by SOFIRpy. We have added a note in lines 485-487 stating that the creation of a metadataschema for describing SOFIRpy-created HDF5 files is a line of future development.*
7. Documentation and Validation
Add some README files for the examples, they are using specific versions of proprietary software.
*The user guide in the SOFIRpy documentation details the usage. The provided examples are implementations and should be comprehensible through the user guide. We have added a note in lines 419-422 of the descriptor highlighting that the examples for model export depend on third party software being installed on the system, proprietary software in the case of Dymola.*
Show whether SOFIRpy has been tested by colleagues or applied in case studies. The code has only one developer showing quantitative evidence builds credibility.
*Thank you for this reccomendation. We have included remarks on how SOFIRpy has been used at the Chair of Fluid Systems, TU Darmstadt in lines 476-479. Additionally, we have referenced two conference contributions in which SOFIRpy has been used after adapting it for use with real-world physical systems rather than Modelica models. One study presents an approach for RDM for bespoke experiments, the other is an experimental study on resilience in water distribution systems (cf. lines 493-495).*
8. Comparison with Other Tools
The paper states SOFIRpy’s advantage is Modelica focus and integrated RDM, while broader frameworks like Mosaik offer more features. Highlight SOFIRpy’s lightweight nature and ease of modification, which is valuable for researchers needing flexibility over features.
*We have included this point in lines 116-118 to highlight the benefits of SOFIRpy.*
9. Other Points
Avoid hard-coded paths for the exporters
*We have replaced hard-coded paths with a function prompting users to select their Dymola executable in the exporter examples for Dymola in the repository on GitHub.*
Address long-term maintainability, mention any commitment of use within your research group or institute.
*Starting from the project that provided the use-case that initially motivated the work, the issue of optimal and decentral control of fluid systems has been explored in several follow-up projects and ongoing parallel projects. SOFIRpy is proving useful for this ongoing work. The use-case for the extension to real-world systems serves as a starting point for further developing methods for RDM for test rigs. We have included these remarks in the descriptor in lines 498-502.*
Comment #216 Bernd Flemisch @ 2025-08-28 09:55
As the responsible topical editor, I would like to thank the two reviewers for their detailed and constructive feedback. After consideration of the comments, I advise the authors to revise the paper according to the suggestions provided in the reviews. After completion, the new version of the paper should be uploaded again and will be given again to the reviewers. Thank you.
Invited Review Comment #215 Hamza Oukili @ 2025-08-27 12:45
Overall Assessment
SOFIRpy is a Python tool for co-simulation of Functional Mock-up Units (FMUs) with integrated research data management (RDM). The software descriptor is generally well-written, clearly structured, and follows a standard format for a software paper. However, several revisions are recommended to improve clarity, accuracy, and completeness before publication.
1. Target Audience
The paper currently lists researchers, planners, and operators as potential users, but these groups have very different needs. Focus primarily on researchers, it is more realistic. The software doesn’t seem to focus on UI/UX.
2. Statement of Need
The current statement is generic and could apply to many tools. It should highlight the unique gaps SOFIRpy fills, mainly for Modelica.
Additionally, ensure consistency between Sections 1.1 and 1.2 regarding supported workflow steps, avoid implying that all five steps are fully covered Line 36 when only three are implemented.
3. Proprietary Dependencies
The paper claims SOFIRpy “does not rely on proprietary dependencies,” yet mentions tools like Dymola (proprietary) for exporters. This ensures transparency and avoids misleading claims.
4. Example Code Completeness
The PID controller example (lines 294–349) is incomplete, leaving essential methods unimplemented. Provide working implementations. These are short methods and completing them ensures users can understand the example.
5. Installation Instructions
The installation section in the repository currently states only:
pip install sofirpyAdd in the repository Python version requirements, list dependencies, and note platform-specific considerations. A virtual environment setup guide would also improve onboarding.
6. Metadata Standardization
Lines 213–218 note that metadata is not standardized. Provide at least one default schema in an example or template following established standards (e.g., FAIR principles) while allowing customization. SOFIRpy claims RDM is its main strength providing one example schema is important.
7. Documentation and Validation
Add some README files for the examples, they are using specific versions of proprietary software.
Show whether SOFIRpy has been tested by colleagues or applied in case studies. The code has only one developer showing quantitative evidence builds credibility.
8. Comparison with Other Tools
The paper states SOFIRpy’s advantage is Modelica focus and integrated RDM, while broader frameworks like Mosaik offer more features. Highlight SOFIRpy’s lightweight nature and ease of modification, which is valuable for researchers needing flexibility over features.
9. Other Points
Avoid hard-coded paths for the exporters
Address long-term maintainability, mention any commitment of use within your research group or institute.
Final Remark
With these revisions the paper will provide a clear, credible, and user-friendly description of SOFIRpy suitable for publication.
Invited Review Comment #213 Anonymous @ 2025-07-18 09:08
The Paper presents SOFIRpy, a tool for simulation of fluid systems along with there control algorithms, with the goal of optimizing this controller. Along with capabilities supporting this goal, SOFIRpy also includes some RDM reproducibility features.
The tool helps users to:
- export there model created using dedicated modelling software such as Modelica into to independent FMU format
- Co-Simulate the Modell with a Controller (which is the software to be optimized)
- Storing of the Model and simulation results as well as metadata in HDF5 formate
The paper is well written, and the topic fits the scope of the Journal.
However I have a few suggestions:
The FMI Standard, and what part of it are used within SOFIRpy should be discussed in more detail. I Example: Is it possible to couple system models with this approach, or only Controllers with Systems? How is time controlled within this coupling? (i. e. by using fixed integration step sizes)
Is there a way to connect the stored results in HDF5 to specific version of the controllers source code? One suggestion would be to store it together with the code, i.e. using MLFlow (originating from machine learning applications)
Meta data: Even given the goal of flexibility, a fixed minimum set of required Methadata would help the interoperability of this approach. (like date, subject, model version, controller version…)
For clarity 168 should include some hint to the goal of exporting form script (this is clear later, but points to the wrong direction)
448 reads Government of the “Länder”, I am not sure if this is translated correctly