Joss-reviews: [REVIEW]: MoFEM: An open source, parallel finite element library

[whedon]

Submitting author: @likask (Lukasz Kaczmarczyk)
Repository: https://bitbucket.org/likask/mofem-cephas
Version: v0.9.0-joss
Editor: @jedbrown
Reviewers: @tjhei, @chrisrichardson, @Kevin-Mattheus-Moerman, @vijaysm, @chennachaos
Archive: 10.5281/zenodo.3627253

Status

Status badge code:

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

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

@tjhei & @chrisrichardson, @Kevin-Mattheus-Moerman, @vijaysm, & @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 @jedbrown know.

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

Review checklist for @tjhei

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.9.0-joss
• [x] Authorship: Has the submitting author (@likask) 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 @chrisrichardson

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.9.0-joss
• [x] Authorship: Has the submitting author (@likask) 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 @Kevin-Mattheus-Moerman

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.9.0-joss
• [x] Authorship: Has the submitting author (@likask) 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 @vijaysm

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.9.0-joss
• [x] Authorship: Has the submitting author (@likask) 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 @chennachaos

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.9.0-joss
• [x] Authorship: Has the submitting author (@likask) 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]

Hello human, I'm @whedon, a robot that can help you with some common editorial tasks. @tjhei, 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:

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

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

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

@whedon commands

[whedon]

Attempting PDF compilation. Reticulating splines etc...

[whedon]

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

[jedbrown]

@tjhei @chrisrichardson @Kevin-Mattheus-Moerman :wave: Welcome and thanks for agreeing to review! The comments from @whedon above outline the review process, which takes place in this thread (possibly with issues filed in the MoFem repository). I'll be watching this thread if you have any questions.

[likask]

Thank you all for agreeing to spend some time on this. Making life easier, to kick start installation, you can use docker & spack as follows:

git clone --recurse-submodules https://bitbucket.org/likask/mofem-cephas.git mofem-cephas
cd mofem-cephas
docker build -t spack_mofem_build --force-rm=true --file=Dockerfile-spack-mofem-testing .

[chrisrichardson]

@whedon commands

[whedon]

Here are some things you can ask me to do:

# List Whedon's capabilities
@whedon commands

# List of editor GitHub usernames
@whedon list editors

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

EDITORIAL TASKS

# Compile the paper
@whedon generate pdf

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

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

[chrisrichardson]

@likask - https://bitbucket.org/likask/mofem-cephas/src/joss/media/paper.md seems not to work. Is this the correct URL anyway?

[likask]

@chrisrichardson Hello, I had to move paper to the directory visible by whedon to generate PDF. You will find it here https://bitbucket.org/likask/mofem-cephas/src/master/joss/paper.md

See here to view compiled PDF

[chrisrichardson]

@likask - it seems like something must be wrong though. The URL is supposed to point at the software, not the paper?

Repository: Is the source code for this software available at the repository url?

[arfon]

@whedon generate pdf

[whedon]

Attempting PDF compilation. Reticulating splines etc...

[arfon]

@likask - it seems like something must be wrong though. The URL is supposed to point at the software, not the paper?

I've updated the URL for the software at the top of the review issue.

[whedon]

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

[likask]

@arfon Thank you.

@chrisrichardson Source for a master branch is here. Alternatively, you can browse in doxygen generated web-pages here.

[vijaysm]

@likask Please update the version number being reviewed to v0.8.23 if necessary.

Also, fix the broken link to the paper as well. I see your comment above but it would be good to have this propagated on this issue page if possible.

[likask]

I think that version could be bumped at the very end. If you are looking for the source of the paper, it is here link. That is in joss folder in root repo directory in the master branch.

[likask]

@jedbrown are you aware of any major problem enabling to reviewers kick start or complete review? Can I be any help?

[jedbrown]

@likask I'm not aware of any issues. Two reviewers have started ticking boxes in the review. I'll start reminding in a couple weeks if there is no further visible progress.

[Kevin-Mattheus-Moerman]

@jedbrown I'll provide my review by the end of this week. Apologies for the delay so far.

[Kevin-Mattheus-Moerman]

@likask can you point me to some more basic documentation on how to get started to run some examples. I did the following as you suggested:

git clone --recurse-submodules https://bitbucket.org/likask/mofem-cephas.git mofem-cephas
cd mofem-cephas
docker build -t spack_mofem_build --force-rm=true --file=Dockerfile-spack-mofem-testing .

I then studied this demo, went to: /mofem-cephas/mofem/users_modules/basic_finite_elements/nonlinear_elasticity/examples/dam and ran:

mpirun -np 4 ../../nonlinear_dynamics \
-my_file dam.h5m \
-ksp_type fgmres \
-pc_type lu -pc_factor_mat_solver_package mumps \
-ksp_atol 1e-10 -ksp_rtol 1e-12 -ksp_monitor \
-snes_type newtonls -snes_linesearch_type basic \
-snes_max_it 10 -snes_atol 1e-4 -snes_rtol 1e-8 -snes_monitor \
-ts_monitor -ts_type alpha -ts_dt 0.002 \
-ts_final_time 8 -ts_max_snes_failures -1 \
-my_time_data_file dam_history.in \
-my_accelerogram accelerogram.in \
-my_solve_at_time_zero 1 \
-my_output_prt -1 -my_max_post_proc_ref_level 0 \
-my_disp_order 2 \
-default_material HOOKE -is_linear -snes_lag_jacobian -2 \
-elastic_material_configuration block_data.in 2>&1 | tee log

This resulted in:

mpirun was unable to launch the specified application as it could not access
or execute an executable:

Executable: ../../nonlinear_dynamics
Node: newton

while attempting to start process rank 0.

[likask]

@Kevin-Mattheus-Moerman I apologise for the confusion, I put this to run units tests in the docker. We are using that for testing. I see that you run this successfully for core lib and users modules,

core
users modules

If you like to run some particular cases, is better to use spack on the system. However, if you like you, you can execute the dam example as follows

Run docker container

docker run --rm=true -it -vpwd/mofem:/mofem -v $HOME:$HOME -e HOSTHOME=$HOME spack_mofem_build /bin/bash

In doceker

cd /mofem_build/um/build/basic_finite_elements/nonlinear_elasticity
make
cp /mofem/users_modules/basic_finite_elements/nonlinear_elasticity/examples/dam/* .
/mofem_build/um/um_view/bin/mpirun --allow-run-as-root -np 4 ./nonlinear_dynamics \
-my_file dam.h5m  \
-ksp_type fgmres -pc_type lu -pc_factor_mat_solver_package mumps -ksp_atol 1e-10 -ksp_rtol 1e-12 -ksp_monitor \
-snes_type newtonls -snes_linesearch_type basic -snes_max_it 10 -snes_atol 1e-4 -snes_rtol 1e-8 -snes_monitor \
-ts_monitor -ts_type alpha -ts_dt 0.002 -ts_final_time 8 -ts_max_snes_failures -1 \
-my_time_data_file dam_history.in -my_accelerogram accelerogram.in -my_solve_at_time_zero 1 \
-my_output_prt -1 -my_max_post_proc_ref_level 0 \
-my_disp_order 2 -default_material HOOKE -is_linear -snes_lag_jacobian -2 \
-elastic_material_configuration block_data.in 2>&1 | grep -v "Read -1" | tee log

[Kevin-Mattheus-Moerman]

@likask I'm not a C++ specialist and this is also my first real experience with Docker. Part of the dam example ran using the above code (which is not trivial to set up, should you simplify this and create a run_dam_example script?). Also the dam models takes very long to run. How can a user see how long the model has to go? Can you add a progress indicator e.g. steps 50 of 100 or 50%.

Can you create (or point me to) an extremely simple, e.g. uniaxial tension of a cube, example that runs really fast?

Can you add documentation on how to visualize the results? How can I do do_vtk.sh out_values_*h5m from Docker? How do I use ParaView from Docker? Or how do I get at the files generated in Docker from outside the Docker session?

[likask]

@Kevin-Mattheus-Moerman it could be that docker is not the best choice, but we can work with it.

Run docker container

docker run --rm=true -it -v `pwd`/mofem:/mofem -v $HOME:$HOME -e HOSTHOME=$HOME spack_mofem_build /bin/bash

Run simple L-shape beam which will run very quick.

In docker just copy and paste following script,

```
cd /mofem_build/um/build/basic_finite_elements/elasticity \
make \
cp /mofem/users_modules/basic_finite_elements/elasticity/LShape.h5m . \
./elasticity -my_file LShape.h5m -ksp_type gmres -pc_type lu -pc_factor_mat_solver_package mumps -ksp_monitor -my_order 2 \
/mofem_build/um/build/basic_finite_elements/elasticity# /mofem_build/um/um_view/bin/mbconvert out.h5m out.vtk
````

You can copy out.vtk file somewhere to your host directory, if you are in Mac OS, somewhere to /User, on linux /home, and see VTK in ParaView.

[tjhei]

FYI: I am documenting some of the issues I am having here: https://bitbucket.org/likask/mofem-cephas/issues/15/joss-review

[likask]

@vijaysm Can you look here
https://bitbucket.org/likask/mofem-cephas/issues/15/joss-review
It could be an issue with make install with MOAB?

[tjhei]

@jedbrown I finished reviewing and testing the MoFEM library. @likask has been responsive in the issues I raised. I think there is room for major improvements in the documentation of the examples, specifically how to run the programs. My struggles are documented in the issue linked above. Otherwise, I am happy to accept this.

[jedbrown]

Thanks, @tjhei.
@likask Thanks for being responsive. Please update when you feel that revision of documentation/installation/examples is complete.

[likask]

@jedbrown We have open pull request updating READMEs and documentation as results @tjhei comments and problems.

pull request

[vijaysm]

@likask Several comments below regarding build/installation workflows.

• I've had multiple failed attempts going via the Docker route. The container builds do not complete the MoFEM compilation on my OSX machine. I tried multiple times but it just times out. I am unsure if it is just my machine here.

• I was able to build the Docker image on my Ubuntu workstation. There were several "unused variable" warnings during compilation but the MoFEM build and test runs succeeded, along with a CDash dashboard update.

• I then loaded up the image and wanted to run some of the examples as shown in [1]. There is still no clear documentation on how to proceed with this, after having an installation handy.

• Can you please point me to the instructions on running different examples here ? Your instructions above do not work as I get the following error.

root@267c26bd517e:/mofem_build/um# cd /mofem_build/um/build/basic_finite_elements/elasticity 
bash: cd: /mofem_build/um/build/basic_finite_elements/elasticity: No such file or directory

• You should also update the tags in Docker hub for likask/mofem_build so that users do not have to build the entire stack to run examples or to test new problems based on MoFEM. The test process can additionally be made simpler if we can pull the container from the hub with prebuilt dependencies.

[likask]

@vijaysm I apologise for the late response, I am on annual break at the moment.

• If you let me know what is a problem on Mac OS X, I can fix it. I running docker with MoFME on Mac OS X.

• To run example pleas see link below. Can you make an issue on the bitbucket, my colleagues will pick this and try to guide you through examples.

@vijaysm Look here link

[vijaysm]

Thanks @likask. I will create an issue on the Bitbucket page to raise my problems. FWIW, I built the Docker image on Ubuntu, but the instructions in your link did not help with running examples. You can see the error message above (folder does not exist). Perhaps there is a step missing and that is why I was enquiring about a better guide to running the examples.

[likask]

@vijaysm It took me some time to push the docker container, poor internet where I am at the moment. You will find all details on docker installation.

MoFEM has a structure that core functionality is separated from the particular implementation of finite element cases. That separation has many advantages; we can make implementation modular, keep particular implementations of the finite element on separate repositories, or make part of the code private. That has a reflection in a docker container since the code is modular, user can add functionality while building users modules. So compilation in container is in two stages, core and users modules stage. I made container with precomiled code you can pull it as follows

docker pull likask/mofem_build_core:develop

Next

docker run --name mofem_build mofem_build
This command compiles users modules and runs tests. However, results of compilation are not part of the container but are stored in the volume. Several docker containers can share volume, by the option, --volumes-from mofem_build, and use it as space where data can be easily exchanged.

Now you can run examples.

docker run --rm=true -it --volumes-from mofem_build -v $HOME:$HOME -e HOSTHOME=$HOME likask/mofem_build_core:develop /bin/bash

We have updated all readme files, and follow command line there, so you can go to any directory in /mofem_build/um/basic_finite_element. Before run test compile code, and run the example, for example

cd /mofem_build/um/basic_finite_elements/elasticity && \
make 

mpirun -np 2 ./elasticity -my_file LShape.h5m -ksp_type gmres -pc_type lu -pc_factor_mat_solver_package mumps -ksp_monitor -my_order 2

mbconvert out.h5m out.vtk
cp out.h5m $HOSTHOME/Downloads/

In container you will seer error.

[2761d885210d:00054] Read -1, expected 18240, errno = 1
[2761d885210d:00054] Read -1, expected 18240, errno = 1
[2761d885210d:00053] Read -1, expected 11280, errno = 1

You can ignor that openmpi message, or to fix it, set

export OMPI_MCA_btl_vader_single_copy_mechanism=none

[jedbrown]

Welcome to the party, @chennachaos. :tada: There is a description of the process and a checklist above for you. Please let me know if you have questions.

[chennachaos]

Thank you for inviting me for the review.
I get the following message when I click on the link to accept the invitation.

Sorry, we couldn't find that repository invitation. It is possible that the invitation was revoked or that you are not logged into the invited account.

[jedbrown]

@chennachaos Are you able to check boxes in your review checklist above? That and being able to comment here are all that is needed.

[chennachaos]

No, I can't check any of the boxes in the review checklist under my account. Are there any settings I need to change?

[jedbrown]

@whedon add @chennachaos as reviewer

[whedon]

OK, @chennachaos is now a reviewer

[jedbrown]

@chennachaos Can you accept now?

[chennachaos]

Received the invitation now and accepted it. Can check the boxes now.
Thank you @jedbrown.

[chennachaos]

General checks:

Repository: Need to correct the url. This issue has already been raised by other reviewers.
License: Yes, LICENSE file with the required contents exist in the repository.
Version: This software is hosted on BitBucket but not GitHub. Need to correct this in the review checklist. The version available at http://mofem.eng.gla.ac.uk is 0.8.23. If the software has been updated since its submission to the journal, then the review checklist needs to be updated.
Authorship: Yes, the submitting author @likask has made significant contributions to the software. The full list of authors in the paper seems appropriate.

[jedbrown]

@chennachaos Our bot, Whedon, doesn't currently know how to propagate changes (in this case, to the repository) through the checklist. I just fixed it manually to avoid further confusion. It's also fine that the repository is on Bitbucket.

[chennachaos]

Software paper
Authors: Yes, the paper includes a list of authors and their affiliations.

A statement of need: The authors clearly state the motivation for incorporating the new techniques and technologies for tackling a wide range of challenging problems in computational engineering. The authors also provide examples that demonstrate the class of problems the library can solve. The target audience for the proposed library and how the audience can benefit from the library are also highlighted.

References: The list of references needs to be expanded. The authors should consider adding some important references used for the examples presented in Figure 4.

[likask]

@chennachaos We put in the text key reference, however for problems like magnetostatics we have no publication as such. However, you can reproduce quickly figure by running example in users modules, see for instance build/basic_finite_elements/magnetostatic/README. Key papers are included in code bibliography bibliography and through Zenodo library Zenodo available from the code web page. We attempt to put only references necessary for the justification of code development, whereas examples in Figure 4, can be reproduced by running the code.

[chennachaos]

Fair enough, @likask. Thank you.

[chennachaos]

I have been looking at the documentation. I think that the documentation is quite exhaustive. My main concern with the documentation is in the way the examples are presented. I am yet to test the installation, the examples and the test; I will do this in the coming days. But before that, I have a few comments on the documentation which the authors might want to take into account. The only intention behind my comments is to make the library as user-friendly to the new users as possible. I hope the authors find them useful.

A statement of need: The statement on motivation is obscured in the features page (http://mofem.eng.gla.ac.uk/mofem/html/motivation.html). The authors should consider moving this to the About page of the documentation so that the reader can easily find out what MoFEM library is. The authors can then redirect the reader to features page for additional details on the capabilities of the library.

Example usage: Documentation includes a number of examples that explain the usage of the library. The list of examples for the interested developers is also quite comprehensive.

To improve the user-friendliness, the authors should reconsider the getting started examples by taking the following comments into account.

• The first getting started example straight away presents problems on elastodynamics. This is quite a demanding example to be followed by a new user. The authors should consider increasing the level of difficulty step by step, for example, starting with the linear elastostatic example followed by a nonlinear elastostatics example and then present elastodynamic examples.

• The example Nonlinear Elasticity presents two problems, that too without any details on the description of the problem. Every example should include

  • a figure depicting the geometry along with the dimensions, and the locations of boundary and loading conditions clearly marked
  • details of how the load varies, if the load is not constant
  • a plot of the sample mesh used
  • a list of material models and parameters
  • the time integration scheme, the time integration parameters and the time step used, for unsteady problems
  • a plot of the result showing some field variable along with a suitable legend for the field variable, a colorbar and limits on the colorbar (to serve as a reference for the user)
  • a graph showing the variation of a quantity of interest, if necessary (to serve as a reference for the user)

  The authors have already done a great job in this respect for the Plasticity and Layered Gel Problem examples. If they follow the same procedure for the other examples then it will improve the presentation of examples quite significantly.




• The Plasticity example also presents two problems. This can be quite confusing to the user. For the sake of clarity, one example should not present more than one problem.




• Displaying the contents of the entire mesh file unnecessarily lengthens the content of the example. The authors can simply provide the link to the downloadable mesh file.




• There is no mention of what Cubit is and what Cubit journal files are. Users not familiar with CUBIT will find this hard to follow.




• While the ability to run the examples in parallel is commendable, all the examples or at least those aimed at introducing the functionality to the users should provide execution commands with the serial code.




• The number of input arguments to the program are too many; this is an avenue for mistakes, especially if the users are not familiar with PETSc, and even more so for users not familiar with the command-line. For the purpose of demonstration, the example programs should be executed with as many default options as possible, preferably without any PETSc arguments.




• The MoFEM-specific input arguments -my_output_prt, -my_max_post_proc_ref_level, -my_disp_order, -default_material etc. should be described in a documented list. Although these options are described in the examples, a centralised list of options would be helpful for the interested readers in exploring additional options.

Functionality documentation: The functionality of the software is well documented in the form of features, tutorial and examples on both the usage and source code design and modules.

Community guidelines: Guidelines for contributing to the software, reporting bugs and seeking support are in place. The authors might consider merging the Guidelines for bug reporting page, Q&A tab, Bibliography and other similar pages into Help tab.

[likask]

@chennachaos Thanks, that is very useful. We will break down on tasks and start to work on this. We will begin to remove long command lines.

link to isses.

[vijaysm]

@likask I was able to go through with the installation with your new instructions. Thanks.

However, when running the examples, the input meshes are actually in the Docker volume containing the user-module sources and not in the container with the build. So please update the workflow for running examples, or the instructions here [1] that state:

mpirun -np 2 ./elasticity -my_file LShape.h5m -ksp_type gmres -pc_type lu -pc_factor_mat_solver_package mumps -ksp_monitor -my_order 2

LShape.h5m is only available from the location /mofem/users_modules/basic_finite_elements/elasticity/LShape.h5m and not /mofem_build/um/basic_finite_elements/elasticity. Let me know if I misunderstood your instructions here.

[1] http://mofem.eng.gla.ac.uk/mofem/html/install_docker.html

[vijaysm]

Additionally, I also want to point out that latest versions of VisIt can natively read MOAB h5m files for visualization and you do not need to perform a mbconvert operation. However, if you want to use other tools like ParaView (there is a MOAB plugin you can compile for this as well), you will want a conversion to VTK.

[likask]

Thanks @vijaysm. If you repeat exactly that sequence

docker pull likask/mofem_build_core:develop
docker run --name mofem_build likask/mofem_build_core:develop
docker run --rm=true -it --volumes-from mofem_build -v $HOME:$HOME -e HOSTHOME=$HOME likask/mofem_build_core:develop /bin/bash

all files necessary to run code should be in build and install directories. That should be fixed now, however, if you pull from the master branch is still a bug. We will be making a bigger release soon with this fix included. We work as well on a suggestion by @chennachaos to move long parameters from the command line tp PETSc param file.

Very good point with VisIt, thanks for this. I have to play with it a bit. It is a good visualisation code. We can have the reader to ParaView, but a compilation of it is a nightmare.

[kthyng]

Hi all! Where are we at in the review process of this submission? @likask are you working on something on your end?

[likask]

@kthyng Yes, we made changes suggested by @chennachaos, and going to have a new release. I am happy to give any possible help in case of the problems with running code and installation.
BTW We continuously develop and refactor code.

[kthyng]

@likask Sounds good. What is the next step then? Should the reviewers @tjhei, @chrisrichardson, @Kevin-Mattheus-Moerman, @vijaysm, @chennachaos wait for your new release?

[likask]

It looks that @tjhei finished his work a long time ago.

I do think that is a need to wait for a new release. In the case of @chrisrichardson, @Kevin-Mattheus-Moerman, @vijaysm, @chennachaos probably time is the main problem. I can make quickly container with a particular update only if needed. From my side, I can promise to be swift as possible in answering questions and solve the problems.

[chennachaos]

Hi @likask. If you can push the updates, then I will go through the rest of the steps in the review process and complete the review by the end of next week.

[likask]

@chennachaos I will make precompiled docker version v0.9.0 for you by Monday.

[likask]

Hello @kthyng @chrisrichardson, @Kevin-Mattheus-Moerman, @vijaysm, @chennachaos

The easiest, precompiled installation of MoFEM is with docker container. This is new release v0.9.0, which you can run and try executing following commends. For example reaction-diffusion equation (reaction_diffusion_tutorial). You can see more tutorials on MoFEM webpages and every directory has a README file with an example of how to run code.

1. Install docker link
2. Pull container docker pull likask/mofem_build_with_um:v0.9.0
3. Runn container docker run -it -v $HOME:$HOME likask/mofem_build_with_um:v0.9.0

When you are in the running container

cd um/basic_finite_elements/reaction_diffusion_equation
cat README
NBPROC=6 && ../../tools/mofem_part -my_file mesh.cub -output_file mesh.h5m -my_nparts $NBPROC -dim 2 -adj_dim 1
mpirun -np $NBPROC ./reaction_diffusion_equation -file_name mesh.h5m

Note, other types of installation form source are available on the MoFEM web pages.

Please feel free to ask for help.

Good luck, and thanks for the effort.
Lukasz

[chennachaos]

Hi @likask, I tried working with the docker installation you recently posted.
I could not pull the files without using sudo. I got the following message if I didn't use sudo.

Warning: failed to get default registry endpoint from daemon (Got permission denied while trying to connect to the Docker daemon socket at unix:///var/run/docker.sock: Get http://%2Fvar%2Frun%2Fdocker.sock/v1.26/info: dial unix /var/run/docker.sock: connect: permission denied). Using system default: https://index.docker.io/v1/
Got permission denied while trying to connect to the Docker daemon socket at unix:///var/run/docker.sock: Post http://%2Fvar%2Frun%2Fdocker.sock/v1.26/images/create?fromImage=likask%2Fmofem_build_with_um&tag=v0.9.0: dial unix /var/run/docker.sock: connect: permission denied

I am new to docker. So, I don't know why I needed to do that.

Once I downloaded the files, I followed the steps you listed for the reaction-diffusion example. I could not run it using 6 processors. So, I changed the number of processors to 2 and rerun the program.

partition step: This is the output I got.

root@15734ca0f032:/mofem_build/um/basic_finite_elements/reaction_diffusion_equation# NBPROC=2 && ../../tools/mofem_part -my_file mesh.cub -output_file mesh.h5m -my_nparts $NBPROC -dim 2 -adj_dim 1
Element ids are not contiguous!
read cubit meshset 12682136550675316746 type BLOCKSET msId 1 block header:  blockCol = 4294967295 blockMat = 0 blockDimension = 2
MoFEM version 0.9.0 (MOAB 5.0.1 Petsc Release Version 3.7.7, unknown ) 
git commit id GITDIR-NOTFOUND
meshset 12682136550675316746 type BLOCKSET msId 1 block header:  blockCol = 4294967295 blockMat = 0 blockDimension = 2
Finite elements partition in problem: row lower 0 row upper 10024 nb elems 10024 ( 10024 )
Partition mesh <- Done

It would be a good idea to investigate and fix the message git commit id GITDIR-NOTFOUND.

Analysis step: I got many error messages. The output at the end of the execution is as follows.

[15734ca0f032:00103] Read -1, expected 6184, errno = 1
[15734ca0f032:00104] Read -1, expected 155128, errno = 1
[15734ca0f032:00103] Read -1, expected 147480, errno = 1
300 TS dt 0.1 time 30.

real    3m14.366s
user    6m24.922s
sys 0m1.592s

But these error messages do not seem to have any effect on the results. Nonetheless, the issue should be fixed.

Post-processing step:
I managed to create the *.vtk files and visualised them in Paraview. The attached figure is the solution in the 46th vtk file.

[likask]

@chennachaos This is an issue with docker and openmpi. Here is the solution
openmpi error solution

git commit id GITDIR-NOTFOUND. This is because I install the tarball, instead of git repo, to save a space a bit.

You can look here, for direct installation in Spack. We recently updated spack,
spack install but I think docker is the quickest way for you, with minimal footprint on your system.

Regards,
Lukasz

[chennachaos]

Thank you for your prompt response, @likask
I have installed MoFEM using spack. I must say that it was not as straightforward as I would have liked.

The Spack setup at http://mofem.eng.gla.ac.uk/mofem/html/install_spack.html section can be improved.

• The command curl -s -L https://bitbucket.org/likask/mofem-cephas/downloads/mirror_v0.9.0.tar.gz \ | tar xzC $PWD/mofem_mirror --strip 1
  failed to execute. It was stuck without doing anything. I don't know the reason behind this. I killed it and installed the library by skipping this step.

• Since it is possible to install the library by downloading files from online on the fly, the optional commands that are needed for off-line installation can be moved to the end as a note or sub-section with appropriate heading.

• I could not test the elasticity module with MPI. I got a couple of errors related to PMIX when I executed the command. [surface:21622] PMIX ERROR: UNPACK-PAST-END in file unpack.c at line 206. I think the issue is the incompatible MPI installations on my laptop. However, I could test the example as a serial run.
  Do you have any inputs on fixing this issue with PMIX?

[likask]

@chennachaos

1. Yes, you do not have to add mirror. However dependent packages often change locations, and sometimes servers are down. This is more reliable way of installation. Mirror is large file, ~700 MB, you have to a bit patient.

2. Mirror allows installation on secure servers with restricted internet access.

3. You can load openmpi and moab from spack.

spack load openmpi

That should fix problem.

Lukasz

[chennachaos]

spack load openmpi command fixed the issue with PMIX. Thank you.

I confirm that I can run the test case in parallel.

[chennachaos]

@jedbrown I have finished my review for the MoFEM software library.
Lukasz @likask has been very responsive to my queries.

MoFEM is a very powerful library for FEA. It is well designed and documented. I have verified its installation, functionality and examples. Of course, there is room for improvement in the documentation for which I have already identified few places in my earlier post. I am confident that it will be improved in the due course since the developers and contributors of MoFEM are actively working.

i am happy with the current state of MoFEM. I recommend it for publication in JOSS.

Thank you for the opportunity.

[likask]

@chennachaos Thank you.

@vijaysm @chrisrichardson, @Kevin-Mattheus-Moerman, can you have a go.

See this link as a quick and easy way of installation.

[vijaysm]

Thanks @likask I am almost done with the repository review and should be able to get the other items in my list done by end of this week. I will let you know my list of comments soon.

[likask]

@vijaysm Can I help you with something?

[vijaysm]

@lukasz I apologize about the delay. I'm on vacation and don't have my
laptop (and review comments) with me. I was able to get the stack built
couple of months back, though the process has become simpler since. I
wanted to verify running some complex problems with MoFEM but haven't
gotten around to that yet. This is the primary reason for my tardy review.
I get back to work on Nov 18 and will make it a priority to update my
review. Thanks for the quick responses.

On Sat., Nov. 9, 2019, 06:19 Lukasz, [e-mail] wrote:

@vijaysm https://github.com/vijaysm Can I help you with something?

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/openjournals/joss-reviews/issues/1441?email_source=notifications&email_token=AACVEPNOEEVH6VXTX5IPQ73QS2META5CNFSM4HL4D2A2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEDUDX2A#issuecomment-552090600,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AACVEPNMZAP5FH7PVHZCUTDQS2METANCNFSM4HL4D2AQ
.

[danielskatz]

👋 @vijaysm - just noting that it's now a couple of weeks after Nov 18

[vijaysm]

I should be able to finish the review by Sunday. Thanks for the reminder. @danielskatz

[vijaysm]

@likask I was able to build the MoFEM examples and executed several of them. Some comments below after my experiments.

1. Executing examples under (container)likask/mofem_build_with_um and (folder) /mofem_build/um/basic_finite_elements

• The parallel run of the example prints many errors like below, per every timestep of the calculation. These errors should be better handled and/or documented in case the user input is incorrect. This was already pointed out by @chennachaos above.
  Read -1, expected 107328, errno = 1

• I also wanted to note that the serial run of the program finished as expected and does not produce the above errors.

1. The documentation for some of the examples provide significant details about the Cubit setup. It perhaps takes the focus away from the actual example setup and execution related documentation. For instance, the Computational Homogenization page (http://mofem.eng.gla.ac.uk/mofem/html/comp_homo.html) can be simplified without details about Cubit, but instead about the model setup and code snippets related to that.

2. There is a documentation page about Gmsh but I could only find one ".msh" file for user input in the user module repository. Adding more ".msh" files as alternative input will emphasize flexibility of MoFEM to take other input formats.

3. You should add a separate page about PostProcessing to explain how to convert h5m files to vtk for visualization. It is currently unclear to me whether this is done on a problem-dependent basis, because there really should be a single tool to do the conversion.

4. The links to MOAB should point to http://ftp.mcs.anl.gov/pub/fathom/moab-docs/index.html instead of the outdated https://www.mcs.anl.gov/~fathom/moab-docs/index.html.

5. I had several issues related to installing the MoFEM stack with Spack. But I do not want to delay the review process on account of that. I am satisfied with the accessibility to the code and compilation of the examples through the provided Docker containers.

General suggestions

1. For running examples, I would advise you to use more standard input mesh formats. I wanted to point out that the CUB file reader in MOAB is built for specific versions of Cubit outputs and we cannot guarantee that this will continue to be supported if the developers decide to change the underlying format. Additionally, using Cubit outside of US institutions may have licensing implications that you need to be aware, as your software gets broader usage. This should be stated somewhere as part of README in the repository.

2. It would be useful to distribute the visualization tool (Paraview or VisIt) as part of the Docker container that has the user modules (likask/mofem_build_with_um). My suggestion is to have a VisIt installation with MOAB native h5m file support so that you do not have to go through the additional conversion process to vtk to visualize data.

@jedbrown @danielskatz I am satisfied with the current status of the MoFEM software and the documentation. I have completed my review process and recommend the paper be published to JOSS after my comments above are addressed. Thanks.

[likask]

Thanks @vijaysm

1. Docker MPI error is fixed. I've updated docker build file to eliminate that problem. How to handle that error is as well described in FAQs.
2. You right. Cubit is a tool that we used in the past, now we moving toward Slome and other free & open meshes. The Computational Homogenization example is not mange by us directly, it is a user module which is not part of the MoFEM library.
3. You are correct. That flexibly comes with MOAB library.
4. That will be done with the next release. Also, we recently write convert.py tool to convert a large number of files (usually from nonlinear time-dependent problems) in parallel. It will be part of the next release version.
5. I will do that ASP.
6. We constantly working on improving installation. It is a bit moving target.

Thanks again for spending time on this.

Kind regards,
Lukasz

[likask]

@vijaysm We starting work on postprocessing documentation (and other suggestions). Link to MoAB documentation is fixed.

@jedbrown what about two remaining reviewers?

[jedbrown]

@chrisrichardson @Kevin-Mattheus-Moerman :wave: Could you please have a look at the remaining items on your checklist and let us know what requests you may have in order to check those?

[likask]

@chrisrichardson @Kevin-Mattheus-Moerman Do you have any New Year commitments?

@jedbrown

[chrisrichardson]

I'm not quite sure where to find the release number (v0.8.22) - currently seems to be 0.9.0?

[chrisrichardson]

I also got a fail when running ctest:

99% tests passed, 1 tests failed out of 158

Total Test time (real) =  54.66 sec

The following tests FAILED:
    104 - dm_partitioned_no_field_3parts (Failed)
Performing coverage
 Cannot find any coverage files. Ignoring Coverage request.
Submit files (using http)
   Using HTTP submit method
   Drop site:http://cdash.eng.gla.ac.uk/cdash/submit.php?project=Cephas
   Uploaded: /home/chris/mofem_installation/lib/Testing/20200107-1124/Build.xml
   Uploaded: /home/chris/mofem_installation/lib/Testing/20200107-1124/Configure.xml
   Uploaded: /home/chris/mofem_installation/lib/Testing/20200107-1124/Test.xml
   Submission successful
Errors while running CTest

[likask]

Hello @chrisrichardson, how you install code? If you have source code you can checkout to version 0.8.22

git checkout tags/v0.8.22

I see that you install all for ubuntu with own compiled libraries. I see your test error, as well, I investigate this.

[likask]

@chrisrichardson We continuously develop code, will not do harm and you are OK with this, if you could work with v0.9.0, in fact, we have another version in the pipeline.

[likask]

@chrisrichardson About the error,

In webpage about Ubuntu type installation, all is fixed to Petsc version 3.8.4 which comes with MoAB 5.0.0. If I remember we have some problem in past with nondeterministic behaviour of MoAB since entity handlers were numbered based on the pointers (locations in the memory). So to a different memory, allocations would lead to two different numbers of entities (e.g. nodes). That is fixed with newer versions of MoAB.

I see your error here
CDashTest

This is your version which you run at the moment,
MoFEM version 0.9.0 (MOAB 5.0.0 Petsc Release Version 3.8.4, unknown )

You can bump version of PETSc to [email protected].*, install all with Spack. Form the other hand, this error should not affect examples (except the crack propagation module) so you can ignore them for now.

I will bump Petsc version on MoFEM webpages to avoid such problems in the future.

[Kevin-Mattheus-Moerman]

@jedbrown I've ticked those last boxes and hereby recommend acceptance in JOSS. My sincere apologies for the delay in my review.

@likask et al. great work developing MoFEM, excited to see where this project is going.

[likask]

Thanks @Kevin-Mattheus-Moerman
It is a work in progress.

[chrisrichardson]

@jedbrown - I've ticked off the other boxes. I don't think the minor issues which I had are very significant.

[jedbrown]

@whedon generate pdf

[whedon]

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

[jedbrown]

Thanks for your patience. I have created a PR (https://bitbucket.org/likask/mofem-cephas/pull-requests/1114/joss-paper-copy-editing-and-bib-reference/diff) with some copy edits. I also have the following comments relating to the paper that may take some of your discretion to address.

• MoFEM is developed to provide free and open source finite element codes: I think this wording could be improved to label it a software library or framework; "codes" is nebulous and often not associated with composability and extensibility, or with library workflows.
• I proposed a switch to in-text citation for the hp paper, but you may want to reword if you only mean it to be a representative paper. (The 1986 paper is a more standard citation for hp methods in particular.)
• If MoFEM does not have fast matrix-free evaluation (a la spectral elements), then maybe this discussion of multigrid should be shortened. I think the evidence is unclear at best that hierarchical bases are better for unstructured MG (interpolation and restriction are rarely bottlenecks); some of the fastest implementations I'm aware of are not hierarchical. Kronbichler and Ljungkvist (2019) is a recent study.
• I would drop the quotes around terms like "mixed" and "ecosystem".
• A diverse user and contributor base helps to justify sustained funding, but I think it's risky and gives the wrong impression to take it for granted.
• In Examples and Capabilities, I would remove the funding details (such as grant numbers) and limit to citation of scholarly work. Funding details belong in Acknowledgments (looks to already be there).
• I pretty much always see "basis" (singular) and "bases" (plural). Do you identify with a community that deliberately uses "base" instead of "basis", or would you be willing to use "basis"?
• CHKERR appears to be a macro that is not defined, and would yield invalid code without an unusual definition. Could you drop it or explain it?
• While your paper is long by JOSS standards, it doesn't directly discuss other finite element software. We usually ask for brief comparison with related work; in this space, some popular packages include Deal.II, MFEM, libMesh, FEniCS, and FreeFEM++.

[likask]

Thank you @jedbrown, that is very appreciated.

• Do you mean paper from 1996?

(1996) Approximation properties of the h-p version of the finite element method. Computer Methods in Applied Mechanics and Engineering 133:3-4, 319-346.

• You right, up to know we have not done proper MG with the fully matrix-free approach. In fact, we using MoFEM implementation of DM which called is called MG implemented in PETSc. Typically for assembling problem on the last level, and then exploit hierarchical basis to make matrix-vector multiplication on lower levels, and than on coarse level use sub-matrix when we like to have direct solver on the bottom. At the end is tricky to have a fully matrix-free approach which nonlinear material, large strains or plasticity, in particular when historic variables are involved. I will rewrite that paragraph, make it shorter without MG.

• You right CHKERR is a macro, under the bonnet is an operator to specialised template class with handle errors.

#define CHKERR MoFEM::ErrorCheckerCode<__LINE__>() <<

Is omnipresent in the code however is not essential. Ok, I will remove it from paper.

We did it like that, to handle errors from PETSc, MOAB, and MoFEM consistently, at very end PETSc error handler is called with an appropriate message. Add on is that clang-format do not break lines; for example

ierr = VecSetValues(...) ; 
CHKERR(ierr);

• MoFEM does more or less what Deal.II, MFEM, libMesh, FEniCS, and FreeFEM++, with some strengths in one area, and weaknesses in other. I will add paragraphs as you suggest for completeness, or do you expect some detailed comparison?

• Agreed with other suggestions.

[jedbrown]

I often see citations to https://link.springer.com/article/10.1007/BF00298636 or the Babuska and Suri SIAM Review from 1994.

A detailed comparison is not needed, but place then in context. One paragraph in total would be fine IMO.

[likask]

@whedon generate pdf

[whedon]

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

[likask]

@jedbrown Pull request with our corrections is here.

[likask]

@whedon generate pdf

[whedon]

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

[jedbrown]

@whedon check references

[whedon]

Reference check summary:

OK DOIs

- 10.5281/zenodo.789521 is OK
- 10.1515/jnma-2019-0064 is OK
- 10.11578/dc.20171025.1248 is OK
- 10.11578/dc.20171025.1248 is OK
- 10.11588/ans.2015.100.20553 is OK

MISSING DOIs

- https://doi.org/10.1515/jnum-2012-0013 may be missing for title: New development in FreeFem++

INVALID DOIs

- https://doi.org/10.2172/970174 is INVALID because of 'https://doi.org/' prefix
- https://doi.org/10.1002/nme.847 is INVALID because of 'https://doi.org/' prefix
- https://doi.org/10.1137/11082539x is INVALID because of 'https://doi.org/' prefix
- https://doi.org/10.1016/j.camwa.2015.04.027 is INVALID because of 'https://doi.org/' prefix
- https://doi.org/10.1016/j.cma.2017.06.001 is INVALID because of 'https://doi.org/' prefix
- https://doi.org/10.1093/imanum/drq047 is INVALID because of 'https://doi.org/' prefix

[likask]

@whedon check references

[whedon]

Reference check summary:

OK DOIs

- 10.5281/zenodo.789521 is OK
- 10.1515/jnma-2019-0064 is OK
- 10.11578/dc.20171025.1248 is OK
- 10.11578/dc.20171025.1248 is OK
- 10.11588/ans.2015.100.20553 is OK

MISSING DOIs

- https://doi.org/10.1515/jnum-2012-0013 may be missing for title: New development in FreeFem++

INVALID DOIs

- https://doi.org/10.2172/970174 is INVALID because of 'https://doi.org/' prefix
- https://doi.org/10.1002/nme.847 is INVALID because of 'https://doi.org/' prefix
- https://doi.org/10.1137/11082539x is INVALID because of 'https://doi.org/' prefix
- https://doi.org/10.1016/j.camwa.2015.04.027 is INVALID because of 'https://doi.org/' prefix
- https://doi.org/10.1016/j.cma.2017.06.001 is INVALID because of 'https://doi.org/' prefix
- https://doi.org/10.1093/imanum/drq047 is INVALID because of 'https://doi.org/' prefix

[likask]

@whedon generate pdf

[whedon]

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

[likask]

@whedon check references

[whedon]

Reference check summary:

OK DOIs

- 10.2172/970174 is OK
- 10.1002/nme.847 is OK
- 10.1137/11082539x is OK
- 10.1016/j.camwa.2015.04.027 is OK
- 10.1016/j.cma.2017.06.001 is OK
- 10.5281/zenodo.789521 is OK
- 10.1093/imanum/drq047 is OK
- 10.1515/jnma-2019-0064 is OK
- 10.11578/dc.20171025.1248 is OK
- 10.11578/dc.20171025.1248 is OK
- 10.11588/ans.2015.100.20553 is OK
- 10.1515/jnum-2012-0013 is OK

MISSING DOIs

- None

INVALID DOIs

- None

[jedbrown]

I think these three are missing.

https://doi.org/10.1007/BF00298636
https://doi.org/10.1007/s00366-006-0049-3
https://doi.org/10.1016/j.compositesb.2019.03.027

[likask]

@whedon generate pdf

[whedon]

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

[likask]

@whedon check references

[whedon]

Reference check summary:

OK DOIs

- 10.2172/970174 is OK
- 10.1002/nme.847 is OK
- 10.1137/11082539x is OK
- 10.1016/j.camwa.2015.04.027 is OK
- 10.1016/j.cma.2017.06.001 is OK
- 10.1016/j.compositesb.2019.03.027 is OK
- 10.1007/BF00298636 is OK
- 10.5281/zenodo.789521 is OK
- 10.1093/imanum/drq047 is OK
- 10.1515/jnma-2019-0064 is OK
- 10.11578/dc.20171025.1248 is OK
- 10.11578/dc.20171025.1248 is OK
- 10.1007/s00366-006-0049-3 is OK
- 10.11588/ans.2015.100.20553 is OK
- 10.1515/jnum-2012-0013 is OK

MISSING DOIs

- None

INVALID DOIs

- None

[jedbrown]

Great! Please tag a release (may be minor or subminor), archive your repository on Zenodo or similar, and report the DOI back here.

[likask]

@jedbrown

10.5281/zenodo.3627253

http://doi.org/10.5281/zenodo.3627253

[likask]

@jedbrown Master branch is tagged v0.9.0.

[jedbrown]

The archive says it's v0.9.0, but you just tagged v0.9.1 (on develop from last month)?

[jedbrown]

$ git pull --tags 
From bitbucket:likask/mofem-cephas
 ! [rejected]            v0.9.0     -> v0.9.0  (would clobber existing tag)

Probably shouldn't do that. Best to make a new tag.

[likask]

Yes, it was stupid from my side,

git fetch --prune --prune-tags

should fix the problem.

The archive is uploaded for version v0.9.0, it is tarball from the master branch. We will yet to merge develop branch with the master when all is ready.

[likask]

@jedbrown You can note that zipped file in Zenode has in name "0a18bd77be0a" that is commit SHA for current master.

[jedbrown]

It doesn't:

$ git fetch --tags  --prune-tags 
From bitbucket:likask/mofem-cephas
 ! [rejected]            v0.9.0     -> v0.9.0  (would clobber existing tag)

$ git fetch --prune --prune-tags 
From bitbucket:likask/mofem-cephas
 - [deleted]             (none)     -> origin/hoang/mofem_paper
 - [deleted]             (none)     -> origin/hoang/webpage
 - [deleted]             (none)     -> origin/lukasz/adding_to_tools
 - [deleted]             (none)     -> origin/lukasz/field_evaluator
 - [deleted]             (none)     -> origin/lukasz/fixing_install
 - [deleted]             (none)     -> origin/lukasz/fixing_install_scripts
 - [deleted]             (none)     -> origin/lukasz/format_code_and_error_handling
 - [deleted]             (none)     -> origin/lukasz/refactor_code
 - [deleted]             (none)     -> origin/lukasz/refactor_users_operatorrs
 ! [rejected]            v0.9.0     -> v0.9.0  (would clobber existing tag)

I'm entirely capable of fixing this situation on my end, but still question whether this is really what you want to do to all your users and co-developers who may have a clone or fork of the repository, and to anyone who may have referenced v0.9.0 as it was released in October.

[likask]

OK

I put tag v0.9.0 on the old commit, where it was, set new tag v0.9.0-joss on top of the master branch.

A mess which I created, should be unnoticed by others.

[jedbrown]

@whedon set 10.5281/zenodo.3627253 as archive

[whedon]

OK. 10.5281/zenodo.3627253 is the archive.

[jedbrown]

@likask Could you adjust the Zenodo metadata to match v0.9.0-joss?

[likask]

It is now.

[jedbrown]

@whedon set v0.9.0-joss as version

[whedon]

OK. v0.9.0-joss is the version.

[jedbrown]

@whedon accept

[whedon]

Attempting dry run of processing paper acceptance...

[whedon]

Reference check summary:

OK DOIs

- 10.2172/970174 is OK
- 10.1002/nme.847 is OK
- 10.1137/11082539x is OK
- 10.1016/j.camwa.2015.04.027 is OK
- 10.1016/j.cma.2017.06.001 is OK
- 10.1016/j.compositesb.2019.03.027 is OK
- 10.1007/BF00298636 is OK
- 10.5281/zenodo.789521 is OK
- 10.1093/imanum/drq047 is OK
- 10.1515/jnma-2019-0064 is OK
- 10.11578/dc.20171025.1248 is OK
- 10.11578/dc.20171025.1248 is OK
- 10.1007/s00366-006-0049-3 is OK
- 10.11588/ans.2015.100.20553 is OK
- 10.1515/jnum-2012-0013 is OK

MISSING DOIs

- None

INVALID DOIs

- None

[whedon]

Check final proof :point_right: https://github.com/openjournals/joss-papers/pull/1247

If the paper PDF and Crossref deposit XML look good in https://github.com/openjournals/joss-papers/pull/1247, then you can now move forward with accepting the submission by compiling again with the flag deposit=true e.g.
@whedon accept deposit=true

[jedbrown]

@openjournals/joss-eics :wave: We're ready for you.

[likask]

Thank you all @jedbrown @tjhei @vijaysm @chennachaos @Kevin-Mattheus-Moerman @chrisrichardson

Time, help and patience. Experience with the open journal and open review is great.

[labarba]

@whedon accept

[whedon]

Attempting dry run of processing paper acceptance...

[whedon]

Reference check summary:

OK DOIs

- 10.2172/970174 is OK
- 10.1002/nme.847 is OK
- 10.1137/11082539x is OK
- 10.1016/j.camwa.2015.04.027 is OK
- 10.1016/j.cma.2017.06.001 is OK
- 10.1016/j.compositesb.2019.03.027 is OK
- 10.1007/BF00298636 is OK
- 10.5281/zenodo.789521 is OK
- 10.1093/imanum/drq047 is OK
- 10.1515/jnma-2019-0064 is OK
- 10.11578/dc.20171025.1248 is OK
- 10.11578/dc.20171025.1248 is OK
- 10.1007/s00366-006-0049-3 is OK
- 10.11588/ans.2015.100.20553 is OK
- 10.1515/jnum-2012-0013 is OK

MISSING DOIs

- None

INVALID DOIs

- None

[whedon]

Check final proof :point_right: https://github.com/openjournals/joss-papers/pull/1248

If the paper PDF and Crossref deposit XML look good in https://github.com/openjournals/joss-papers/pull/1248, then you can now move forward with accepting the submission by compiling again with the flag deposit=true e.g.
@whedon accept deposit=true

[labarba]

@whedon accept deposit=true

[whedon]

Doing it live! Attempting automated processing of paper acceptance...

[whedon]

🐦🐦🐦 👉 Tweet for this paper 👈 🐦🐦🐦

[whedon]

🚨🚨🚨 THIS IS NOT A DRILL, YOU HAVE JUST ACCEPTED A PAPER INTO JOSS! 🚨🚨🚨

Here's what you must now do:

1. Check final PDF and Crossref metadata that was deposited :point_right: https://github.com/openjournals/joss-papers/pull/1249
2. Wait a couple of minutes to verify that the paper DOI resolves https://doi.org/10.21105/joss.01441
3. If everything looks good, then close this review issue.

4. Party like you just published a paper! 🎉🌈🦄💃👻🤘

   Any issues? notify your editorial technical team...

[labarba]

Congratulations, @likask, your JOSS paper is published! 🚀

Huge thanks to our editor, @jedbrown, and to the hard-working team of reviewers here! JOSS depends on volunteers like you, and we are grateful 🙏

[whedon]

:tada::tada::tada: Congratulations on your paper acceptance! :tada::tada::tada:

If you would like to include a link to your paper from your README use the following code snippets:

Markdown:
[![DOI](https://joss.theoj.org/papers/10.21105/joss.01441/status.svg)](https://doi.org/10.21105/joss.01441)

HTML:
<a style="border-width:0" href="https://doi.org/10.21105/joss.01441">
  <img src="https://joss.theoj.org/papers/10.21105/joss.01441/status.svg" alt="DOI badge" >
</a>

reStructuredText:
.. image:: https://joss.theoj.org/papers/10.21105/joss.01441/status.svg
   :target: https://doi.org/10.21105/joss.01441

This is how it will look in your documentation:

We need your help!

Journal of Open Source Software is a community-run journal and relies upon volunteer effort. If you'd like to support us please consider doing either one (or both) of the the following:

• Volunteering to review for us sometime in the future. You can add your name to the reviewer list here: https://joss.theoj.org/reviewer-signup.html
• Making a small donation to support our running costs here: https://numfocus.org/donate-to-joss

[likask]

@labarba @jedbrown It is possible to fix link to the repository? See the following
https://bitbucket.org/likask/mofem-cephas/src/joss/media/paper.md

An error was created on very beginning by me from misunderstanding how Weldon searching for the location of paper.md. The fix is simple, the link has to be changed to https://bitbucket.org/likask/mofem-cephas

[labarba]

Yikes.

@openjournals/dev The author notifies us of a mistake in the repository URL, post-publication. Can you help?

[arfon]

@openjournals/dev The author notifies us of a mistake in the repository URL, post-publication. Can you help?

Fixed!