Closed whedon closed 3 years ago
Hello human, I'm @whedon, a robot that can help you with some common editorial tasks. @IgorBaratta, @chennachaos, @finsberg 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:
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
Reference check summary (note 'MISSING' DOIs are suggestions that need verification):
OK DOIs
- 10.1002/nme.2579 is OK
- 10.1016/j.tplants.2010.04.002 is OK
- 10.1016/j.physa.2017.02.014 is OK
- 10.1126/science.251.4994.650 is OK
- 10.1016/j.cub.2020.07.076 is OK
- 10.5281/zenodo.4090832 is OK
MISSING DOIs
- None
INVALID DOIs
- None
:point_right::page_facing_up: Download article proof :page_facing_up: View article proof on GitHub :page_facing_up: :point_left:
@Kevin-Mattheus-Moerman @oalii I am unable to create new issues in the git repo - seems like I need to request an external account from an Inria member, or am I doing something wrong? Would it be possible to mirror this repo on gitlab.com ?
@finsberg, ok, I need to discuss this within my team. To be honest this is a first time for us and I don't know what is best, to make external account for the reviewers or to mirror the repo. I am forwarding the issue to the other lab members; but since tomorrow is a banking holiday here don't expect an answer before Thursday at most... Sorry about that.
@finsberg, ok, I need to discuss this within my team. To be honest this is a first time for us and I don't know what is best, to make external account for the reviewers or to mirror the repo. I am forwarding the issue to the other lab members; but since tomorrow is a banking holiday here don't expect an answer before Thursday at most... Sorry about that.
I don't know if we need to mirror everything or just make an empty repo dedicated for JOSS issues. @Kevin-Mattheus-Moerman do you have any experience with this? I guess another option would be to do all the issues in this review thread (although it is stated above that we shouldn't do that).
The project is supposed to be public, but maybe we need to uncheck the "Allow users to request access" square ?... So that you won't need to request access prior to opening issues ?...
@oalii @finsberg the software repository needs to be fully open so that anybody can open an issue. This is a requirement for JOSS, see our submission requirements which state:
In addition, the software associated with your submission must:
- Be stored in a repository that can be cloned without registration.
- Be stored in a repository that is browsable online without registration.
- Have an issue tracker that is readable without registration.
- Permit individuals to create issues/file tickets against your repository.
Rather than mirroring to GitHub it would be best if you can adjust your repository settings to allow for this :point_up:
Can you make your current repository conform to these requirements?
Hello @Kevin-Mattheus-Moerman , I made an issue ticket on the Helpdesk of my institute yesterday to see how we can work this out. I will let you know. Sorry for this problem.
So, the Inria IT people tell me that indeed to create issues, one needs to be invited as a "guest". To do so, all I need is emails for @finsberg , @IgorBaratta , @chennachaos and @Kevin-Mattheus-Moerman to invite you. Would this solution be acceptable in regards of the JOSS submission policy ?
So, the Inria IT people tell me that indeed to create issues, one needs to be invited as a "guest". To do so, all I need is emails for @finsberg , @IgorBaratta , @chennachaos and @Kevin-Mattheus-Moerman to invite you. Would this solution be acceptable in regards of the JOSS submission policy ?
@oalii sorry this is not acceptable since that is a form of registration. What is needed is the ability to do cloning, browsing, viewing current issues, posting new issues, all without any form of registration/login.
Please ensure settings are altered to allow this.
@Kevin-Mattheus-Moerman ,
I'm sorry but I'm sure to understand, how can someone open an issue without registration first ? As far as I understand gitlab and/or GitHub (but I am not at all a savvy users of these tools...) you always need an account to raise an issue no ? besides, the guidelines you quote:
In addition, the software associated with your submission must:
- Be stored in a repository that can be cloned without registration.
- Be stored in a repository that is browsable online without registration.
- Have an issue tracker that is readable without registration.
- Permit individuals to create issues/file tickets against your repository.
Do not explicitly say that people should be able to create issues without registration, no ? Again, sorry for these difficulties.
@oalii thanks for these questions. To clarify, yes GitHub and GitLab (the general public platform) require a GitHub or GitLab account for sure. However once logged on you can start issues on any public GitHub and GitLab repository. If this was the case for your project then this is fine. Also anybody can easily, and virtually instantly, create a GitHub/GitLab account. However for your project it requires "invitation" to be a "guest", and the login page says;
External users need to request an external account from an Inria member. When the account is created, the external users can login in the Standard tab.
So this added threshold of the invitation
or the request an external account
is what we deem not acceptable. Posting issues without the need to request and account should be possible (it looks like we may need to clarify our wording in our guidelines in that respect).
@Kevin-Mattheus-Moerman ,
Thanks for the clarification, your point is completely understandable and this limitation of the Inria.gitlab is a pity. To solve this, we have set a mirroring repository within the "regular" gitlab platform : https://gitlab.com/oali/bvpy. Is this solution ok on your end ?
If so, can we simply ask Whedon to change the repository related to our submission ?
@oalii yes thank you this is acceptable. We cannot hold you to it but we do hope you maintain this mirrored repository.
I'll update the repository for this issue now too.
@whedon generate pdf
:point_right::page_facing_up: Download article proof :page_facing_up: View article proof on GitHub :page_facing_up: :point_left:
@IgorBaratta, @chennachaos, @finsberg thanks again for your help reviewing this work. We have just updated the repository for this software which is now: https://gitlab.com/oali/bvpy
You should have access to create issues on that repository now too. Thanks, let me know if you have questions.
@Kevin-Mattheus-Moerman ,
I am glad we worked this out. We will maintain the repo, no problem. FYI, I informed the Inria IT service of this problem. Turns out it is a burning debate within the institute right now. Hopefully the institute policy will be shifted toward more flexibility in the future 🤞🏿
@IgorBaratta, @chennachaos, have you been able to start reviewing this work? Note :point_up: we updated the repository. Thanks for your help!
@IgorBaratta, @chennachaos, have you been able to start reviewing this work? Note we updated the repository. Thanks for your help!
Yes, I've already started. Soon I will tick more boxes in the checklist.
Dear reviewers and editor,
just to inform you: we have created a joss-review
branch on the repository where we are going to perform all the upgrades requested. You should therefore switch to this branch to follow our updates.
thanks for your inputs.
@whedon generate pdf
:point_right::page_facing_up: Download article proof :page_facing_up: View article proof on GitHub :page_facing_up: :point_left:
Thanks for the updates @Kevin-Mattheus-Moerman and @oalii. I have not started the review yet. I will start in the next week.
@chennachaos okay thanks for the update
Hi @Kevin-Mattheus-Moerman, I have gone through the paper, repository and documentation of the submission. After careful consideration, I do not recommend the BVPy library for publication in JOSS in its current form.
I do not believe that there is any novelty in this particular library over what is already available in FEniCS. The authors claim, "Its purpose is to enable users to quickly and efficiently estimate the behaviour of a wide variety of fields (scalars, vectors, tensors) on biologically relevant structures, inspired by biophysical and biochemical processes (morphogene patterning, active matter mechanics, active transports". Correct modelling of these phenomena requires multiphysics and nonlinear capabilities as well as 3D continuum formulations for bulky materials. However, the example problems provided in the library model single physics only. Besides, the examples (Poisson equation, reaction-diffusion equation and linear elasticity equations) are too simple and well-established. With the exception of Turing reaction-diffusion system, all of the examples covered are part of an introductory course on FEM. FEniCS library already contains a rich set of examples, including those that are discussed in BVPy. FEniCS also provides a Python interface.
If the PDEs discussed in the documentation part of the library are the only equations that are of interest to the community, then FEniCS is more than sufficient enough. Therefore, I do not see any particular advantage of BVPy over FEniCS. To me, the library looks like it is in the early stages of development. The fact that the authors have cited only a single paper written by themselves justifies this argument and also that the theoretical framework needs to be established thoroughly before it can be published as a library.
Based on the above points, I do not recommend BVPy for publication in JOSS in its current form.
Hi @Kevin-Mattheus-Moerman
I need to disagree with @chennachaos. It is true that FEniCS provides a framework for solving PDEs using the finite element method, but I think BVPy
add a lot of extra functionality if you want to study boundary value problems in particular.
Furthermore, I think that BVPy
is a premium example on how you should structure an open source project. They have very good documentation and test suite, and the code is in general very well written and structured.
I am myself a FEniCS user and I can definitely see this packages being used by developers in FEniCS community that works with BV problems. I have already recommended BVPy
to a few people already.
In terms of novelty, I think there are a lot of novelty in the way they have integrated meshing with gmsh
as well as how they have implemented the visualisation. I also think that having fined tuned the solvers for these particular equations are very useful for users that wants to solve BV-problems.
When @oalii has added a paragraph about "State of the field" I would strongly recommend this for publication in JOSS.
@whedon generate pdf
:point_right::page_facing_up: Download article proof :page_facing_up: View article proof on GitHub :page_facing_up: :point_left:
@whedon generate pdf from branch joss-review
Attempting PDF compilation from custom branch joss-review. Reticulating splines etc...
:point_right::page_facing_up: Download article proof :page_facing_up: View article proof on GitHub :page_facing_up: :point_left:
Dear editor and reviewers,
First, thank you to @chennachaos and @finsberg for their valuable opinions on our work.
Let me comment on some remarks raised by @chennachaos:
I do not believe that there is any novelty in this particular library over what is already available in FEniCS.
In terms of core components, we completely agree with @chennachaos. This library is not to an add-on to FEniCS providing new solvers or cutting-edge FE types. As we explained within our statement of need, our two main objectives are to: (i) "Provide a high-level API to soften the learning curve of FEMs[..]" and (ii) "Enable users experienced in FEM [...] to develop and fully customize de novo templates [...]".
Rougthly speaking, "we want to widen the user spectrum of FEM-based simulations toward non-specialists". In our highly interdisciplinary scientific domain this is dire necessity. To that end, we built an API that can spare technical aspects of FEM to the unexperienced user and keep them available to the experienced one. For instance, the code example provided within the manuscript (should) demonstrate that within our framework, one can parametrize a BVP and estimate its solution without knowing anything about FEM.
This particular strategy is directly inspired by our day-to-day workflow: Modeling projects are usually conducted by two types of modelers: "explorers" and "builders". While the latter obviously need to be trained in the "art of FEM", the former might not. Having a tool that both can use and upon which they can exchange is crucial. While FEniCS is a great tool to build detailed FEM-simulations, it remains out of reach for many scientists who want to explore models but are untrained in Finite Element Methods.
To answer this need, we propose a light-weight library architecture mapping the theoretical framework of BVPs with the corresponding implementations in FEniCS (combined with useful features from Gmsh and Meshio to handle more properly domains and their mesh implementations). The corner stone of BVPy is the notion of "template" (of problem, vform and domain, e.g. vform.poisson.PoissonForm
). We incorporated some examples of such templates within the sub-modules of the library; for instance vform.elasticity
gathers classes dedicated to the implementation of specific elastic problems (LinearElasticForm
, HyperElasticForm
...). But the very purpose of BVPy is to be evolutive and enable "builders" to derive their own templates from the abstract classes, dedicated to their own problems of interest. In turn, "explorers" can instanciate and run the corresponding simulations.
We believe this workflow, our implementation of it and its full inter-operability with FEniCS, Gmsh and Meshio constitute the novelty of our work.
The authors claim, "Its purpose is to enable users to quickly and efficiently estimate the behaviour of a wide variety of fields (scalars, vectors, tensors) on biologically relevant structures, inspired by biophysical and biochemical processes (morphogene patterning, active matter mechanics, active transports". Correct modelling of these phenomena requires multiphysics and nonlinear capabilities as well as 3D continuum formulations for bulky materials.
However, the example problems provided in the library model single physics only. Besides, the examples (Poisson equation, reaction-diffusion equation and linear elasticity equations) are too simple and well-established. [...]
With the exception of Turing reaction-diffusion system, all of the examples covered are part of an introductory course on FEM.
That is indeed true. Our goal is not to provide users with highly technical models but rather propose them building blocks so they can build their own complex models. We provide a collection of"simple and well-established" equations so users can start to assess the library on easily understandable problems. Presenting such "introductory" examples should make the benefits of our library clearer than directly addressing subtle and cutting-edge problems that only few people are grasping.
We developed the library from the ground up in an incremental manner; starting from the core mapping between mathematical formulation of BVPy and thier FEniCS counterpart components and slowly adding up examples of increasing complexity (first Poisson's equation then linear elasticity, Turing systems, hyperelasticity..). We wrote the tutorial section in the same spirit, starting with the presentation of the various components (tutorials #1 to #4) and then presenting examples of increasing complexity (tutorials #5 and #6).
The example of use proposed in the manuscript (inspired by the penultimate section of tutorial #6), exposes the implementation of a mechanical equilibrium simulation on a cellularized structure (mimicking a 2D slice of a living tissue) with heterogeneous elastic properties. This example shows how easy it is in our framework: (i) to generate a FEniCS mesh from a cellular complex (produced by a third-party framework and encoded as a generic .ply
file), (ii) to define sub-domains on this mesh with heterogeneous parameter values to (iii) parametrize and run the corresponding simulations and (iv) to initiate results analysis. Of course all of this is doable in FEniCS alone (with a bit of help from Gmsh and Meshio to handle properly the input data) but we believe it would take far more than the 11 (almost self-explanatory) lines of code that we use as example in the manuscript.
[...] The fact that the authors have cited only a single paper written by themselves justifies this argument (library in early stages of development) and also that the theoretical framework needs to be established thoroughly before it can be published as a library.
We always try to minimize self-citiation as much as possible. But if necessary, we could add references of our recent works in the field of plantmorphomechanics modeling (Colin et al 2020 PNAS (published this very month) -- Ali et al 2019 Bull. of Math. Biol. -- Cheddadi et al 2019 PloS Comp. Biol. -- Olivery et al 2018 J. of Math. Biol. -- Armezzani et al 2017 Developement -- Cerutti et al 2017 Front. Plant Sci -- Boudon et al 2015 PLoS Comp. Biol., to cite a few). We have been working in this field for, at least, a decade and we have been developing a lot a various numerical approaches ever since. The underlying concepts behind our library come from this slowly-matured experience and have been implemented this year into BVPy.
That being said, it is de facto true that the library has not yet been used in any peer-reviewed publication (but will be in 2021). But this is intentional: we want to publish the library itself first to be a support for coming modeling publications. We also believe that in its current version the library has reached an optimal complexity level for its didactic presentation to the community. That is why we decided to submit the library for publication now.
In conclusion, from @chennachaos appreciation of our work we understand that:
The purpose of the library and the underlying "development philosophy" might not be properly explained in the manuscript. We propose to add a "State of the field" paragraph to the manuscript (as suggested earlier by @finsberg) to clarify our position and justify our strategy. We can also amend our Summary and Statement of need sections to better explain our motivations, if the reviewers think it would be valuable.
The lack of complex example(s) of use "might curb the enthusiasm" of some seasoned FEM-developers. To answer that, we propose to complement the tutorials with more complex examples, for instance we propose a 7th tutorial dedicated to hyperelastic simulations plant tissue tissular mechanics ( we could include plastic formalization of growth...).
We would like to thank again both @chennachaos and @finsberg for their constructive comments. We remain of course open to any suggestions to enhance the quality of our code and the clarity of its description.
@whedon generate pdf from branch joss-review
Attempting PDF compilation from custom branch joss-review. Reticulating splines etc...
:point_right::page_facing_up: Download article proof :page_facing_up: View article proof on GitHub :page_facing_up: :point_left:
Hi @finsberg , we followed your suggestion and added a “State of the field" section to the paper. Let us know if it fits your expectation or if you want a more detailed one.
Hi @finsberg , we followed your suggestion and added a “State of the field" section to the paper. Let us know if it fits your expectation or if you want a more detailed one.
Very good! I can now recommend BVPy for publication in JOSS.
I've opened a few issues on the repository, but I guess they are easy to solve (or to answer). There are still a few un-ticked boxes on the checklist, and they are mostly related to these issues. I will elaborate more on the others as soon as those issues are tackled.
I'd like to add I liked the structure of the software, it's well written with good documentation. The Vform classes are especially handy.
@IgorBaratta , thank you for your issues, I've provided some answers. @Kevin-Mattheus-Moerman , regarding the licence CeCILL-C, can you tell me if it is acceptable by the journal or should we change to another officially listed on the OSI website (like CeCILL-2.1) ?
@whedon generate pdf
:point_right::page_facing_up: Download article proof :page_facing_up: View article proof on GitHub :page_facing_up: :point_left:
@oalii if you are able to switch to an OSI approved license please do, this is required for JOSS.
@Kevin-Mattheus-Moerman and @IgorBaratta,
we changed the licence from CeCILL-C to LGPL V3.
@oalii can you point me to the updated license? I cannot see it updated in the repository :point_up:
@Kevin-Mattheus-Moerman , it is updated within the JOSS-review branch: https://gitlab.com/oali/bvpy/-/blob/joss-review/LICENSE .
@chennachaos and @Kevin-Mattheus-Moerman ,
As proposed earlier, we added a seventh tutorial containing some basic hyper-elasticity simulations as well as a "more complex" model mixing quasi-static mechanics with Turing-like system to illustrate the use of BVPy to tackle models mixing several types of fields. We hope this example could be seen as a first step toward "multi-physics" modeling within BVPy.
We also tried to highlight within this tutorial the inter-operability between BVPy and FEniCS.
Hi @Kevin-Mattheus-Moerman and reviewers,
All the best for this coming new year. Hope you are all doing well despite the gloomy context...
A quick message to catch up on the reviewing process after the holiday season. Just before the Christmas break, we added some new examples of use to address the concerns raised by reviewer @chennachaos, changed the licence and responded to the questions raised by @IgorBaratta.
Do the reviewers have other remarks/questions/concerns to raise ? Let us know.
Thanks for your help.
Great thanks for the update @oalii
@IgorBaratta, @chennachaos, can you have another look at this submission and tick more boxes if possible or summarize what are points that still need work? Thanks a lot for your help!!!
Submitting author: @oalii (Olivier Ali) Repository: https://gitlab.com/oali/bvpy Version: v1.0.1 Editor: @Kevin-Mattheus-Moerman Reviewer: @IgorBaratta, @chennachaos, @finsberg Archive: 10.5281/zenodo.4590758
: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 badge code:
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
@IgorBaratta & @chennachaos & @finsberg, please carry out your review in this issue by updating the checklist below. If you cannot edit the checklist please:
The reviewer guidelines are available here: https://joss.readthedocs.io/en/latest/reviewer_guidelines.html. Any questions/concerns please let @Kevin-Mattheus-Moerman 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 @IgorBaratta
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
Review checklist for @finsberg
Conflict of interest
Code of Conduct
General checks
Functionality
Documentation
Software paper