[REVIEW]: scikit-finite-diff, a new tool for PDE solving

whedon commented 5 years ago

Submitting author: @celliern (Nicolas Cellier) Repository: https://gitlab.com/celliern/scikit-fdiff/ Version: v0.6.0 Editor: @Kevin-Mattheus-Moerman Reviewer: @mrava87, @poulson Archive: 10.5281/zenodo.3236970

Status

Status badge code:

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

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) 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

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

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

The reviewer guidelines are available here: https://joss.theoj.org/about#reviewer_guidelines. Any questions/concerns please let @Kevin-Mattheus-Moerman know.

✨ Please try and complete your review in the next two weeks ✨

Review checklist for @mrava87

Conflict of interest

[x] As the reviewer I confirm that I have read the JOSS conflict of interest policy and that there are no conflicts of interest for me to review this work.

Code of Conduct

[x] I confirm that I read and will adhere to the JOSS code of conduct.

General checks

[x] Repository: Is the source code for this software available at the repository url?
[x] License: Does the repository contain a plain-text LICENSE file with the contents of an OSI approved software license?
[x] Version: v0.6.0
[x] Authorship: Has the submitting author (@celliern) made major contributions to the software? Does the full list of paper authors seem appropriate and complete?

Functionality

[x] Installation: Does installation proceed as outlined in the documentation?
[x] Functionality: Have the functional claims of the software been confirmed?
[x] Performance: If there are any performance claims of the software, have they been confirmed? (If there are no claims, please check off this item.)

Documentation

[x] A statement of need: Do the authors clearly state what problems the software is designed to solve and who the target audience is?
[x] Installation instructions: Is there a clearly-stated list of dependencies? Ideally these should be handled with an automated package management solution.
[x] Example usage: Do the authors include examples of how to use the software (ideally to solve real-world analysis problems).
[x] Functionality documentation: Is the core functionality of the software documented to a satisfactory level (e.g., API method documentation)?
[x] Automated tests: Are there automated tests or manual steps described so that the function of the software can be verified?
[x] Community guidelines: Are there clear guidelines for third parties wishing to 1) Contribute to the software 2) Report issues or problems with the software 3) Seek support

Software paper

[x] Authors: Does the paper.md file include a list of authors with their affiliations?
[x] A statement of need: Do the authors clearly state what problems the software is designed to solve and who the target audience is?
[x] References: Do all archival references that should have a DOI list one (e.g., papers, datasets, software)?

Review checklist for @poulson

Conflict of interest

[x] As the reviewer I confirm that I have read the JOSS conflict of interest policy and that there are no conflicts of interest for me to review this work.

Code of Conduct

[x] I confirm that I read and will adhere to the JOSS code of conduct.

General checks

[x] Repository: Is the source code for this software available at the repository url?
[x] License: Does the repository contain a plain-text LICENSE file with the contents of an OSI approved software license?
[x] Version: v0.6.0
[x] Authorship: Has the submitting author (@celliern) made major contributions to the software? Does the full list of paper authors seem appropriate and complete?

Functionality

[x] Installation: Does installation proceed as outlined in the documentation?
[x] Functionality: Have the functional claims of the software been confirmed?
[x] Performance: If there are any performance claims of the software, have they been confirmed? (If there are no claims, please check off this item.)

Documentation

[x] A statement of need: Do the authors clearly state what problems the software is designed to solve and who the target audience is?
[x] Installation instructions: Is there a clearly-stated list of dependencies? Ideally these should be handled with an automated package management solution.
[x] Example usage: Do the authors include examples of how to use the software (ideally to solve real-world analysis problems).
[x] Functionality documentation: Is the core functionality of the software documented to a satisfactory level (e.g., API method documentation)?
[x] Automated tests: Are there automated tests or manual steps described so that the function of the software can be verified?
[x] Community guidelines: Are there clear guidelines for third parties wishing to 1) Contribute to the software 2) Report issues or problems with the software 3) Seek support

Software paper

[x] Authors: Does the paper.md file include a list of authors with their affiliations?
[x] A statement of need: Do the authors clearly state what problems the software is designed to solve and who the target audience is?
[x] References: Do all archival references that should have a DOI list one (e.g., papers, datasets, software)?

whedon commented 5 years ago

Hello human, I'm @whedon, a robot that can help you with some common editorial tasks. @mrava87, it looks like you're currently assigned as the reviewer for this paper :tada:.

: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:

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

watching

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

whedon commented 5 years ago

Attempting PDF compilation. Reticulating splines etc...

whedon commented 5 years ago

PDF failed to compile for issue #1356 with the following error:

% Total % Received % Xferd Average Speed Time Time Time Current Dload Upload Total Spent Left Speed

0 0 0 0 0 0 0 0 --:--:-- --:--:-- --:--:-- 0 100 13 0 13 0 0 254 0 --:--:-- --:--:-- --:--:-- 260 Can't compile the PDF, the bibtex file has 3 extraneous references: @Rang:2015, @Cellier:2018, @Leveque:2002

mrava87 commented 5 years ago

Hi @celliern, nice library. Here are some comments. As they are all quite general I have not created issues on the repo yet. Please have a look and let me know if everything is clear and if you agree with the suggested points and I will create some specific issues for those tasks you agree you will be able to tackle.

General comments:
- I find this tool very nice and valuable. When reading your documentation I see a lot of similarities with https://www.devitoproject.org which you may have never come across as it is more focused on geophysical problems (any sort of wave equation). I suggest to take a look and cite it in your paper and perhaps get in touch with the authors to discuss similarities of your packages - this is definitely up to you and beyond the review process of this paper :)
- What about second order time derivatives: how would you solve a wave equation (https://en.wikipedia.org/wiki/Acoustic_wave_equation), I don't seem to find anything in the documentation?
- Adding external forces: again, taking the acoustic wave equation, it is not always natural to have an initial condition, rather you would like to have an external at some location (your source) so the equation becomes dttU - 1/c**2 dxxU = f. I would assume you can implement f using the Hook but I am not sure why I would call this a non-linear effect then as this is linear. Can you comment?
Paper: fix the following typos
- developpment —> development
- Paper: The later —> The latter
- Paper: sparsed by nature —> it is sparse by nature?
- Paper: writting—> writing
Installation: I don’t see packages in scikit-fdiff conda channel that you mention in the documentation.
Examples:
- in the example you show in the landing page of read the docs, I suggest to point to the exact equation you implement in wikipage (Non-conservative form?)
- examples in the README file and documentation are hard to try out as you need to manually copy paste and remove >>>>. I suggest to at least remove those >>>>. A better solution could be to add links to python scripts (or better jupyter-notebooks) and even better to convert them into sphinx-gallery examples which are run as part of readthedoc build project. I see two main advantages by implementing this last option: i) you are entirely sure your examples will always run, typos or changes in code that you forget to fix in the example will be easy to spot as your documentation build would crash otherwise, ii) everyone can download python files or notebooks with the example and run it.
Contribution: I can’t find any info related to how to contribute, https://scikit-fdiff.readthedocs.io/en/latest/contribute.html# is empty.
Documentation API: I see that your documentation, especially is very accurate in the going further section. However it looks to me a bit more like a long story (paper style) other than a software documentation. I would strive to include also a skdiff API section where users have easy to all main classes and functions in your library that you want to expose to them. If for example I want to use fft routines in numpy but I do not need to understand the theory behind as I am familiar I will go here https://docs.scipy.org/doc/numpy/reference/routines.fft.html, I feel something along this lines is lacking in your documentation. As you use sphinx it is very easy to add something like that, if you don’t know how to do it I can point you to some examples :)
Versioning: I am not sure this project follows semantic versioning. You say that v0.6.0 is a huge step for the software, does this make it incompatible with previous versions (any backward incompatible change being made?). I would think that if the software name changed all the imports in previous scripts will not work anymore? In that case is very important to boost the first number (here would be v1.0.0). I am not sure how to go about here but I think you should aware and at least strive for that from here onwards.
News / TODO / Roadmad: suggest to move this to independent md file and/or in documentation

That's all for me, really nice to discover this library!

MR

celliern commented 5 years ago

Hi @mrava87 ! Thanks for the review !

I will answer to the different points :

I wasn't aware of Devito, I will look at the paper and sure discuss with the team ! Some part of scikit-fdiff could may use Devito internal, reducing development / maintenance cost of the software.
Second order time derivative can be solved with using an intermediate variable and solving two first order equation instead of one second order equation.
You can implement external force by writing them explicitly as model = Model("dxxU - 1/c**2 dxxU - f", "U(x)", parameters=["f"]) then providing f when initializing the fields. You can also explicitly write "f" if you have it as a function of x. model = Model("dxxU - 1/c**2 dxxU - f", "U(x)", subs={"f": "cos(x)"}) for example.
The conda package was in project, but some of the dependencies are not in conda-forge. I will remove that from the doc, and I "may" add all the deps and the software to conda-forge. As scikit-fdiff is pip installable both under linux and windows, It's not top priority anymore.
A sphinx gallery is plan (maybe next week?). For now, all the example are in doctest form (explaining the >>>). This means that they tested during the gitlab pipeline, ensuring they run correctly. Short term will have the two : doctest in the readme and a cookbook with example as jupyter notebooks.
Contribution : my bad! Forgot that part. Will appear (very) soon !
I will add the API page thank to autodoc. I'll try to do that this week.
Versioning : the rule for semantic versioning are slightly different when < 1.0. In that case, breaking rules are allowed between "minor" revision, as the software is still in early stages. This version (0.6) was the one it goes from 1D only / specific case to (I hope) a really useful tool with arbitrary dimension. It is close to its final form, but I could not go to the 1.0 before more external review (and JOSS is an important part of its external review), and being more used in different cases.
I will certainly make a separate file for the news / TODO / roadmap as you suggest.

I will also do the typo fixes for the paper.

Thank a lot for all these remarks !

Nicolas Cellier

mrava87 commented 5 years ago

No problem :) Let me know when you have added things and I will take another look

Just a quick follow up:

Second order time derivative can be solved with using an intermediate variable and solving two first order equation instead of one second order equation.

I assumed that would have been the case but wasn't sure if you could do it with second order time derivative as well, good to know :)

You can implement external force by writing them explicitly as model = Model("dxxU - 1/c**2 dxxU - f", "U(x)", parameters=["f"]) then providing f when initializing the fields. You can also explicitly write "f" if you have it as a function of x. model = Model("dxxU - 1/c**2 dxxU - f", "U(x)", subs={"f": "cos(x)"}) for example.

Maybe I wasn't precise enough, I meant a time-space dependent external forcing f, for example say I want to implement this set of equations:

dtVx = -dxP/rho,
dtVy = -dyP/rho,
dtP = -dxVx/k - dyVy/k +q,

where q(t, x, y), can you do that?

celliern commented 5 years ago

You can do that in two way : If you have the explicit q function, you can define put it in the model :

model = Model(["-dxP / rho", "-dyP / rho", "-dxVx / k - dyVy / k + cos(t) * sin(y) + x**2"],
                         ["Vx", "Vy", "P"],
                         parameters=["rho", "k"])

or use the subs argument to lighten a bit the writting

model = Model(["-dxP / rho", "-dyP / rho", "-dxVx / k - dyVy / k + q"],
                         ["Vx", "Vy", "P"],
                         parameters=["rho", "k"],
                         subs={"q": "cos(t) * sin(y) + x**2"})

Or, if you cannot write q as a sympy expr, you can provide it as a parameters, then update it using a hook.

model = Model(["-dxP / rho", "-dyP / rho", "-dxVx / k - dyVy / k + q"],
                         ["Vx", "Vy", "P"],
                         parameters=["rho", "k", "g"])

def compute_q(t, fields):
    fields["q"] = some_stuff_to_process_g(t, fields)
    return fields

simulation = Simulation(..., hook=compute_q)

mrava87 commented 5 years ago

Nice :) I followed this and got an example working but I think there are still some issues with dispersion due to source injection. Let's take this off this issue and do it here https://gitlab.com/celliern/scikit-fdiff/issues/2

celliern commented 5 years ago

Hello again ! A word to say that most of the point addressed have been fixed. There is just the creation of the cookbook that is missing, but you can already look at the new version of the documentation if you want.

It will be in the dev branch :

mrava87 commented 5 years ago

Great :)

Looks very good to me. Just one minor thing:

make sure to remove News / TODO / Roadmad etc. from the list of index in the README as now their link is broken.

Congrats with a nice software and documentation. This is good to go for me when you get the cookbook and adapt the paper (don't see it the pdf here)

Kevin-Mattheus-Moerman commented 5 years ago

@poulson can you please also contribute your side of the review? Thanks!

poulson commented 5 years ago

@Kevin-Mattheus-Moerman Please excuse the delay, I am getting back to this now!

poulson commented 5 years ago

@whedon generate pdf

whedon commented 5 years ago

Attempting PDF compilation. Reticulating splines etc...

whedon commented 5 years ago

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

poulson commented 5 years ago

Thank you for your patience, Nicolas (@celliern).

First, some comments on the paper:

The FEniCS Project is quite popular and has similar, if not more aggressive, goals, and deserves to be referenced.
You are making use of SymPy for your symbolic manipulations, and so it would be good form to provide a citation of the project rather than simply stating that you are doing symbolic manipulations.
The sentence on using "as few computational resources" as possible strikes me as a slightly redundant overstatement of the impact of making use of sparsity, as essentially all PDE and ODE solvers make use of sparsity, and doing so does not imply optimality.
There are a few spelling errors. For example: "development" is twice written as "developpement", "providing" as "provinding", "the latter" as "the later", "sparse" as "sparsed", "reasonable" as "reasoneable", "Nicolson" as "Nickolson", "complex" as "complexe", and "Rosenbock" as "Rosebock".

Some comments on the code itself:

I looked over and ran the examples, and there does not appear to be any plotting or querying of the solution itself, only the mean values. I would recommend using matplotlib, or an equivalent library, to visualize some of the solutions.
Further, your paper mentions that scikit-diff has been validated on a dam break problem, among others. Why not include these as examples? The current examples are a bit too elementary and do not stress the type of functionality that would be needed for the mentioned validations.
Feel free to ignore this suggestion, but there are very few docstrings or comments in your code. It might be a good idea to add docstrings to the major functions and classes.
Feel free to ignore this suggestion, but PEP 8 suggests limiting your code to at most 79 characters, and yours goes well beyond 80.

celliern commented 5 years ago

Hello !

No problem : the review process is still way faster than any "classic" journal.

Note taken for the references : I will add references to the Fenics project, and better, say a word on software targeting the same goals and their difference with my project. I will add citation for sympy as well as other main dependencies as well.

For the computational resources, it's a bit more than just the sparsity : as the system is entirely discretized with sympy, the numerical routines (F and J) are as simple as possible, making them really fast (even with the default numpy backend). In addition, the vectorization chosen for the repartition of the unknown lead to an "optimal" system to solve (as decribed here). Moreover, using by default Rosenbrock Wanner schemes allow to have only one system factorization for one time upgrade, drastically reducing the numerical cost. My bad, I should have add that to the paper. I will be done.

Thanks to the spelling, they will be fixed soon.

For the examples, I am building a gallery as @mrava87 already suggests. The 1D / 2D dam break will be present as well as more complex cases.

I note the suggestion for the docstring. I will add the docstring for all public methods (but as being solo for this project for now, this will take some time...).

For the limiting of 79 characters, I chose to use the black formatting that set the limit to pep8 + 10%, and their reasonning can be found here.

Thank you for the review. I will modify the paper and create the gallery as fast as I can (but being in vacation, I cannot work as fast as I would).

celliern commented 5 years ago

As complement on the examples, you can find two complex working examples (that will be in the gallery) here :

https://nbviewer.jupyter.org/gist/celliern/c9f408c905b2cd533dcb7c7ffbe9c851

The first one has been built by @mrava87, the second one is a 2D dam break problem.

poulson commented 5 years ago

@whedon generate pdf

whedon commented 5 years ago

Attempting PDF compilation. Reticulating splines etc...

whedon commented 5 years ago

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

celliern commented 5 years ago

Hello again!

Sorry for the delay !

I have updated the repository as well as the doc with the different suggestions, and I have added some examples and validation cases to a cookbook.

https://gitlab.com/celliern/scikit-fdiff/ https://scikit-fdiff.readthedocs.io/ https://scikit-fdiff.readthedocs.io/en/latest/auto_examples/index.html

@mrava87 @poulson

mrava87 commented 5 years ago

Hi, nice to see all the changes you implemented. I am happy to recommend this for publication.

Just one small comment regarding the example One dimension shallow water, dam break case. I struggle to see the equation that you write in the implementation. For example the first eq has one term (plus the time deriv)... ignore this comment if you think I am wrong :)

poulson commented 5 years ago

I am also very happy to see the added examples: I believe the package is significantly improved as a result.

I would also add the small comment that the timings for the 2D acoustic wave and dam examples are both listed as 0 seconds; it would be great if timings on a commodity laptop or workstation were added.

EDIT: I should also add that a short 'How to contribute' section in the README, or a 'CONTRIBUTING' file, would be ideal.

Other than that, I am happy to recommend this for publication as well.

celliern commented 5 years ago

@mrava87 You are right, they should be equivalent, but the notation differs and leads to confusion. I will fix it.

@poulson I will "clone" the doc contribute to the readme, as you suggest. The 0 timing is due to the rtd limitation: I cannot generate "huge" case in their servers. To be coherent, I will benchmark all the simulation cases on laptop / desktop and small cluster (4 / 8 / 32 cpu, with specs) to have a good idea. Update very soon !

Kevin-Mattheus-Moerman commented 5 years ago

@celliern let us know when you've implemented all changes so we can resume review. Below are some points to consider.

[x] In terms of contributing guidelines, have you added anything yet? I recommend creating a CONTRIBUTING.md file and linking to it in the README.md file with a nice heading. There are guidelines and templates for creating such a file available too (here is one of mine).
[x] It is also good practice to add a COC.md (code of conduct) file and link to it in the README.md file too. There is a template for that here: https://www.contributor-covenant.org/

celliern commented 5 years ago

@Kevin-Mattheus-Moerman @mrava87 @poulson

Hello!

I did the requested changes: a proper benchmark of the examples, some fix in the equations. I have also linked the contrubute section of the doc in the readme and added a code of conduct.

The changes live in the dev branche

https://gitlab.com/celliern/scikit-fdiff/tree/dev https://scikit-fdiff.readthedocs.io/en/dev/index.html

Kevin-Mattheus-Moerman commented 5 years ago

Great. @celliern. Minor point, I noticed your README says "See the contribe section of the doc" which should probably read: "See the contribute section of the doc"

Kevin-Mattheus-Moerman commented 5 years ago

@mrava87 @poulson can you review these updates

mrava87 commented 5 years ago

I did. Everything looks good to me, thanks for updating the documentation :)

poulson commented 5 years ago

I am happy to recommend this for publication as well. @Kevin-Mattheus-Moerman

celliern commented 5 years ago

Hello @Kevin-Mattheus-Moerman !

I have fixed the typo you noticed, and updated the master branch to the repo. Is there anything left I can do?

Kevin-Mattheus-Moerman commented 5 years ago

@celliern no thank for alerting me. I'll run a few check and will let you know if anything needs to be done

Kevin-Mattheus-Moerman commented 5 years ago

@whedon generate pdf

whedon commented 5 years ago

Attempting PDF compilation. Reticulating splines etc...

whedon commented 5 years ago

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

Kevin-Mattheus-Moerman commented 5 years ago

@whedon check references

whedon commented 5 years ago

Attempting to check references...

whedon commented 5 years ago


OK DOIs

- 10.1016/j.cam.2015.03.010 is OK
- 10.7717/peerj-cs.103 is OK

MISSING DOIs

- None

INVALID DOIs

- None

Kevin-Mattheus-Moerman commented 5 years ago

@celliern below are suggested changes to your paper. I tried to improve the language, rephrase some difficult sentences, and fixed several typos. Can you please check it thoroughly to make sure I did not misunderstand/break what you tried to say in some of your sentences. If you agree with these changes please paste them into your paper.md file. I also suggest you add a sentence to the last paragraph to hint at applications. Currently it suddenly mentions "the shallow water equation". Perhaps you can start it with something like: "Scikit-FDiff can be used for a wide range of application including A, B and C. To date the authors have used it for solving X type of problems. Furthermore, Scikit-Fdiff has been validated for solving the shallow-water equation on dam-breaks ..."

Scikit-FDiff is a new tool for Partial Differential Equation (PDE) solving, written in pure Python, that focuses on reducing the time between the development of the mathematical model and the numerical solving.

It allows easy and automated finite difference discretization, thanks to symbolic processing (using the SymPy library [@Meurer:2017]) which can deal with systems of multi-dimensional partial differential equations and complex boundary conditions.

Using finite differences, and the method of lines, Scikit-FDiff allows for the transformation of the original PDE into an Ordinary Differential Equation (ODE), providing fast computation of the temporal evolution vector and the Jacobian matrix. The latter is pre-computed in a symbolic way and is sparse by nature. An efficient vectorization allows one to formulate the numerical system in such a way as to facilitate the numerical solver work, even for complex multi-dimensional coupled cases. Systems can be evaluated with as few computational resources as possible, enabling the use of implicit and explicit solvers at a reasonable cost.

Scikit-FDiff stands out in comparison to other competitors, such as the FEniCS Project, Clawpack, or the Dedalus Project, in terms of its simplicity. Despite the fact that Scikit-FDiff uses a relatively simple method (finite-differences), which allows one to code in a way which is close to the mathematical model, it is able to solve real-world problems. It is however less suited than other packages for building specialized solvers.

Scikit-FDiff also contains several classic ODE solver implementations (some of which have been made available from dedicated python libraries), including the backward and forward Euler scheme, Crank-Nicolson, and explicit Runge-Kutta. More complex approaches, like the improved Rosenbrock-Wanner schemes [@Rang:2015] up to the 6th order, are also available in Scikit-FDiff. The time-step is managed by a built-in error computation, which ensures the accuracy of the solution.

The main goal of this software is to minimize the time spent writing numerical solvers allowing one to focus on model development and data analysis. Therefore, Scikit-Fdiff has been formulated such that it can solve both simple examples and complex models in only a few line of code. In addition, extra tools are provides, such as data saving during the simulation, real-time plotting, and post-processing.

Scikit-Fdiff has been validated with the shallow-water equation on dam-breaks [@Leveque:2002] and the steady-lake case. It has also been applied to heated falling-films [@Cellier:2018], droplet spread, and simple moisture flow in a porous medium.

Kevin-Mattheus-Moerman commented 5 years ago

@mrava87, @poulson thanks for reviewing this submission! :tada:

@mrava87 are you able to tick those last boxes?

mrava87 commented 5 years ago

Done, thanks @Kevin-Mattheus-Moerman for assisting us in the process and congrats @celliern

celliern commented 5 years ago

@Kevin-Mattheus-Moerman done for the paper modification ! Thanks @poulson and @mrava87 for the review and @Kevin-Mattheus-Moerman for the edition !

Kevin-Mattheus-Moerman commented 5 years ago

@whedon generate pdf

whedon commented 5 years ago

Attempting PDF compilation. Reticulating splines etc...

whedon commented 5 years ago

PDF failed to compile for issue #1356 with the following error:

/app/vendor/bundle/ruby/2.4.0/bundler/gems/whedon-379fcd917139/lib/whedon.rb:114:in check_fields': undefined methodkeys' for # (NoMethodError) from /app/vendor/bundle/ruby/2.4.0/bundler/gems/whedon-379fcd917139/lib/whedon.rb:80:in initialize' from /app/vendor/bundle/ruby/2.4.0/bundler/gems/whedon-379fcd917139/lib/whedon/processor.rb:36:innew' from /app/vendor/bundle/ruby/2.4.0/bundler/gems/whedon-379fcd917139/lib/whedon/processor.rb:36:in set_paper' from /app/vendor/bundle/ruby/2.4.0/bundler/gems/whedon-379fcd917139/bin/whedon:55:inprepare' from /app/vendor/bundle/ruby/2.4.0/gems/thor-0.20.3/lib/thor/command.rb:27:in run' from /app/vendor/bundle/ruby/2.4.0/gems/thor-0.20.3/lib/thor/invocation.rb:126:ininvoke_command' from /app/vendor/bundle/ruby/2.4.0/gems/thor-0.20.3/lib/thor.rb:387:in dispatch' from /app/vendor/bundle/ruby/2.4.0/gems/thor-0.20.3/lib/thor/base.rb:466:instart' from /app/vendor/bundle/ruby/2.4.0/bundler/gems/whedon-379fcd917139/bin/whedon:116:in <top (required)>' from /app/vendor/bundle/ruby/2.4.0/bin/whedon:23:inload' from /app/vendor/bundle/ruby/2.4.0/bin/whedon:23:in `

'

Kevin-Mattheus-Moerman commented 5 years ago

@arfon do you know what's going wrong here?

arfon commented 5 years ago

@Kevin-Mattheus-Moerman - it looks like the paper isn't structured for JOSS properly https://gitlab.com/celliern/scikit-fdiff/blob/master/paper.md

See https://joss.readthedocs.io/en/latest/submitting.html#example-paper-and-bibliography on how the paper should be structured.

Kevin-Mattheus-Moerman commented 5 years ago

@celliern the paper is not being generated because you deleted this from the top, please put it back:

---
title: 'scikit-finite-diff, a new tool for PDE solving'
tags:
  - python
  - pde
  - physical modelling
authors:
  - name: Nicolas Cellier
    orcid: 0000-0002-3759-3546  
    affiliation: 1
  - name: Christian Ruyer-Quil
    affiliation: 1
affiliations:
 - name: Université Savoie Mont-Blanc
   index: 1
date: 18 March 2019
bibliography: paper.bib
---

Also I noticed you removed the references to [@Leveque:2002] (dam breaks) and [@Cellier:2018] (heated falling-films). It is good to comment on the use of the software with such references so I would encourage you to put these back unless you have a good reason to remove them.

Kevin-Mattheus-Moerman commented 5 years ago

@celliern In relation to the paper, I created a merge request here with proposed changes to the paper: https://gitlab.com/celliern/scikit-fdiff/merge_requests/3 can you check that out?

As you can see I also added an Acknowledgement, and a Reference heading. The References will be added automatically but you need to add text for the acknowledgements.

openjournals / joss-reviews