Skip to content

[REVIEW]: SIMsalabim: A time resolved drift-diffusion simulation software #3727

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom
Closed
60 tasks done
whedon opened this issue Sep 14, 2021 · 139 comments
Closed
60 tasks done

[REVIEW]: SIMsalabim: A time resolved drift-diffusion simulation software #3727

whedon opened this issue Sep 14, 2021 · 139 comments
Assignees
@roderickmackenzie @shahmoradi @ProfTuan @rkurchin
Labels
accepted Pascal published Papers published in JOSS recommend-accept Papers recommended for acceptance in JOSS. review TeX

Comments

@whedon
Copy link

whedon commented Sep 14, 2021 •
edited
Loading

Submitting author: @ljakoster (Lambert Jan Anton Koster)
Repository: https://github.com/kostergroup/SIMsalabim
Version: v4.29-JOSS
Editor: @rkurchin
Reviewer: @UTH-Tuan, @shahmoradi, @roderickmackenzie
Archive: 10.5281/zenodo.6010442

⚠️ JOSS reduced service mode ⚠️

Due to the challenges of the COVID-19 pandemic, JOSS is currently operating in a "reduced service mode". You can read more about what that means in our blog post.

Status

status

Status badge code:

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

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

@UTH-Tuan & @shahmoradi & @roderickmackenzie, 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 @rkurchin 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 ✨

Review checklist for @UTH-Tuan

✨ Important: Please do not use the Convert to issue functionality when working through this checklist, instead, please open any new issues associated with your review in the software repository associated with the submission. ✨

Conflict of interest

  • I confirm that I have read the JOSS conflict of interest (COI) policy and that: I have no COIs with reviewing this work or that any perceived COIs have been waived by JOSS for the purpose of this review.

Code of Conduct

General checks

  • Repository: Is the source code for this software available at the repository url?
  • License: Does the repository contain a plain-text LICENSE file with the contents of an OSI approved software license?
  • Contribution and authorship: Has the submitting author (@ljakoster) made major contributions to the software? Does the full list of paper authors seem appropriate and complete?
  • Substantial scholarly effort: Does this submission meet the scope eligibility described in the JOSS guidelines

Functionality

  • Installation: Does installation proceed as outlined in the documentation?
  • Functionality: Have the functional claims of the software been confirmed?
  • 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

  • A statement of need: Do the authors clearly state what problems the software is designed to solve and who the target audience is?
  • Installation instructions: Is there a clearly-stated list of dependencies? Ideally these should be handled with an automated package management solution.
  • Example usage: Do the authors include examples of how to use the software (ideally to solve real-world analysis problems).
  • Functionality documentation: Is the core functionality of the software documented to a satisfactory level (e.g., API method documentation)?
  • Automated tests: Are there automated tests or manual steps described so that the functionality of the software can be verified?
  • 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

  • Summary: Has a clear description of the high-level functionality and purpose of the software for a diverse, non-specialist audience been provided?
  • A statement of need: Does the paper have a section titled 'Statement of Need' that clearly states what problems the software is designed to solve and who the target audience is?
  • State of the field: Do the authors describe how this software compares to other commonly-used packages?
  • Quality of writing: Is the paper well written (i.e., it does not require editing for structure, language, or writing quality)?
  • References: Is the list of references complete, and is everything cited appropriately that should be cited (e.g., papers, datasets, software)? Do references in the text use the proper citation syntax?

Review checklist for @shahmoradi

✨ Important: Please do not use the Convert to issue functionality when working through this checklist, instead, please open any new issues associated with your review in the software repository associated with the submission. ✨

Conflict of interest

  • I confirm that I have read the JOSS conflict of interest (COI) policy and that: I have no COIs with reviewing this work or that any perceived COIs have been waived by JOSS for the purpose of this review.

Code of Conduct

General checks

  • Repository: Is the source code for this software available at the repository url?
  • License: Does the repository contain a plain-text LICENSE file with the contents of an OSI approved software license?
  • Contribution and authorship: Has the submitting author (@ljakoster) made major contributions to the software? Does the full list of paper authors seem appropriate and complete?
  • Substantial scholarly effort: Does this submission meet the scope eligibility described in the JOSS guidelines

Functionality

  • Installation: Does installation proceed as outlined in the documentation?
  • Functionality: Have the functional claims of the software been confirmed?
  • 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

  • A statement of need: Do the authors clearly state what problems the software is designed to solve and who the target audience is?
  • Installation instructions: Is there a clearly-stated list of dependencies? Ideally these should be handled with an automated package management solution.
  • Example usage: Do the authors include examples of how to use the software (ideally to solve real-world analysis problems).
  • Functionality documentation: Is the core functionality of the software documented to a satisfactory level (e.g., API method documentation)?
  • Automated tests: Are there automated tests or manual steps described so that the functionality of the software can be verified?
  • 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

  • Summary: Has a clear description of the high-level functionality and purpose of the software for a diverse, non-specialist audience been provided?
  • A statement of need: Does the paper have a section titled 'Statement of Need' that clearly states what problems the software is designed to solve and who the target audience is?
  • State of the field: Do the authors describe how this software compares to other commonly-used packages?
  • Quality of writing: Is the paper well written (i.e., it does not require editing for structure, language, or writing quality)?
  • References: Is the list of references complete, and is everything cited appropriately that should be cited (e.g., papers, datasets, software)? Do references in the text use the proper citation syntax?

Review checklist for @roderickmackenzie

✨ Important: Please do not use the Convert to issue functionality when working through this checklist, instead, please open any new issues associated with your review in the software repository associated with the submission. ✨

Conflict of interest

  • I confirm that I have read the JOSS conflict of interest (COI) policy and that: I have no COIs with reviewing this work or that any perceived COIs have been waived by JOSS for the purpose of this review.

Code of Conduct

General checks

  • Repository: Is the source code for this software available at the repository url?
  • License: Does the repository contain a plain-text LICENSE file with the contents of an OSI approved software license?
  • Contribution and authorship: Has the submitting author (@ljakoster) made major contributions to the software? Does the full list of paper authors seem appropriate and complete?
  • Substantial scholarly effort: Does this submission meet the scope eligibility described in the JOSS guidelines

Functionality

  • Installation: Does installation proceed as outlined in the documentation?
  • Functionality: Have the functional claims of the software been confirmed?
  • 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

  • A statement of need: Do the authors clearly state what problems the software is designed to solve and who the target audience is?
  • Installation instructions: Is there a clearly-stated list of dependencies? Ideally these should be handled with an automated package management solution.
  • Example usage: Do the authors include examples of how to use the software (ideally to solve real-world analysis problems).
  • Functionality documentation: Is the core functionality of the software documented to a satisfactory level (e.g., API method documentation)?
  • Automated tests: Are there automated tests or manual steps described so that the functionality of the software can be verified?
  • 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

  • Summary: Has a clear description of the high-level functionality and purpose of the software for a diverse, non-specialist audience been provided?
  • A statement of need: Does the paper have a section titled 'Statement of Need' that clearly states what problems the software is designed to solve and who the target audience is?
  • State of the field: Do the authors describe how this software compares to other commonly-used packages?
  • Quality of writing: Is the paper well written (i.e., it does not require editing for structure, language, or writing quality)?
  • References: Is the list of references complete, and is everything cited appropriately that should be cited (e.g., papers, datasets, software)? Do references in the text use the proper citation syntax?
@whedon
Copy link
Author

whedon commented Sep 14, 2021

Hello human, I'm @whedon, a robot that can help you with some common editorial tasks. @UTH-Tuan, @shahmoradi, @roderickmackenzie it looks like you're currently assigned to review this paper 🎉.

⚠️ JOSS reduced service mode ⚠️

Due to the challenges of the COVID-19 pandemic, JOSS is currently operating in a "reduced service mode". You can read more about what that means in our blog post.

⭐ Important ⭐

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:

watching

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

notifications

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

@whedon commands

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

@whedon generate pdf

@whedon whedon mentioned this issue Sep 14, 2021
Closed
@whedon
Copy link
Author

whedon commented Sep 14, 2021

Wordcount for paper.md is 571

@whedon
Copy link
Author

whedon commented Sep 14, 2021 

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

OK DOIs

- 10.1016/j.xcrp.2021.100346 is OK
- 10.1021/acsenergylett.0c02599 is OK
- 10.1039/D0EE00714E is OK
- 10.1021/acsami.0c16411 is OK
- 10.1103/PhysRevApplied.15.014006 is OK
- 10.1021/acsenergylett.9b02720 is OK
- 10.1021/acsami.8b20493 is OK
- 10.1021/acsaem.9b00856 is OK

MISSING DOIs

- None

INVALID DOIs

- None

@whedon
Copy link
Author

whedon commented Sep 14, 2021 

Software report (experimental):

github.com/AlDanial/cloc v 1.88  T=0.04 s (289.9 files/s, 142762.7 lines/s)
-------------------------------------------------------------------------------
Language                     files          blank        comment           code
-------------------------------------------------------------------------------
Pascal                           7            676           1006           3334
Markdown                         3            103              0            166
TeX                              1             18              0            114
-------------------------------------------------------------------------------
SUM:                            11            797           1006           3614
-------------------------------------------------------------------------------


Statistical information for the repository 'd69dfd24522b30627402b84d' was
gathered on 2021/09/14.
No commited files with the specified extensions were found.

@whedon
Copy link
Author

whedon commented Sep 14, 2021

👉📄 Download article proof 📄 View article proof on GitHub 📄 👈

@rkurchin
Copy link

Copying @roderickmackenzie's comments from the pre-review issue #3412 ...

Hi There!,
Thanks for your mail. Sorry for not seeing this I have a special e-mail account setup for high volume stuff which I don't check.. and this went into it.. So as far as I understand the review process, I just write comments here and then the authors respond?

I am happy to take a look but will need a few days to compile and poke at the code base. I've not used Pascal since the Borland Delphi days of 2000..

I've read the manual and had a quick poke around. Some initial comments are:
*Nice manual.
*Nice scientific description in the manual.
*The code seems clear on first impressions.
*I like the hat logo!
*I also like your implementation of the bernoulli function, might be faster than what I do. Exponentials are always a pain to calculate as they are done iteratively... I would be good though if you could point to literature or show a graph that what you do works.
*The model is clearly a nice thing and a benefit to the community. The more people are simulating these devices the better as we will have a chance of pushing renewable stuff forward...

Here are some general questions to kick off with:

Your use of the V in equations 2.1 -2.6 is a bit confusing because commonly V is only used in the DD equations when hetero-junctions are not taken into account. When the model has been adjusted to handle hetero-junctions (as yours seems to be 2.13-2.14) it's conmen to write Ec and Ev in the DD equations instead of V, to explicitly say that heterosteps can drive current. This is especially confusing as your fig 2.1 shows hetero steps so made me scratch me head as soon as I started reading until I reached the interfaces section. If you rewrite in terms of Ec and Ev you can get rid of equations 2.13-2.14, it would make the description look more like the classical DD literature as used for things like the III-V materials - and make things a bit clearer.

As I understand it there are two parts to the model a transient part and a steady state parts. In the intro you talk about transient photovoltage and AC analysis. However your equation 2.22 is the steady state form of the SRH equation, so you are assuming your trapped carrier distribution is in quasi-steady state. This means that although you can do time domain simulations your trapped carriers will always think they are in quasi-equilibrium. This won't matter for DC or for slow small perturbation stuff. But you won't for example be able to simulate things far from equilibrium, e.g. ToF transients are an extreme example of this where carriers are initially captured then gradually released from deeper and deeper traps as time goes on. TPV transients could also meet this large signal condition depending on the power of the laser pulse, and AC depending on carrier trapping/detrapping rates and the frequency you are at (and trap depth). CELIV will also fall into large perturbation regime etc... etc... I think the user should be alerted to the fact that your carriers are in SS and the model does not explicitly solve the SRH equations in time domain. Many users won't grasp this so I think it needs to be clearly pointed out and what the implications of this are for results.

I'm assuming that your trapped carriers introduced through equation 2.22 don't interact with the field? As for some devices (organics) quite a lot of the charge will be trapped (>90%) so this could affect the results. If the trapped charge does not affect the field I think the user should also be told about this in the manual. Maybe include a limitations section in the manual? Again, it depends on what the user is using the code for. If it's some perovskite device with not many traps then this may not be an issue, but if it's some ultra trappy organic thing then..

I think my main concern with points 2 and 3 is that the user knows what he/she is dealing with. There are a tonne of papers where people just use software (aka COMSOL etc..) to produce a paper without understand what is going on under the hood and results in miss interpretation of data which is not a good thing.

Would be nice if you could add some makefiles. Also would be good if you could tell me (the user) which package I need to install on Ubuntu to get pascal. I'm not super excited about installing free pascal binaries from anything but the Ubuntu repos due to security reasons.
I'll install and play with over the next week then get more computer related comments back to you..

best,
Rod

@rkurchin
Copy link

@ljakoster, I think Rod's comments above give a solid starting point for things to address on the technical side. I wanted to jump in with a slightly more "administrative" query as well:

Given that this code has been around for a long time and has suggested citations in the repo, it's important that we ensure this submission isn't in violation of JOSS's self-plagiarism policy. Can you clarify what aspects of this submission have not been previously published?

@ljakoster
Copy link

ljakoster commented Sep 15, 2021 via email

@ProfTuan
Copy link

I am bit confused by documentation to compile it. Sorry, my previous experience was in Object Pascal using Delphi IDE. So it might be helpful to get more clarification on how to compile it. Specifically I am thrown off by the bracket placeholder ( [zimbt] )... is this supposed to be the path to the ZimbT folder?

@ljakoster
Copy link

ljakoster commented Sep 17, 2021 via email

@rkurchin
Copy link

@shahmoradi, reminder to get your checklist started! Similarly for @UTH-Tuan, assuming the comments from @ljakoster above resolve your issues...

@rkurchin
Copy link

Followup ping to reviewers @UTH-Tuan @shahmoradi!

@whedon
Copy link
Author

whedon commented Sep 28, 2021

👋 @shahmoradi, please update us on how your review is going (this is an automated reminder).

@whedon
Copy link
Author

whedon commented Sep 28, 2021

👋 @roderickmackenzie, please update us on how your review is going (this is an automated reminder).

@whedon
Copy link
Author

whedon commented Sep 28, 2021

👋 @UTH-Tuan, please update us on how your review is going (this is an automated reminder).

@roderickmackenzie
Copy link

@whedon Waiting for blockers from first review to be resolved.

@whedon
Copy link
Author

whedon commented Oct 4, 2021

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

@whedon commands

@rkurchin
Copy link

rkurchin commented Oct 5, 2021

@ljakoster, any updates on Rod's review?

@UTH-Tuan, did the response above help you to compile the code?

@shahmoradi, reminder to please start your review!

@ljakoster
Copy link

ljakoster commented Oct 5, 2021 via email

@rkurchin
Copy link

rkurchin commented Oct 5, 2021

Make any updates to the code and/or manuscript that are needed to address the issues, and describe the changes here (or, if you prefer to open issues in your own repository to track things individually, that's also fine, just mention this issue in them and link to them here). If you update the manuscript, you can refresh the proof here by running @whedon generate pdf (note that this must be the first thing in your comment for Whedon to trigger properly).

@shahmoradi
Copy link

shahmoradi commented Oct 6, 2021 •
edited
Loading

Comments for the authors:

  • The paper is well-written and the statement of the need is reasonable.

    • A comparison with other available comparable software to SIMsalabim would be highly desirable.

  • Licensing issues:

    • There are multiple CopyRight files in the project in different subfolders.
      Only one should really exist and if parts of the code are licensed differently,
      then this should be clearly stated in the front page README file licensing section.
      But I doubt if this is indeed the case as all license files appear to be either GNU or GNU Lesser.
    • I think it suffices to have only one set of license files at the root of the project.
      If the authors are worried about users' lack of attention to the license,
      I suggest adding the licensing information at the top of each source file.
      Having too many redundant files in the repository, only adds to the user's confusion.
    • My suggestion is to rename all licensing files to something that clearly conveys what the files indeed contain, like LICENSE, LICENSE.txt, LICENSE.md, ...
      It seems to me that JOSS requires the existence of a file named LICENSE
      in the root of the project, which is missing in this repository.

  • Binary releases:

    • The binaries provided in the repository work fine for the given sample.
    • However, it seems odd and highly unusual to release binaries as part of the Git project. I am even surprised by the fact that GitHub allows the uploading of binaries to a Git project hosted on GitHub.
      I suggest the authors upload the binaries to the release page of their project.
      There are currently no releases published under this project.
      The binaries along with the example files should go there.
      Authors could separate the builds for different platforms into separate release compressed files.

  • Documentation:

    • Missing README.md files:
      • Every folder should ideally contain a README.md file describing the
        reasons for the existence of the folder and a description of its contents.
        For example, what is the purpose of zimT folder? Is it a separate project?
        If it is a separate project, then the authors may want to put it in a separate repository.
        If it is not a separate project, then its connection with SIMsalabim should be clarified.
    • User Documentation:
      The User documentation looks fine on GitHub. But the file seems to be corrupted on Windows OS.
      The authors should check if the user documentation PDF file opens properly on all supported operating systems.
      It is possible that this PDF file was generated on a macOS or Linux OS and it is incompatible with Windows.
      In any case, it needs a fix.
    • change_log.txt Should likely be moved to the root of the project.
    • Ideally, the project would also benefit from developer documentation devoted to guiding future developers about the structure of the code. Consider this question: If I decide to make any contributions to this project,
      can I start today independently, fork the project, understand the structure of the project, and make meaningful contributions to the project to merge with the main branch? This is where the developer documentation becomes handy.
      Right now, this project appears to become an orphan as soon as the primary contributor to the project (kostergroup)
      stops contributing to it, unless there is a developer guideline for the potential future developers.

  • Testing and Code Coverage:

    • There exists a folder named Tests in the project.
      But I could not find any code that performs any tests of the codebase functionality here in a verifiable manner.
      The tests in this folder resemble more a set of example input files.
      The authors should consider this question: How could a potential user of this library ensure that the library's functionality is verifiable at any time in the future? Even if the code works fine today and is accurate,
      how do we know the next person who works on this project will not introduce bugs and errors in the code or cause regression inadvertently?

  • Compilation:

    • I have tested the compilation of the two codebases on Windows
      and it seems to compile and run fine with the supplied example input file.

@rkurchin
Copy link

@UTH-Tuan, were you able to run the code and begin your review?

@whedon
Copy link
Author

whedon commented Feb 8, 2022 

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

OK DOIs

- 10.1016/j.xcrp.2021.100346 is OK
- 10.1021/acsenergylett.0c02599 is OK
- 10.1039/D0EE00714E is OK
- 10.1021/acsami.0c16411 is OK
- 10.1103/PhysRevApplied.15.014006 is OK
- 10.1021/acsenergylett.9b02720 is OK
- 10.1021/acsami.8b20493 is OK
- 10.1021/acsaem.9b00856 is OK
- 10.1007/s10825-019-01396-2 is OK
- 10.1016/S0040-6090(99)00825-1 is OK

MISSING DOIs

- None

INVALID DOIs

- None

@whedon
Copy link
Author

whedon commented Feb 8, 2022

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

Check final proof 👉 openjournals/joss-papers#2933

If the paper PDF and Crossref deposit XML look good in openjournals/joss-papers#2933, then you can now move forward with accepting the submission by compiling again with the flag deposit=true e.g.

@whedon accept deposit=true from branch paper

@ljakoster
Copy link

ljakoster commented Feb 9, 2022 via email

@kthyng
Copy link

kthyng commented Feb 9, 2022

Hi @ljakoster! A few last items:

  1. zenodo and version look good.
  2. I recommend putting `` around SIMsalabim so it stands out as software.
  3. Is Hu et al missing a title?
  4. MacKenzie et al seems like it is missing information?
  5. Do your references just happen to stop at M? Seems odd.

@ljakoster
Copy link

ljakoster commented Feb 10, 2022 via email

@whedon
Copy link
Author

whedon commented Feb 10, 2022

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

@whedon commands

@kostergroup
Copy link

kostergroup commented Feb 10, 2022 via email

@whedon
Copy link
Author

whedon commented Feb 10, 2022 

Attempting PDF compilation from custom branch paper. Reticulating splines etc...

@whedon
Copy link
Author

whedon commented Feb 10, 2022

👉📄 Download article proof 📄 View article proof on GitHub 📄 👈

@ljakoster
Copy link

ljakoster commented Feb 10, 2022 via email

@kthyng
Copy link

kthyng commented Feb 10, 2022

@ljakoster ok! One thing — I meant `` around your software name throughout the paper, but it is up to you. Would you like to change that before we accept the final version of the paper?

@kostergroup
Copy link

kostergroup commented Feb 11, 2022 via email

@rkurchin
Copy link

@whedon generate pdf from branch paper

@whedon
Copy link
Author

whedon commented Feb 11, 2022 

Attempting PDF compilation from custom branch paper. Reticulating splines etc...

@whedon
Copy link
Author

whedon commented Feb 11, 2022

👉📄 Download article proof 📄 View article proof on GitHub 📄 👈

@kthyng
Copy link

kthyng commented Feb 11, 2022

Ok everything looks great!

@kthyng
Copy link

kthyng commented Feb 11, 2022

@whedon accept deposit=true from branch paper

@whedon
Copy link
Author

whedon commented Feb 11, 2022 

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

@whedon whedon added accepted published Papers published in JOSS labels Feb 11, 2022
@whedon
Copy link
Author

whedon commented Feb 11, 2022

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

@whedon
Copy link
Author

whedon commented Feb 11, 2022

🚨🚨🚨 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 👉 Creating pull request for 10.21105.joss.03727 joss-papers#2950
  2. Wait a couple of minutes, then verify that the paper DOI resolves https://doi.org/10.21105/joss.03727
  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...

@kthyng
Copy link

kthyng commented Feb 11, 2022

Congratulations on your new publication @ljakoster! Many thanks to editor @rkurchin and reviewers @UTH-Tuan, @shahmoradi, and @roderickmackenzie for your time, hard work, and expertise!!

@kthyng kthyng closed this as completed Feb 11, 2022
@whedon
Copy link
Author

whedon commented Feb 11, 2022

🎉🎉🎉 Congratulations on your paper acceptance! 🎉🎉🎉

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.03727/status.svg)](https://doi.org/10.21105/joss.03727)

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

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

This is how it will look in your documentation:

DOI

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:

@editorialbot editorialbot mentioned this issue Oct 1, 2023
Open
@editorialbot editorialbot mentioned this issue Oct 25, 2023
Closed
@editorialbot editorialbot mentioned this issue Jan 11, 2024
Closed
@editorialbot editorialbot mentioned this issue Jun 23, 2024
Closed
@editorialbot editorialbot mentioned this issue May 17, 2025
Open
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@roderickmackenzie roderickmackenzie

@shahmoradi shahmoradi

@ProfTuan ProfTuan

@rkurchin rkurchin

Labels
accepted Pascal published Papers published in JOSS recommend-accept Papers recommended for acceptance in JOSS. review TeX
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
9 participants
@roderickmackenzie @danielskatz @kthyng @shahmoradi @ProfTuan @rkurchin @whedon @Mkoopm @ljakoster