[PRE REVIEW]: GRFsaw: A lightweight stochastic microstructure generator

[editorialbot]

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

Status

Status badge code:

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

Author instructions

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

@larsblatny if you have any suggestions for potential reviewers then please mention them here in this thread (without tagging them with an @). In addition, this list of people have already agreed to review for JOSS and may be suitable for this submission (please start at the bottom of the list).

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.88  T=0.09 s (480.0 files/s, 209662.2 lines/s)
-------------------------------------------------------------------------------
Language                     files          blank        comment           code
-------------------------------------------------------------------------------
JavaScript                      12           2447           2523           9245
HTML                             6            121              0           1155
CSS                              3            235             46            962
Python                          12            237            267            763
Markdown                         2             64              0            261
TeX                              1             20              0            191
YAML                             2              6             11             48
reStructuredText                 3             34             46             46
DOS Batch                        1              8              1             26
make                             1              4              7              9
-------------------------------------------------------------------------------
SUM:                            43           3176           2901          12706
-------------------------------------------------------------------------------

gitinspector failed to run statistical information for the repository

[editorialbot]

Wordcount for paper.md is 1799

[editorialbot]

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

OK DOIs

- 10.1103/PhysRevE.57.495 is OK
- 10.1103/PhysRevE.51.4141 is OK
- 10.1016/j.jcp.2014.07.046 is OK
- 10.1109/TGRS.2010.2043953 is OK
- 10.1109/LGRS.2016.2574759 is OK
- 10.1016/j.actamat.2018.01.005 is OK
- 10.1063/1.1695731 is OK
- 10.1063/1.527804 is OK
- 10.1111/jmi.12077 is OK
- 10.1098/rspa.2001.0900 is OK
- 10.1063/1.1600827 is OK
- 10.1016/j.compgeo.2021.104284 is OK
- 10.1088/0305-4470/17/5/008 is OK
- 10.1017/jfm.2018.875 is OK
- 10.1016/j.softx.2020.100595 is OK
- 10.5281/zenodo.3662366 is OK
- 10.1186/2193-9772-3-5 is OK

MISSING DOIs

- 10.1038/s41598-022-12845-7 may be a valid DOI for title: Synthesizing controlled microstructures of porous media using generative adversarial networks and reinforcement learning

INVALID DOIs

- None

[editorialbot]

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

[Kevin-Mattheus-Moerman]

@editorialbot query scope

[editorialbot]

Submission flagged for editorial review.

[Kevin-Mattheus-Moerman]

@larsblatny thanks for this submission. I am the AEiC for JOSS for this track and here to check if this work is in scope, and if so, to find a handling editor. I have just assigned the query-scope label. This is to trigger a scope review by the editorial board. In particular we will check if this work conforms to our substantial scholarly effort criteria, which is common for submissions of this size (in terms of lines of code). This scope review should be completed within about 2 weeks.

Note that in the meantime, if you wish, you could address that potentially missing DOI ☝️. And you may call @editorialbot check references to check these again.

[jgostick]

Hi @larsblatny, I would probably be a good candidate for associate editor of this one, so I'm going to put a few thoughts here. Please correct me in this thread if I am mistaken, and sorry if the following sounds harsh.

• Your submission does not constitute a package in my opinion. You basically have one function for generating microstructures, which does seem handy to me, but you have a lot of redundant code here. Once you strip this submission down to only the truly novel/necessary code, there is only one function left.
• As an example of redundant code, it strikes me as odd is that you've used NO functions from scikit-image or scipy.ndimage. How is it possible that you coded all of this up without asking "maybe there is already a function for this on the internet?". For instance...unless I am mistaken, your "clean_structure" function, which is 115 lines (including numerous python for loops, which I'll talk about below) can be accomplished in ONE LINE by calling skimage.segmentation.clear_border on the inverse of your image.
• Of the remaining code, a sizable chunk is just formatting of matplotlib and other visualization tools, which is not a scientific contribution. I'm sure you find this handy in your daily work, but this is not something you need to share with the world.
• Moreover, on the subject of redundant code, my group develops PoreSpy (https://github.com/PMEAL/porespy) which offers many generators including some that use thresholds of noise (see here and here). We also offer several other modules for doing the type of analysis you're doing (autocorrelation, chord lengths, etc). We even have a paper in JOSS about our package, so I'm surprized that you're unaware of it.
• Regarding your for-loops, you have a LOT of pure python for-loops where you actually index through images. This is an absolute no-no when dealing with large arrays like voxel images. Have you profiled your code on images of meaningful size, like 1000-cubed? Are you aware of the Numba, which can be used to do just-in-time compiliation of python functions to make them about 100x faster? Many of your loops would actually work perfectly for this...ironically because you don't use functions from other modules.
• You have no setup.py so I gather than you haven't tried to publish this on pip.
• You have no unit tests, which is a ton of work to create and is basically a hard requirement for JOSS.

[jgostick]

I would like to update my comment about the use of the clear_border function. You would use the inverse of the result, not inverse the input. Anyway, my point remains valid...there is a pre written solution to this already.

[larsblatny]

Hi @jgostick. Thank you very much for having a look at our software, and for your valuable comments. Also thanks for mentioning PoreSpy, which we were not familiar with, and which from a first glance appears to be a very interesting and well-documented software that could be used in our future research.

We are very well aware that several parts of our code can be implemented in more computationally efficient ways. This is especially the case for some of the post-processing functions, which you highlighted in your comment. For the particular post-processing related to structure cleaning, we were not aware that skimage.segmentation.clear_border could be used for this purpose. While our cleaning is a direct implementation of the Burning Method, we are very grateful for this suggestion which will certainly improve our code.

However, these post-processing functions are not the main contribution of our software, and we are aware that there exist available schemes in various different software that can be used instead of the post-processing functions we provide. Our purpose with GRFsaw was to provide a lightweight and simple microstructure generator based on the concept of thresholding Gaussian Random Fields (a method that we do not believe is directly available in other standard software for microstructure generation). While parts of the generator itself may also be improved in terms of computational efficiency, for example through the use of Numba, which again is a great suggestion from your side, it is already "efficient enough" for many practical purposes. By making our code open-source, we hope that readers and users can also suggest ways to speed up the code - exactly like you did - and this is very much appreciated from our side. Regarding tests, this is definitely something we can incorporate in the nearest future.

With this in mind, and with appropriate modifications, do you believe there is a future for our software and associated paper in JOSS?

[jgostick]

Hi @larsblatny I think the main problem is that JOSS has a threshold for 'scholarly effort', which is a bit vague, but means something like "the package has a lot of (useful) code". In fact, one of the first things we do for new submissions is count the lines of code (see 3rd comment in this thread). Your package is already low (even for Python), which triggered this discussion; but once you strip out the excess frills and unncessarily long/verbose code, it seems to be below that threshold. It's really just the one "gaussian thresholding" function. I would personally use this function, it seems great, but it is not enough to justify a JOSS paper. JOSS is getting quite popular, so we need to screen out packages which are not likely to become a pillar or cornerstone of research in its given area.

Also, I would like to point out that us editors also live by this threshold. My group has a package called BEaTmap which only does one thing: find surface area from isotherm data rigorously. I have not submitted to JOSS because I know it won't meet the threshold.

Finally, this is probably obvious, but I think the best way to publish your code is to write a scientific article that uses your image generator to produce some strutures for a specific application. In this paper you would explain in detail your implementation and its beneficial features. This is of course the traditional way publish code, but I think is the best/only route for such niche tools.

[larsblatny]

Hi @jgostick. Thanks for the clarification, and I’m happy to hear that you would personally use our software. For the record, although we certainly acknowledge that many elements of the software can be written more efficiently, parts of the code that you refer to as “excess frills and unnecessarily long/verbose code” support a more user-friendly software and provide helpful visualization. As such, obviously not every line of code can be considered a scientific contribution.

We will continue to improve our code, taking into account your suggestions. At this time, @Kevin-Mattheus-Moerman we request to withdraw our submission to JOSS and the closure of this discussion/issue.

[Kevin-Mattheus-Moerman]

@larsblatny the scope review by the editorial board has determined this work is unfortunately not in scope for JOSS. In particular this work does not pass our "substantial scholarly effort" criteria as it stands.

Note that the above does not mean the work is of a poor quality or not useful, it merely means it is currently not in scope.

We welcome any future (re-)submissions of a more substantial nature. Also we'd like to point out that you may want to consider other venues to e.g. ZENODO to enable software citation.

[Kevin-Mattheus-Moerman]

@editorialbot reject

[editorialbot]

Paper rejected.