[REVIEW]: DMT-core: A Python Toolkit for Semiconductor Device Engineers

[editorialbot]

Submitting author: !--author-handle-->@miesli<!--end-author-handle-- (Mario Krattenmacher) Repository: https://gitlab.com/dmt-development/dmt-core Branch with paper.md (empty if default branch): Version: 1.6.2 Editor: !--editor-->@lucydot<!--end-editor-- Reviewers: @dilawar, @phoebe-p Archive: 10.5281/zenodo.6685185

Status

Status badge code:

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

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

@dilawar & @phoebe-p, your review will be checklist based. Each of you will have a separate checklist that you should update when carrying out your review. First of all you need to run this command in a separate comment to create the checklist:

@editorialbot generate my checklist

The reviewer guidelines are available here: https://joss.readthedocs.io/en/latest/reviewer_guidelines.html. Any questions/concerns please let @lucydot know.

✨ Please start on your review when you are able, and be sure to complete your review in the next six weeks, at the very latest ✨

Checklists

📝 Checklist for @dilawar

📝 Checklist for @phoebe-p

[editorialbot]

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

[lucydot]

Dear @miesli I've just submited a PR with some edits to the language in your paper (https://gitlab.com/dmt-development/dmt-core/-/merge_requests/2). Please review my suggested changes carefully to ensure that your meaning is not lost.

[lucydot]

@miesli in addition I think that the "statement of need" section would be improved if there was a reference supporting your claims regarding issues with "home-made" scripts (I'm using my wording here). I agree that these are common problems - it would be good to find something in the literature to evidence what we both know anecdotally. There is quite a lot of work done on this in the context of reproducibility - for example, https://www.science.org/doi/full/10.1126/science.aah6168 might have something.

[dilawar]

Thanks, @lucydot for bringing up the reproducibility. It is a significant issue — a couple of examples from the field of neuroscience/biology.

• https://journals.plos.org/ploscompbiol/article?id=10.1371/journal.pcbi.1001122 | Minimum Information About a Simulation Experiment (MIASE)
• https://biosimulators.org | It is a community platform to run simulations where reproducibility is a central selling point.

[miesli]

@lucydot Thank you for improving the language. Your tips were quite helpful.

I am not sure, how to "proof" the claim of "home-made" scripts. Although people admit this in private, I do not know someone who could be cited for that.

The paper "Enhancing reproducibility for computational methods" was quite a good read. DMT addresses the point:

Share data, software, workflows, and details of the computational environment that generate published findings in open trusted repositories

Using DMT simulation data generation, workflow implementation and result generation can be implemented in a single file. DMT would carry all the "simple" stuff needed to focus on the real stuff of the paper. So we see this as one step into a better direction. But there is the simple fact that most journals do not require to publish the implementations, and currently we do not see that this will change.

@dilawar Thanks for the papers. Good to see that, at least in biology, the community advanced to a better standard.

[lucydot]

Hi @miesli perhaps you could incorporate your comment above re: reprocubility and the reference into your paper:

DMT-based simulations allow data generation, workflow implementation and visualization to be be implemented in a single file, allowing for more reproducible research [@stodden2016]. In addition, basic principles of software engineering, such as unit testing, version control and documentation are adhered to, so that others can also use and contribute to the software.

I tried editing myself directly but keep getting a message about somebody else making an edit at the same time.

[miesli]

There seems to be an issue with the CI build-chain. It is stuck at checking the CI build chain. I will have to debug that, but it seems to be an known issue.

I have added the text about rebroducibility to the paper. One can still hope :)

[phoebe-p]

Hi all, sorry for my silence, last few weeks were busy -- I will attempt to run the two examples I was having trouble with again by switching from Xyce to Ngspice, and avoiding the use of LaTeX in the other.

[phoebe-p]

Happy to report I can now run the three examples (making minor modifications, so commenting out the DutXyce line and using he DutNgspice lone since I do not have Xyce installed, and setting use_tex=False in the plotting functions)!

[lucydot]

Excellent @phoebe-p, thanks for the update. @miesli if not done already it may be good to give hints to do these small edits somewhere in the documentation.

[miesli]

@phoebe-p thank you for double-checking the changes I made. I'm really happy that it works now for you.

@lucydot I added paragraphs about interchanging DutXyce and DutNgspice, and about Plot.plot_py(use_tex=False) in the introduction.

[miesli]

@editorialbot set 1.6.0 as version

[editorialbot]

I'm sorry @miesli, I'm afraid I can't do that. That's something only editors are allowed to do.

[lucydot]

@editorialbot set 1.6.0 as version

[editorialbot]

Done! version is now 1.6.0

[lucydot]

@phoebe-p I can see you have ticked off all boxes and (from your last comment) have ran the examples, so I guess you are happy to recommend for acceptance (in fact I think you recommended for acceptance a few messages ago, so I'll assume that is still the case!).

There seems to be an issue with the CI build-chain. It is stuck at checking the CI build chain. I will have to debug that, but it seems to be an known issue.

@miesli let me know when the CI is fixed (I tried checking this myself, but the CI status button at the top of your README file was broken). After the CI is fixed we can do the final small editorial steps before passing onto the EiCs.

[miesli]

@lucydot thanks for updating the version.

The pipeline was stuck at releasing the wheel to the gitlab and pypi repository. I did not test this release automation enough in the past and assumed my copied CI-configuration works -.-. So, now it does. Each new commit to main is now properly automated and if a tag is set, a push to pypi and a release version is created.

The Issue, you are talking about, is there because I ticked "check CI before merge" in the settings. But this does not really work, if the CI is only run for commits to special branches.

The next step is to use the "rules" section instead of the "only" in the ci.yml to determine the branch and also merge requests. I will try to achieve this later (I do not know when exactly). So the current state and version is the one for the paper

[lucydot]

@editorialbot generate pdf

[lucydot]

@editorialbot check references

[editorialbot]

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

OK DOIs

- 10.1109/MS.2010.152 is OK
- 10.2172/1826862 is OK
- 10.25080/majora-92bf1922-00a is OK
- 10.1109/MMM.2021.3117139 is OK
- 10.1109/JEDS.2020.3023165 is OK
- 10.1109/TED.2021.3051552 is OK
- 10.1109/bcicts50416.2021.9682487 is OK
- 10.1109/bcicts50416.2021.9682485 is OK
- 10.1109/bcicts50416.2021.9682473 is OK
- 10.1109/JEDS.2020.3023165 is OK
- 10.1126/science.aah6168 is OK

MISSING DOIs

- None

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:

[phoebe-p]

@lucydot Your assumption is correct, I am recommending acceptance :)

[lucydot]

@miesli I've made some edits to the paper wording. I have tried editing this directly on Gitlab but keep getting an annoying error about someone editing the file at the same time (I'm 99% sure this is not the case so I'm not sure why it keeps popping up...). So I've pasted the proposed changes as a gist here: https://gist.github.com/lucydot/9d7afb8bd387d0f13d7ee1ce75aebfcd - please check meaning has been lost. Changes are to improve readability.

[miesli]

@lucydot Thank you for the new changes. I included most of them, the exceptions are those, there we want to address a bigger community. For example:

This enables semiconductor device engineers with some basic experience in Python to install, use and contribute to the software.

to

This enables electrical engineers with some basic experience in Python to install, use and contribute to the software.

I also just tried to use the edit button in gitlab.com. It worked for me. Did you try in your fork or our repo?

[miesli]

@lucydot here are my changes (also in the gist to make an easy diff)

https://gist.github.com/miesli/f94111018af08fe855b828e441283b4c/revisions?diff=split

I also merged the changes into main so version 1.6.1 is the correct one now (finished CI bugfix in 1.6.1)

[lucydot]

@editorialbot generate pdf

[lucydot]

@editorialbot set 1.6.1 as version

[editorialbot]

Done! version is now 1.6.1

[editorialbot]

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

[lucydot]

OK @miesli the pdf looks good to me - final steps now. Please can you do the following:

• Make a tagged release of your software
• Archive this release on Zenodo (or similar)
  • The archive should have exactly the same title and author list as your JOSS paper
• Report the archive DOI in this thread

[lucydot]

I also just tried to use the edit button in gitlab.com. It worked for me. Did you try in your fork or our repo?

This was when trying to commit to my fork - others have reported a similar problem for other repos. Oh well, one to think about another day!

[miesli]

@lucydot

• The release link is here
• The Zenodo archive DOI is 10.5281/zenodo.6684190

Thank you for doing the publication with us.

Also thank you to @dilawar and @phoebe-p for the great reviews and work!

[lucydot]

Excellent thanks @miesli.

[editorialbot]

I'm sorry human, I don't understand that. You can see what commands I support by typing:

@editorialbot commands

[lucydot]

@editorialbot set 10.5281/zenodo.6684190 as archive

[editorialbot]

Done! Archive is now 10.5281/zenodo.6684190

[lucydot]

@editorialbot recommend-accept

[editorialbot]

Attempting dry run of processing paper acceptance...

[editorialbot]

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

OK DOIs

- 10.1109/MS.2010.152 is OK
- 10.2172/1826862 is OK
- 10.25080/majora-92bf1922-00a is OK
- 10.1109/MMM.2021.3117139 is OK
- 10.1109/JEDS.2020.3023165 is OK
- 10.1109/TED.2021.3051552 is OK
- 10.1109/bcicts50416.2021.9682487 is OK
- 10.1109/bcicts50416.2021.9682485 is OK
- 10.1109/bcicts50416.2021.9682473 is OK
- 10.1109/JEDS.2020.3023165 is OK
- 10.1126/science.aah6168 is OK

MISSING DOIs

- None

INVALID DOIs

- None

[editorialbot]

:warning: Error prepararing paper acceptance. The generated XML metadata file is invalid.

ID ref-Kuthe2020a already defined

[miesli]

That paper is twice in the bib-file Oo. I will fix that immediately.

PS: It would be great if the reference check could also check that.

[miesli]

The new version is 1.6.2

• Release
• Archive-DOI 10.5281/zenodo.6685185

I hope it works now. Sorry :(

[lucydot]

@editorialbot set 1.6.2 as version

[editorialbot]

Done! version is now 1.6.2

[lucydot]

@editorialbot set 10.5281/zenodo.6685185 as archive

[editorialbot]

Done! Archive is now 10.5281/zenodo.6685185

[lucydot]

@editorialbot recommend-accept

[editorialbot]

Attempting dry run of processing paper acceptance...

[editorialbot]

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

OK DOIs

- 10.1109/MS.2010.152 is OK
- 10.2172/1826862 is OK
- 10.25080/majora-92bf1922-00a is OK
- 10.1109/MMM.2021.3117139 is OK
- 10.1109/TED.2021.3051552 is OK
- 10.1109/bcicts50416.2021.9682487 is OK
- 10.1109/bcicts50416.2021.9682485 is OK
- 10.1109/bcicts50416.2021.9682473 is OK
- 10.1109/JEDS.2020.3023165 is OK
- 10.1126/science.aah6168 is OK

MISSING DOIs

- None

INVALID DOIs

- None

[editorialbot]

:wave: @openjournals/joss-eics, this paper is ready to be accepted and published.

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

If the paper PDF and the deposit XML files look good in https://github.com/openjournals/joss-papers/pull/3313, then you can now move forward with accepting the submission by compiling again with the command @editorialbot accept