[PRE REVIEW]: Space-time formulation, discretization, and computational performance studies for phase-field fracture optimal control problems: reproduction code

[editorialbot]

Submitting author: !--author-handle-->@Denis-Khimin<!--end-author-handle-- (Denis Khimin) Repository: https://github.com/tommeswick/phase_field_fracture_optimal_control Branch with paper.md (empty if default branch): Version: v 1.0.0 Editor: Pending Reviewers: Pending Managing EiC: Kevin M. Moerman

Status

Status badge code:

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

Author instructions

Thanks for submitting your paper to JOSS @Denis-Khimin. Currently, there isn't a JOSS editor assigned to your paper.

@Denis-Khimin if you have any suggestions for potential reviewers then please mention them here in this thread (without tagging them with an @). You can search the list of people that have already agreed to review and may be suitable for this submission.

Editor instructions

The JOSS submission bot @editorialbot is here to help you find and assign reviewers and start the main review. To find out what @editorialbot can do for you type:

@editorialbot commands

[editorialbot]

Hello human, I'm @editorialbot, a robot that can help you with some common editorial tasks.

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

@editorialbot commands

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

@editorialbot generate pdf

[editorialbot]

Software report:

github.com/AlDanial/cloc v 1.90  T=0.02 s (701.8 files/s, 205577.5 lines/s)
-------------------------------------------------------------------------------
Language                     files          blank        comment           code
-------------------------------------------------------------------------------
C/C++ Header                     5            431            157           1726
C++                              1             56            163            232
Markdown                         2             24              0            193
TeX                              1             14              0            164
YAML                             1              0              4             24
CMake                            1              5              9             20
-------------------------------------------------------------------------------
SUM:                            11            530            333           2359
-------------------------------------------------------------------------------

Commit count by author:

    15  Thomas Wick
    13  Denis Khimin

[editorialbot]

Reference check summary (note 'MISSING' DOIs are suggestions that need verification):

OK DOIs

- 10.11588/ans.2017.2.11815 is OK
- 10.1016/j.camwa.2020.02.022 is OK
- 10.1515/jnma-2019-0064 is OK
- 10.1007/s00466-022-02147-0 is OK

MISSING DOIs

- No DOI given, and none found for title: Past and present of variational fracture
- No DOI given, and none found for title: Phase field modelling of fracture
- 10.1016/s0022-5096(99)00028-9 may be a valid DOI for title: Numerical experiments in revisited brittle fractur...
- 10.1002/nme.2861 may be a valid DOI for title: Thermodynamically consistent phase-field models of...
- 10.1007/s00466-014-1109-y may be a valid DOI for title: A review on phase-field models of brittle fracture...
- 10.1080/10556780701228532 may be a valid DOI for title: Efficient numerical solution of parabolic optimiza...
- No DOI given, and none found for title: Optimization with PDE constraints
- No DOI given, and none found for title: Optimale Steuerung partieller Differentialgleichun...

INVALID DOIs

- https://doi.org/10.1016/j.jcp.2022.111554 is INVALID because of 'https://doi.org/' prefix
- https://doi.org/10.1515/9783110497397 is INVALID because of 'https://doi.org/' prefix
- http://dx.doi.org/10.1016/j.engfracmech.2010.08.009 is INVALID because of 'https://doi.org/' prefix

[editorialbot]

Paper file info:

📄 Wordcount for paper.md is 1058

✅ The paper includes a Statement of need section

[editorialbot]

License info:

🔴 Failed to discover a valid open source license

[editorialbot]

:point_right::page_facing_up: Download article proof :page_facing_up: View article proof on GitHub :page_facing_up: :point_left:

[editorialbot]

Five most similar historical JOSS papers:

cRacklet: a spectral boundary integral method library for interfacial rupture simulation Submitting author: @tiburoch Handling editor: @diehlpk (Active) Reviewers: @srmnitc, @kylebeggs Similarity score: 0.6964

PDLSM-FEM: Solver of Coupled Peridynamics Least Squares Minimization with Finite Element Method Submitting author: @QibangLiu Handling editor: @prashjha (Active) Reviewers: @TLCFEM, @karthikncsu, @Balaje Similarity score: 0.6847

Motorcycle: A spectral boundary-integral method for seismic cycles on multiple faults Submitting author: @sbarbot Handling editor: @jedbrown (Active) Reviewers: @mherman09, @willic3, @thehalfspace Similarity score: 0.6820

NLMech: Implementation of finite difference/meshfree discretization of nonlocal fracture models Submitting author: @diehlpk Handling editor: @Kevin-Mattheus-Moerman (Active) Reviewers: @vijaysm, @chennachaos Similarity score: 0.6820

fibergen: An introductory tool for FFT-based material homogenization Submitting author: @fospald Handling editor: @jedbrown (Active) Reviewers: @tisaac, @ctdegroot Similarity score: 0.6794

⚠️ Note to editors: If these papers look like they might be a good match, click through to the review issue for that paper and invite one or more of the authors before considering asking the reviewers of these papers to review again for JOSS.

[Kevin-Mattheus-Moerman]

@Denis-Khimin, thanks for this submission. I am the AEiC on this track and here to help process the initial steps. Unfortunately this submission is not acceptable as it stands. It appears newly created on GitHub, and contributions appear to have started in July. There is no issue/pull request history, and furthermore, the repository looks rather immature. I will proceed to reject this submission. I would welcome a future resubmission once all of the below are addressed:

• [ ] Please study the above reference check :point_up: and see if you can address any of the reported potential DOI issues. You can add/amend DOI entries in your .bib file.
• [ ] The project appears to lack an OSI approved license. Please add one as a plain LICENSE file in the main folder.
• [ ] Your project appears to lack contributing guidelines at the moment. Please work to add these and to mention/link to them in your README. You could for instance create a CONTRIBUTING.md file (see here for some examples: https://contributing.md/example/).
• [ ] The README is very short. Besides a brief description it should link to installation, first steps, documentation, testing, the license, the contributing guidelines.
• [ ] Please detail how this work (or the publication sought) differs from your recent publication: https://doi-org.nuigalway.idm.oclc.org/10.1016/j.jcp.2022.111554
• [ ] The project should feature dedicated documentation and automated testing. Both should be clearly linked to in the README as mentioned before.

Finally, since the functionality is captured by about ~2000 lines the code, the code base is rather small. This means that following a resubmission we may still need to check if this work is in scope for JOSS in terms of size/effort, i.e. to check if the work conforms to our substantial scholarly effort criteria.

[Kevin-Mattheus-Moerman]

@editorialbot reject

[editorialbot]

Paper rejected.

[Denis-Khimin]

Dear reviewer,

Thank you for your comments. We have a few questions

• Regarding your fifth remark: The code we provided offers a concrete implementation of the mathematics developed in [https://doi-org.nuigalway.idm.oclc.org/10.1016/j.jcp.2022.111554], where no implementation aspects were covered. We believed that this aligns with the intended purpose of the "reproduction code" category.

• Regarding point 7 (~2000 lines of code): We would like to clarify that the code we have submitted is a "reproduction code," which is built upon existing libraries, specifically deal.II (which consists of 1 million lines of code) and DOpElib (around 100,000 lines of code). Given this, we are unsure about the specific expectations regarding the length of our submission. As the reproduction code is intended to leverage these established libraries, it naturally results in a smaller codebase, ranging between 2,000 and 10,000 lines of code. We understand that, according to the JOSS guidelines, submissions of this nature are acceptable. However, we would appreciate any further guidance or clarification you could provide on this matter.

Best regards, Denis Khimin

[Kevin-Mattheus-Moerman]

@Denis-Khimin on your first point, regarding the paper, that sounds okay and we'll review that if needed. On the second point, indeed ~2000 LOC can be okay if the functionality is extensive enough. I do typically review submissions of that length for scope first but yes it can in principle be acceptable. So we are not too hung up on the exact number of lines of code (and what you describe makes sense in terms of being compact). Instead we tend to trigger the scope review ~ 2000 LOC. Our substantial scholarly effort criteria are mainly there to filter out <3 month effort projects.