search

openjournals / joss-reviews

Reviews for the Journal of Open Source Software
Creative Commons Zero v1.0 Universal
707 stars 37 forks source link

[REVIEW]: RodiCS: a finite element solver of Kirchhoff rods under fluid flow and more #2577

Closed whedon closed 3 years ago

whedon commented 4 years ago

Submitting author: @mou3adb (Mouad Boudina) Repository: https://github.com/lm2-poly/RodiCS Version: v1.0.0 Editor: @diehlpk Reviewer: @ilyasst, @chennachaos Archive: Pending

:warning: JOSS reduced service mode :warning:

Due to the challenges of the COVID-19 pandemic, JOSS is currently operating in a "reduced service mode". You can read more about what that means in our blog post.

Status

status

Status badge code:

HTML: <a href="https://joss.theoj.org/papers/69bad7d5d3939781ccd4198b7ec87745"><img src="https://joss.theoj.org/papers/69bad7d5d3939781ccd4198b7ec87745/status.svg"></a>
Markdown: [![status](https://joss.theoj.org/papers/69bad7d5d3939781ccd4198b7ec87745/status.svg)](https://joss.theoj.org/papers/69bad7d5d3939781ccd4198b7ec87745)

Reviewers and authors:

Please avoid lengthy details of difficulties in the review thread. Instead, please create a new issue in the target repository and link to those issues (especially acceptance-blockers) by leaving comments in the review thread below. (For completists: if the target issue tracker is also on GitHub, linking the review thread in the issue or vice versa will create corresponding breadcrumb trails in the link target.)

Reviewer instructions & questions

@ilyasst & @chennachaos, please carry out your review in this issue by updating the checklist below. If you cannot edit the checklist please:

  1. Make sure you're logged in to your GitHub account
  2. Be sure to accept the invite at this URL: https://github.com/openjournals/joss-reviews/invitations

The reviewer guidelines are available here: https://joss.readthedocs.io/en/latest/reviewer_guidelines.html. Any questions/concerns please let @diehlpk know.

✨ Please start on your review when you are able, and be sure to complete your review in the next six weeks, at the very latest ✨

Review checklist for @ilyasst

Conflict of interest

Code of Conduct

General checks

Functionality

Documentation

Software paper

Review checklist for @chennachaos

Conflict of interest

Code of Conduct

General checks

Functionality

Documentation

Software paper

whedon commented 4 years ago

Hello human, I'm @whedon, a robot that can help you with some common editorial tasks. @ilyasst, @chennachaos it looks like you're currently assigned to review this paper :tada:.

:warning: JOSS reduced service mode :warning:

Due to the challenges of the COVID-19 pandemic, JOSS is currently operating in a "reduced service mode". You can read more about what that means in our blog post.

:star: Important :star:

If you haven't already, you should seriously consider unsubscribing from GitHub notifications for this (https://github.com/openjournals/joss-reviews) repository. As a reviewer, you're probably currently watching this repository which means for GitHub's default behaviour you will receive notifications (emails) for all reviews 😿

To fix this do the following two things:

  1. Set yourself as 'Not watching' https://github.com/openjournals/joss-reviews:

watching

  1. You may also like to change your default settings for this watching repositories in your GitHub profile here: https://github.com/settings/notifications

notifications

For a list of things I can do to help you, just type:

@whedon commands

For example, to regenerate the paper pdf after making changes in the paper's md or bib files, type:

@whedon generate pdf
whedon commented 4 years ago 
Reference check summary:

OK DOIs

- 10.11588/ans.2015.100.20553 is OK
- 10.1145/2566630 is OK
- 10.1016/j.jfluidstructs.2003.12.004 is OK
- 10.1017/jfm.2017.910 is OK
- 10.1016/j.jfluidstructs.2015.12.009 is OK
- 10.1093/jxb/erz288 is OK
- 10.1146/annurev-fluid-122414-034606 is OK
- 10.1098/rstb.1998.0262 is OK
- 10.5281/zenodo.1287832 is OK
- 10.1016/j.jfluidstructs.2015.12.009 is OK
- 10.1016/j.jfluidstructs.2015.11.007 is OK
- 10.1146/annurev.fl.09.010177.002011 is OK
- 10.1017/S0022112009993673 is OK
- 10.1073/pnas.1409118111 is OK

MISSING DOIs

- https://doi.org/10.5860/choice.48-5112 may be missing for title: Elasticity and Geometry: From hair curls to the nonlinear response of shells

INVALID DOIs

- None
whedon commented 4 years ago

:point_right: Check article proof :page_facing_up: :point_left:

chennachaos commented 4 years ago

Hi @diehlpk, I have gone through the paper and the repository. I don't think that the library is matured enough to consider it for publication in the JOSS. I provide the following points to justify my decision and hope that they help the authors in improving the library.

1.) In essence, this library is a finite element analysis code for studying the response of a single elastic rod modelled with 2-noded elements. The coupling between the fluid and solid is modelled as an external force and van der Pol equation. It does not even model multiple rods and their interactions. The problem tackled here is too simple and the library is too small to be considered for another publication.

2.) The theory behind the library is not available and it is not yet peer-reviewed. It seems to be under review for publication in another journal.

3.) The library is less than two months old. The library does not follow the standard guidelines in organising the files. There is no distinction between the source code and test cases. All files in the scripts folder contain only 2247 lines of code.

4.) The library lacks dedicated documentation describing the various aspects of the code. The thesis linked to the library is not accessible; the link is not working. This is not an issue that contributed to my decision.

5.) The authors' statement "The traditional method to simulate the motion of elastic rods in finite elements is to solve the elasticity equation in three-dimensions" is not correct. There are well-established rod and beam elements for modelling such a class of problems. Adding external forces to such models in any reasonably established FE software is not difficult.

6.) The authors' argument for the maintenance of the code, or the lack of it, is weak, considering especially that the framework is based on the 2-noded finite element. I do not see any motivation for using FEniCS. I think that the use of FEniCS for this problem is overkill. Why not implement 1-d basis functions in the code itself?

7.) There is only one time integration scheme, the backward Euler scheme, and it is only first-order. There are numerous well-established second-order time schemes.

diehlpk commented 4 years ago

@chennachaos Thanks for your review.

diehlpk commented 4 years ago

@mou3adb I talked to the first reviewer (@ilyasst) and he will respond to the above review soon. I think in the current state, we can not accept the paper and the code as it is. Following the reviewers, I think a major revision of the paper is needed. I paused the review for now and like to ask you to address the comments of the reviewers or give a statement here in the issues, if you think that is not possible or disagree.

Let me know once you are done with the major revision and I will check, if all the points are resolved. After that I will start a new round of reviews.

mou3adb commented 4 years ago

Hi @chennachaos. Thank you for these comments. Here are our responses:

Comment 1.) In essence, this library is a finite element analysis code for studying the response of a single elastic rod modelled with 2-noded elements. The coupling between the fluid and solid is modelled as an external force and van der Pol equation. It does not even model multiple rods and their interactions. The problem tackled here is too simple and the library is too small to be considered for another publication.

Yes, RodiCS is a FEniCS-based solver that simulates the response of a single Kirchhoff rod using interval finite elements embedded in three-dimensional space. The wake-oscillator model is only one example of the ability of RodiCS to compute coupled dynamics, and other phenomenological or reduced-order models should be easily implemented following the framework we propose. Our code combines geometrical non-linearity, the semi-empirical and non-linear drag model, and the distributed wake-oscillators model, features that are of great interest for diverse applications in fluid-structure interaction and beyond. In addition, owing to its versatility, RodiCS is a verified and validated library that could have saved valuable time for many graduate students, among whom those cited below, that wrote ad hoc codes in their research projects from zero. To strengthen the case for the motivation of the work in the paper, we added the following passage in the section `Summary':

While numerous researchers (Buchak, Eloy, & Reis, 2010; Goldberg &O’Reilly, 2020; Gosselin, de Langre, & Machado-Almeida, 2010; Hassani, Mureithi, & Gosselin,2016; T. Leclercq & de Langre, 2018; Tristan Leclercq & de Langre, 2018; Leclercq & deLangre, 2016; Lei & Nepf, 2019; Luhar & Nepf, 2016; Violette, de Langre, & Szydlowski,2007) spend valuable time and effort in writing ad hoc codes with limited verification and validation, RodiCS comes as a versatile and practical open source library that scientific projectscan benefit from and build upon.

In all these cited papers, graduate students coded ad hoc software with limited capabilities, benefiting from limited verification and validation. By building upon an open-source code which can be further developed by many researchers, deeper can be achieved.

Concerning the multiple rod interactions, the solution of a many-rod problem or an arborescent structure all coupled mechanically is directly amenable with the code. In terms of coupling via the flow, this is not possible with the phenomenological wake-oscillator model that is implemented and is beyond the scope of the software at the moment, although it is an interesting research topic.

Comment 2.) The theory behind the library is not available and it is not yet peer-reviewed. It seems to be under review for publication in another journal.

The derivation of equations, numerical formulation, code verification and validation, as well as some simulation cases, are described in chapter 7 of my thesis, which I joined a copy in the repository. As for the paper mentioned, it is actually an example of the code usage in an academic study, as recommended in the review criteria, in ‘The JOSS paper’ section.

Comment 3.) The library is less than two months old. The library does not follow the standard guidelines in organising the files. There is no distinction between the source code and test cases. All files in the scripts folder contain only 2247 lines of code.

The online repository is less than two months old, yet the real starting time of this project is older. I began to work on the project in my own directory in my personal computer, as we did not think about making a publishable library at that time. We are not aware of publication criteria regarding the repository age.

Also, we are not aware of any file organisation standard prescribed in the JOSS guidelines.

Regarding test functions, we added test files with names starting with the prefix test_, followed by the type of simulation, either _static_ or _dynamic_, then the simulation case. Each of these files contains a list of input parameters that the user may tune. To make it even clearer, we included in the repository description a section explaining how to run the tests.

The number of lines of code (LOC) respects the length requirements of JOSS mentioned in the ‘Substantial scholarly efforts’ section. RodiCS builds upon FEniCS to achieve much of the calculation capabilities. It makes efficient uses of pre-established packages and codes.

Comment 4.) The library lacks dedicated documentation describing the various aspects of the code. The thesis linked to the library is not accessible; the link is not working. This is not an issue that contributed to my decision.

We acknowledge this remark, and understand that this was not an issue for the decision following this review. As I mentioned in the response to Comment 2.), I joined a copy of my MSc thesis to the online repository. The theory supporting the code is dedicated in chapter 7.

Comment 5.) The authors' statement "The traditional method to simulate the motion of elastic rods in finite elements is to solve the elasticity equation in three-dimensions" is not correct. There are well-established rod and beam elements for modelling such a class of problems. Adding external forces to such models in any reasonably established FE software is not difficult.

This is a good point. We replaced "in finite elements" by "in FEniCS" to precise that it is the traditional method used in this platform. To the extend we looked into, we have not found any FEniCS code simulating a transient problem using one-dimensional elements. Broadly, open source finite element solvers rarely use 1D Kirchhoff rod elements embedded in a 3D space. Upon this latter affirmation, we emphasised the importance of RodiCS by adding the following sentence in the first paragraph of the section `Statement of Need':

Therefore, RodiCS fills a need in open source finite element codes for a way to solve the one-dimensional Kirchhoff rod equation embedded in a three-dimensional space.

We would like to add that it is the difficulty in some commercial software to implement customised loads, especially non-linear, space and time dependent loads, that pushed us to code our own library. For months, we tried different approaches with ANSYS and Abaqus, went over the provided functionalities, but have not found a proper way to include the semi-empirical non-linear drag model for a beam under a constant flow speed, a very basic FSI problem, let alone the coupled wake-oscillator model. With RodiCS, this difficulty is wiped out, and even non-programmer users can simulate time and space dependent, coupled rod dynamics fluently and straightforwardly.

Comment 6.) The authors' argument for the maintenance of the code, or the lack of it, is weak, considering especially that the framework is based on the 2-noded finite element. I do not see any motivation for using FEniCS. I think that the use of FEniCS for this problem is overkill. Why not implement 1-d basis functions in the code itself?

The argument is one of ad hoc coding versus one made to be part of a bigger environment. Open source codes that can achieve some of the capabilities in RodiCS do exist. For example, one such code we tried functioned only on a precise distribution of Linux, making use of 5 version specific libraries, which all had to be properly linked. The code, which was less than 5 years old, had instructions explicitly mentioning that it was not maintained and that assistance was not available for installing or running it. In this sense, we believe that a code based on Python and FEniCS, an open source FEM with an active community, is an important advantage for RodiCS. The use of FEniCS imposes a standard in the definition of meshes, making possible mesh generation with external meshing software, or combination of the elements in RodiCS with other types of finite elements. This modular approach is definitely a feature. We stressed this point in the paper by replacing the second part of the second paragraph of `Statement of Need' with the following:

These drawbacks were incentives for the authors of the present paper to think of writing their own code based on the FEniCS project, an open source finite element solver with an active community, continuously developed, and cross-platform; all significant advantages. Also as an essential modular feature, FEniCS imposes a standard in the mesh definition, making possible either the mesh generation with external meshing software, or the combination of elements in RodiCS with other types of finite elements. Finally, written in Python, RodiCS is inclusive and accessible for users of all programming levels.

Comment 7.) There is only one time integration scheme, the backward Euler scheme, and it is only first-order. There are numerous well-established second-order time schemes.

At this point, first order time integration worked for the purpose we had and the precision we desired. Implementing other time integration schemes is on the feature development list. We clarified more this proposition in the ‘Contribution’ section of our repository description.

Finally, I would like to mention some minor changes we added in the paper:

mou3adb commented 4 years ago

@whedon generate pdf

whedon commented 4 years ago

:point_right: Check article proof :page_facing_up: :point_left:

diehlpk commented 4 years ago

@chennachaos and @ilyasst Would you mind to check the author's response?

chennachaos commented 4 years ago

Hi @mou3adb. Thank you for your response! Your MSc thesis is great; however, your arguments are not convincing. I do not recommend this library in its current form for publication in JOSS.

The primary issue in recommending this library for publication in JOSS is the lack of content. There is not much one can do with this library. The type of problems that can be readily solved using this library is very limited. In fact, it is limited to a problem with a single rod with prescribed force and coupled to another discrete oscillator model. This code is not for direct numerical simulations of the interaction of thin rods with fluid flow. Considering the dimensionality of the problem, this, in its current form, is not such a challenging problem that a library dedicated to it deserves a publication in JOSS.

A thorough look at your thesis, and the concerned references therein, regarding the problem of vortex-induced vibrations, reveals that there is no quantitative comparison of numerical results for the dynamic case. How accurate is the lift-force model for simulating complex models such as non-uniform flows, multi-directional flows, geometries with multiple bifurcations such as the one shown in Figure 3.2. in your thesis? These kinds of questions concerning the theory should be answered before considering the library for publication. Extension of this framework to other complex problems requires a significant effort, in which case, my question is, why should the authors of this library get the credit when others need to add all the features/models they want to simulate? Extensions should only constitute a fraction of the work required to develop the library.

I sympathise with you regarding the lack of maintenance of research codes. However, your arguments on the use of FEniCS are not particularly convincing. I see no motivation for basing this code on FEniCS or any other FE core library for that matter. By relying on FEniCS, you are imposing unnecessary requirements on the user to install that library, considering especially that all that is needed for this problem is the basic 2-noded finite elements which can be hand-coded into the library itself. I don't see what other features of FEniCS you can use for the extension of this particular code. However, the book-keeping and maintenance aspects of the library are secondary here.

Last but not the least, have a look at other libraries published in JOSS to get an idea of (i) the structure of source code, (ii) documentation and (iii) examples and test cases.

diehlpk commented 4 years ago

Thanks @chennachaos.

diehlpk commented 4 years ago

@ilyasst Do you like to add something?

diehlpk commented 4 years ago

There is not much one can do with this library. The type of problems that can be readily solved using this library is very limited. In fact, it is limited to a problem with a single rod with prescribed force and coupled to another discrete oscillator model. This code is not for direct numerical simulations of the interaction of thin rods with fluid flow. Considering the dimensionality of the problem, this, in its current form, is not such a challenging problem that a library dedicated to it deserves a publication in JOSS.

Hey, @mou3adb. I think this quote from @chennachaos is my major concern. To back up my decision, I like to quote JOSS's Scope & submission requirements


JOSS submissions must:

1.  Be open source (i.e., have an OSI-approved license).
1. Have an obvious research application.
1.  Be feature-complete (no half-baked solutions) and be designed for maintainable extension (not one-off modifications).
1. Minor 'utility' packages, including 'thin' API clients, and single-function packages are not acceptable.

Your submission clearly addressed the first two points. However, I do not see how the other two points are addressed.

1. Minor 'utility' packages, including 'thin' API clients, and single-function packages are not acceptable.

I think your package in the current state is a minor 'utility' packages and it is more a single-function, meaning that one can only solve one problem (single rod) and can just change a limited set of parameters. I do not think that one could use your code in the current state without major modifications to solve any other problem than your single rod example problem. Which relates to the third point in the list above. I do not think that your code in the current state is feature-complete and it is more a showcase/example for your research. However, for JOSS we like to see code, which can be easily used by others to solve research problems. Again, I agree with @chennachaos one would have to do major modification to the code to use it for direct numerical simulations of the interaction of thin rods with fluid flow.

I would like to reject this paper in its current form due to a minor 'utility' package. However, I like to encourage you make the code feature-complete and add more functionality, e.g. make the simulation more configurable and add multi rod support. We look forward to your future submissions to JOSS.

mou3adb commented 4 years ago

Hi @diehlpk and @chennachaos. Thank you for these replies. Please consider the responses below, we clarified the points that we think raised confusion.

For the claim that There is not much one can do with this library, we say first that RodiCS is not a 'single-function package' nor a 'thin API client.' RodiCS can reproduce the modelling results of the following papers (Buchak, Eloy, & Reis, 2010; Goldberg & O’Reilly,2020; Gosselin, de Langre, & Machado-Almeida, 2010; Hassani, Mureithi, & Gosselin, 2016;T. Leclercq & de Langre, 2018; Tristan Leclercq & de Langre, 2018; Leclercq & de Langre,2016; Lei & Nepf, 2019; Luhar & Nepf, 2016; Mukundan, Modarres-Sadeghi, Dahl, Hover, &Triantafyllou, 2009; Violette, de Langre, & Szydlowski, 2007). This list is far from exhaustive. These papers deal with geometrically non-linear static deformations of structures under flow, dynamics of slender structures subject to wave action, and vortex-induced vibrations. RodiCS has not limited applications. It not only goes beyond reproducing each of these effects, it allows combining all of them together. Also in the 'Summary' section we pointed the diversity of problems and exciting topics which RodiCS should contribute to. Ignoring the importance of the single rod problem means ignoring a whole legacy in FSI; it has many relevant applications in nature and industry alike (pipes, risers, antennas, terrestrial and aquatic vegetation, microbial locomotion, hair models, whiskers, to name but a few). Therefore we cannot really claim that RodiCS 'has minor utility.' We also said in the previous response that the many-rod problem is amenable with the code.

Regarding the following quote This code is not for direct numerical simulations of the interaction of thin rods with fluid flow, all the purpose of RodiCS is to avoid direct numerical simulations. We do not see any requirement in JOSS to include DNS in mechanical codes to be published.

Considering the dimensionality of the problem, this, in its current form, is not such a challenging problem that a library dedicated to it deserves a publication in JOSS. Writing an open source code for 1D Kirchhoff rods embedded in 3D space is challenging in FEniCS. No such example is found in the web. This is an essential argument why we want to publish the paper; we do not want another endless list of authors spend months hand-coding ad hoc scripts with rudimentary and basic functions. Instead, researchers and graduate students can use RodiCS and save more time. The guidelines of the JOSS state clearly that any paper making addressing research better: simpler, easier, faster is a substantial scholarly effort recommended for publishing. Moreover, always according to the guidelines, RodiCS has already been cited in an academic study which we mentioned in the section 'Complex Dynamics', and we expect it likely to be cited by other researchers in the future.

There is no quantitative comparison of numerical results for the dynamic case. [...] These kinds of questions concerning the theory should be answered before considering the library for publication. We did not develop any theory here. We implemented different theories in a single code. We do not believe it is necessary to validate each of these theories. In terms of quantitative numerical results, RodiCS successfully reproduces the dynamics of a wave-swept thin plate observed in the experiments of Leclercq and de Langre (2018), as shown in Figure 7.6 of my thesis. The paper of the wake-oscillator model earns 600 citations, and cited several times every single year since its publication, which is impressive, and absolutely not 'of minor utility.' We find it disappointing not to have any open source code implementing such an important model applied in series of experimental and numerical studies. Any doubts on or improvements of the model itself are worth discussing with the corresponding author of that paper.

Extension of this framework to other complex problems requires a significant effort, in which case, my question is, why should the authors of this library get the credit when others need to add all the features/models they want to simulate? Extensions should only constitute a fraction of the work required to develop the library. Extension to other features does not require a significant effort. We did the significant effort already. Again, we do not want future researchers and graduate students to repeat this significant effort. They only need to enter the force expressions as their figure in their drafts. We already mentioned this advantage in the 'Description' section.

I see no motivation for basing this code on FEniCS or any other FE core library for that matter. By relying on FEniCS, you are imposing unnecessary requirements on the user to install that library, considering especially that all that is needed for this problem is the basic 2-noded finite elements which can be hand-coded into the library itself. I don't see what other features of FEniCS you can use for the extension of this particular code. Hand-coding existing modules is time-killing and counterproductive; building upon them is enriching. Here we simply use the same justification as Bergersen, Slyngstad, Gjertsen, Souche, and Valen-Sendstad (2020) who published their code in JOSS recently: basing the code on FEniCS allowed us to write it "in only a [couple of hundred] lines of high-level Python code, in contrast to tens of thousands of lines of low-level C++ code. This provides full transparency and a unique opportunity for researchers and educators to modify and experiment with the code, while still providing out of the box entry-level high-performance computing capabilities. Furthermore, because of the close resemblance between mathematics and code in FEniCS, users can make additions or modifications with ease." This latter phrase was put under light in our paper by indicating explicitly the Unified Form Language (UFL) as a simplifying and powerful asset of FEniCS. With UFL, the range of mechanical problems RodiCS can tackle is easily extended. Finally, installing FEniCS is straightforward, fortunately we do not impose anything on users.

However, the book-keeping and maintenance aspects of the library are secondary here. Not sure about that. Maintenance is a vital component commercial software and open source codes rely on. The DER code is an interesting code, but is now let down and forgotten just for being unmaintained, which is a pity. In contrast, FEniCS has a large and active community, and users can report any relevant issue in the forum and expect an answer.

A minor change to the paper: replaced 'In FEniCS, such a code...' instead of 'Such as code...' in the Statement of Need section.

ilyasst commented 4 years ago

I am sorry about the delay (classes 😅). I have filled my review section. Thank you for the previous review and responses @chennachaos and @mou3adb. I believe that in this current state, this code does not seem ready for publication in JOSS. The main comment I have is regarding the current way the code is written (structure and format). The code presented here is a collection of scripts that contain functions that cannot really be re-used to solve different kinds of problems, they can only be used exactly "the way they are written". I do not think that in this state this code fits the definition of a library, it could however be a sound basis for future work that would refactor it and extend it to make a library (and package) out of it. Please understand that my comments will mainly address the code. Although I think that your work is a relevant contribution (thesis and publication), that is however independent from the evaluation of the python code written to support that work.

I am not certain that this code fits the JOSS guidelines in its current format. The repository presented here contains several folders among which two are of interest, scripts and xml_files. The scripts folder contains a collection of scripts. The scripts contain several hard-coded values that do not have comments or documentation that explains their role (please see my comment about docstrings in the following section). Are the files that start with test actually examples ? I do not believe that those are "tests" (I was expecting something like this https://docs.python.org/3/library/unittest.html), however they look like examples.

As a user, I have no idea how to solve my own problem, meaning how to re-use this collection of scripts to solve one of my own problems. It should be possible to easily import and re-use a library to solve a user-specific problem. I have spent quite some time looking through the proposed code and documentation and have no idea how to do so. Should I use the tests to learn how to do so ?

This code feels like an ongoing work that still requires some refactoring and improvement. The functions sometimes feels like wrappers around scripts that are used as compartments or sections in a document more than ways to reduce repetition and make the code re-usable. The code still contains "comment-separations" :

#####################################
#===============================

I also notice something I could not really understand about docstrings: for example, in the dynamic.py file there is a quite good docstring for the run_dynamic function; howeve, in the static.py file there is no docstring at all. By comparing the files dynamic.py and static.py it appears that the two files contain several exact same sections, they even contain the exact same fenics functions (such as root or tip). Although functions are used in this code, all these lines are repeated. I believe that the author could use functions here, and in several other places, to avoid repetition. In addition, those function could be used by several modules. The structure of the code also feels like a work in progress, the whole code should be reviewed while trying to consider more problems, make it easy for the user to provide inputs, and focus on avoiding repetitions and building "more general" functions. The code should not be presented as a loose collection of scripts.

Points that I would recommend the authors should address:

The last point I would like to add is that, if I actually understood how this collection of scripts actually works, meaning that the user should write a file similar to one of the test files, then this collection of scripts should make it easy for the user to write such a script. Currently I do not think that it is the case.

Finally, in the paper the following point is put forward to justify this work Because the DER code is written in C++ and has an intricate file structure, only programmer users are able to modify the source code, excluding thus users new in coding or having basic knowledge in programming. Although I agree with the general idea that python might have a "nicer" syntax than C++, that does not mean that re-writing a code in python automatically makes it more accessible. That is only true if the code is actually written following several guidelines (the python standard documentation, pep-8, ...). Currently, I do not think that this code is accessible, it is however a good first step to build such a library.

Disclosure: I was recently a postdoc in the same lab as @mou3adb (although not in the same field) and I have collaborated with his supervisor on a publication in the last two years. However, I was not involved in this work at all. I have discussed this with @diehlpk.

diehlpk commented 4 years ago

@mou3adb having the second review, I really think that the code is not in the shape to be considered for a publication in JOSS. Note that a JOSS publication is about the source code, in your case the Python code. I do believe that the research you have done is good and interesting, however, you got credit for that in your master thesis and the publication under review. I recommend to not accept the code in its current form. However, I do think, if you wait for some time, improve the code structure, add documentation, do not have hard-coded values, and make it more clear how users should use your code, I think you should resubmit to JOSS.

frederickgosselin commented 4 years ago

I would like to thank the reviewers and editor for their time and their feedback.

diehlpk commented 3 years ago

@mou3adb and @frederickgosselin when do you plan to resubmit the paper? If it is not within the next three months, I would prefer to close this submission and invite you to resubmit once you have improved the paper. I will be happy to edit the paper again.

diehlpk commented 3 years ago

@mou3adb I will close the review next week, since I have not heard back from you since January.

frederickgosselin commented 3 years ago

Dear Patrick, Yes you can close the review. Mouad's paper was published in the Journal of Fluid Mechanics. The paper cite a zenodo DOI for the code https://zenodo.org/record/4023287#.YIxHb7VKiUk Hopefully, I get the manpower in the future to build on this code and perhaps submit it again to JOSS in the future. Thanks for your time,

Frédérick Gosselin Professeur Agrégé, Département de Génie Mécanique, Polytechnique Montréal, Canada Laboratoire de Mécanique Multi-Échelles (LM2) http://www.fgosselin.com

On Fri, 30 Apr 2021 at 12:24, Patrick Diehl @.***> wrote:

@mou3adb https://github.com/mou3adb I will close the review next week, since I have not heard back from you since January.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/openjournals/joss-reviews/issues/2577#issuecomment-830209290, or unsubscribe https://github.com/notifications/unsubscribe-auth/AKYVZYCEFILZCGNGP5ZS4T3TLLKSDANCNFSM4QARJNVA .

diehlpk commented 3 years ago

@whedon commands

whedon commented 3 years ago

Here are some things you can ask me to do:

# List all of Whedon's capabilities
@whedon commands

# Assign a GitHub user as the sole reviewer of this submission
@whedon assign @username as reviewer

# Add a GitHub user to the reviewers of this submission
@whedon add @username as reviewer

# Re-invite a reviewer (if they can't update checklists)
@whedon re-invite @username as reviewer

# Remove a GitHub user from the reviewers of this submission
@whedon remove @username as reviewer

# List of editor GitHub usernames
@whedon list editors

# List of reviewers together with programming language preferences and domain expertise
@whedon list reviewers

# Change editorial assignment
@whedon assign @username as editor

# Set the software archive DOI at the top of the issue e.g.
@whedon set 10.0000/zenodo.00000 as archive

# Set the software version at the top of the issue e.g.
@whedon set v1.0.1 as version

# Open the review issue
@whedon start review

EDITORIAL TASKS

# All commands can be run on a non-default branch, to do this pass a custom 
# branch name by following the command with `from branch custom-branch-name`.
# For example:

# Compile the paper
@whedon generate pdf

# Compile the paper from alternative branch
@whedon generate pdf from branch custom-branch-name

# Remind an author or reviewer to return to a review after a
# certain period of time (supported units days and weeks)
@whedon remind @reviewer in 2 weeks

# Ask Whedon to do a dry run of accepting the paper and depositing with Crossref
@whedon accept

# Ask Whedon to check the references for missing DOIs
@whedon check references

# Ask Whedon to check repository statistics for the submitted software
@whedon check repository

EiC TASKS

# Invite an editor to edit a submission (sending them an email)
@whedon invite @editor as editor

# Reject a paper
@whedon reject

# Withdraw a paper
@whedon withdraw

# Ask Whedon to actually accept the paper and deposit with Crossref
@whedon accept deposit=true
diehlpk commented 3 years ago

@whedon withdraw

whedon commented 3 years ago

I'm sorry @diehlpk, I'm afraid I can't do that. That's something only editor-in-chiefs are allowed to do.

diehlpk commented 3 years ago

@openjournals/joss-eics can someone please withdraw the paper?

diehlpk commented 3 years ago

Dear Patrick, Yes you can close the review. Mouad's paper was published in the Journal of Fluid Mechanics. The paper cite a zenodo DOI for the code https://zenodo.org/record/4023287#.YIxHb7VKiUk Hopefully, I get the manpower in the future to build on this code and perhaps submit it again to JOSS in the future. Thanks for your time, Frédérick Gosselin Professeur Agrégé, Département de Génie Mécanique, Polytechnique Montréal, Canada Laboratoire de Mécanique Multi-Échelles (LM2) http://www.fgosselin.com Cellulaire : (514) 713-6245 Bureau : (514) 340-4711 ext. 3747 … On Fri, 30 Apr 2021 at 12:24, Patrick Diehl @.***> wrote: @mou3adb https://github.com/mou3adb I will close the review next week, since I have not heard back from you since January. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#2577 (comment)>, or unsubscribe https://github.com/notifications/unsubscribe-auth/AKYVZYCEFILZCGNGP5ZS4T3TLLKSDANCNFSM4QARJNVA .

Sure, thing. I look forward to the updated code base. Please feel free to suggest me as the editor for any future submisison.

kthyng commented 3 years ago

@whedon withdraw

whedon commented 3 years ago

Paper withdrawn.