[REVIEW]: FASMA 2.0: A Python package for stellar parameters and chemical abundances

[whedon]

Submitting author: @MariaTsantaki (Maria Tsantaki)
Repository: https://github.com/MariaTsantaki/FASMA-synthesis
Version: v2.0
Editor: @xuanxu
Reviewer: @warrickball, @ipelupessy
Archive: 10.5281/zenodo.3885291

Status

Status badge code:

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

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

@warrickball & @ipelupessy, 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 @xuanxu know.

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

Review checklist for @warrickball

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

• I confirm that I read and will adhere to the JOSS 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 (@MariaTsantaki) made major contributions to the software? Does the full list of paper authors seem appropriate and complete?

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: Do the authors clearly state 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 @ipelupessy

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

• I confirm that I read and will adhere to the JOSS 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 (@MariaTsantaki) made major contributions to the software? Does the full list of paper authors seem appropriate and complete?

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: Do the authors clearly state 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]

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

⭐ 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:

2. 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

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

@whedon generate pdf

[whedon]

Reference check summary:

OK DOIs

- 10.1086/152374 is OK
- 10.1051/0004-6361:200809724 is OK
- 10.1093/mnras/stx2564 is OK
- 10.1051/0004-6361/201527120 is OK
- 10.1137/0111030 is OK
- 10.1088/0031-8949/90/5/054005 is OK

MISSING DOIs

- None

INVALID DOIs

- None

[whedon]

👉 Check article proof 📄 👈

[xuanxu]

@MariaTsantaki, @warrickball, @ipelupessy : this is the review thread for the paper. All of our communications will happen here from now on.

Both reviewers have checklists at the top of this thread with the JOSS requirements. As you go over the submission, please check any items that you feel have been satisfied. There are also links to the JOSS reviewer guidelines.

The JOSS review is different from most other journals. Our goal is to work with the authors to help them meet our criteria instead of merely passing judgment on the submission. As such, the reviewers are encouraged to submit issues and pull requests on the software repository. When doing so, please mention openjournals/joss-reviews#2048 so that a link is created to this thread (and I can keep an eye on what is happening). Please also feel free to comment and ask questions on this thread. In my experience, it is better to post comments/questions/suggestions as you come across them instead of waiting until you've reviewed the entire package.

We aim for reviews to be completed within about 2-4 weeks. Please let me know if any of you require some more time. We can also use Whedon (our bot) to set automatic reminders if you know you'll be away for a known period of time.

Please feel free to ping me (@xuanxu) if you have any questions/concerns.

[ipelupessy]

@MariaTsantaki I think the install procedure should not require sudo

[ipelupessy]

@MariaTsantaki I see that the install procedure calls for editing the source code of MOOG by hand and then build/installing this seperately; it would be nicer if the setup.py does this for you (both things). Also the model data extraction can also be put in the setup.py. fixing this would allow a pip install FASMA

[ipelupessy]

@MariaTsantaki at first sight I see only two tests in FASMA/tests. is this correct?

[ipelupessy]

@MariaTsantaki the repository contains compiled .o and executable files of MOOG. I would suggest these be removed.

[DanielAndreasen]

@ipelupessy (I'm co-author of FASMA). It is true that there currently only are two unit tests. We plan to add more continously, but it hasn't been a priority.

[MariaTsantaki]

@ipelupessy Thanks for reviewing! It's true, only 2 tests. My reason is that errors can be checked by modifying the configuration file and running fasma. But I can include more tests if it is more efficient for the testing.

[ipelupessy]

ok, you need at least basic tests where you go through some simple cases (confirming the install went ok etc) - this will help you enormously when you change something in the install, making sure nothing breaks..

another comment: have you tried to minimize your prerequisites? e.g. I think at the moment astropy is only needed for for fits support - its a big prereq. for a small task..your package is not too bad..but in general I am in favour of minimizing dpendencies;-)

I will try compile and run something later so I can comment more substantially...

[warrickball]

@MariaTsantaki I've just tried to install the program following the instructions on the GitHub repo. Like @ipelupessy, it shouldn't be necessary to install with sudo, so I had a look at the top-level makefile, on which I have several comments.

First, this doesn't make use of any of Make's dependency handling and doesn't do anything more than a bash script, so if the script remains necessary I think you should just run it as a bash script. But the contents are so simple that it would be better off as simple installation instructions.

Secondly, the cp and subsequent rm commands are equivalent to mv, so you could just use that. In fact, it'd make more sense to me to do

cd FASMA/models
tar -zxvf apogee_kurucz.tar.gz
tar -zxvf marcs.tar.gz
cd ../..

With the pip install listed in an instructions page, the user can decide whether to use pip install with or without the --user flag or sudo.

I'm also having trouble installing MOOG but, since that's actually stopping me from progressing, I've opened an issue in the repo itself.

[warrickball]

@MariaTsantaki I see that the install procedure calls for editing the source code of MOOG by hand and then build/installing this seperately; it would be nicer if the setup.py does this for you (both things). Also the model data extraction can also be put in the setup.py. fixing this would allow a pip install FASMA

I'm not familiar with everything that setup.py can do but if it can handle extracting the atmosphere tables and perhaps even installing MOOG, then I agree that's the best way to handle installation (which would override my remarks above).

[ipelupessy]

@MariaTsantaki as @warrickball remarked, the installation instructions are not complete. You need sm plotting package. I am not sure the plotting is needed; in any case it compiles if you add a .f file with stubs for the sm calls.

Then, when running fasma, MOOG fails because missing data (Barklem.dat), I pulled this from https://github.com/hmtabernero/StePar (there is also a stub library for sm there; I don't think this lib works as a general solution because it is written in c and assumes a particular fortran name mangling), after this it seems to work.

[ipelupessy]

some comments on running:

• the configuration with StarMe_synth.cfg is not very intuitive; it seems to need a particular formatting; it would be better if you could provide these through python keyword arguments directly
• I made a cfg file with just the following:

# this is a header (all special characters will act as header/comments)
# linelist teff logg [M/H] vt vmac vsini options
giraffe_sun_arcturus_calib.lst

fasma then complaints about a missing intervals file. so i copied over intervals.lst. it still complained. Error reporting doesn't actually tell me which file was missing, added this in the error message (see PR MariaTsantaki/FASMA-synthesis#13 ). turns out the default suggested by the documentation is not correct (intervals_hr10_15n.lst)

• after this MOOG, fasma complained about missing summary.out. It turns out MOOG was giving an error about missing data. By default the output of MOOG is hidden though, so you would not know. This is not good behaviour - you can hide the errors, but then you should catch and act on them, or just report the output of MOOG (PR do not hide MOOG output MariaTsantaki/FASMA-synthesis#14)
• with the data (Barklem.dat) installed in the proper location, fasma runs and finishes. The output
  files synthresults.dat and synthresults_elements.dat are empty apart from the header. I am not sure
  this is an error of some sort or expected behaviour...
• fasma seems to be made to run in a particular location; for this sort of tool you want to be able to run it in some seperate project folder...(I ran in a test folder, I had to link everything through). It would be better if the needed file locations are pulled from the installation dirs.

[ipelupessy]

@MariaTsantaki some further comments:
for this kind of wrapping it is nice if you can continue from within python with the results - so like:
result = fasma(**kwargs)
with kwargs the options as keyword arguments (as mentioned above) and result a python object encapsulating the output with some metadata. Now you are going to have to parse data files in some obscure format...

[ipelupessy]

MariaTsantaki/FASMA-synthesis#15 contains the above mentioned stub for sm

[MariaTsantaki]

Hi all,
Thank you for the comments! They are very useful. I am implementing them and it may take me some time.

[MariaTsantaki]

Dear reviewers,
Thank you very much for the comments. They helped to improve the code. The major changes were on the setup, how FASMA function works in scripts, and the configuration file. This version seems easier to work with.

1. The configuration file (renamed from StarMe.cfg to config.yml) has now a yaml format with all the keys/options available. The file contains the default options.

2. There were some classes renamed and as suggested, now FASMA can accept options and update the default ones.
   e.g.

from FASMA import FASMA 
options = {'teff':4500, 'fix_teff':True}
result = FASMA(**options)

3. Setting up MOOG is tricky, hopefully now it will work better. The shell script install_fasma.sh will fill the moog path but will ask for the system type. There is a hidden limit for the length of the path characters though for fortran. I commented out the places where sm was used. I checked installed FASMA for versions with and without sudo: pip install . and pip install --user .
   They both work but I leave it as the first for now.

There were indeed some dependencies which were not used and now are removed. Unfortunately, I could not remove for instance astropy as it manipulates fits files and I am not familiar with other methods dealing with them.

A good test (once installation runs fine) will be to adapt the config.yml with the correct paths (for linelist, intervals_file, observations) and change the option 'minimize' to True. Then by running fasma the parameters of the Sun will be obtained!

Thank you very much for your time!

[warrickball]

The test run of the Sun runs fine but I tried to run using a HARPS spectrum of HD38529 that I downloaded off the ESO Archive and got the error

/home/wball/.local/lib/python3.7/site-packages/pyfits/__init__.py:22: PyFITSDeprecationWarning: PyFITS is deprecated, please use astropy.io.fits
  PyFITSDeprecationWarning)  # noqa
Traceback (most recent call last):
  File "/home/wball/.local/bin/fasma", line 12, in <module>
    driver = FASMA.FASMA(cfgfile=cfgfile, overwrite=None)
  File "/home/wball/.local/lib/python3.7/site-packages/FASMA/synthDriver.py", line 49, in __init__
    self.synthdriver()
  File "/home/wball/.local/lib/python3.7/site-packages/FASMA/synthDriver.py", line 530, in synthdriver
    for (self.initial, self.options) in self._genStar():
  File "/home/wball/.local/lib/python3.7/site-packages/FASMA/synthDriver.py", line 124, in _genStar
    self._setup(line)
  File "/home/wball/.local/lib/python3.7/site-packages/FASMA/synthDriver.py", line 104, in _setup
    self._options(line)
  File "/home/wball/.local/lib/python3.7/site-packages/FASMA/synthDriver.py", line 245, in _options
    defaults['snr'] = snr(defaults['observations'])
  File "/home/wball/.local/lib/python3.7/site-packages/FASMA/observations.py", line 286, in snr
    snr = [sub_snr(snr_region) for snr_region in snr_regions]
  File "/home/wball/.local/lib/python3.7/site-packages/FASMA/observations.py", line 286, in <listcomp>
    snr = [sub_snr(snr_region) for snr_region in snr_regions]
  File "/home/wball/.local/lib/python3.7/site-packages/FASMA/observations.py", line 247, in sub_snr
    wave_cut, flux_cut, l = read_observations(fname, w1, w2)
  File "/home/wball/.local/lib/python3.7/site-packages/FASMA/observations.py", line 122, in read_observations
    start_wave = header['CRVAL1']  # initial wavelenght
  File "/home/wball/.local/lib/python3.7/site-packages/astropy/io/fits/header.py", line 148, in __getitem__
    card = self._cards[self._cardindex(key)]
  File "/home/wball/.local/lib/python3.7/site-packages/astropy/io/fits/header.py", line 1708, in _cardindex
    raise KeyError(f"Keyword {keyword!r} not found.")
KeyError: "Keyword 'CRVAL1' not found."

I presume that FASMA expects the spectrum to be in a particular format (that includes the CRVAL1 key in the FITS header) but this isn't documented anywhere.

Here are the contents of hd38529_harps.yml:

$ cat hd38529_harps.yml
# 
star1: 
    linelist: /home/wball/work/FASMA-synthesis/FASMA/rawLinelist/linelist.lst 
    teff: 5578
    logg: 3.832
    feh: 0.338
    vt: 1.0
    vmac: 3.21
    vsini: 1.90
    model: apogee_kurucz
    MOOGv: 2014
    save: False
    element: False
    fix_teff: False
    fix_logg: False
    fix_feh: False
    fix_vt: False
    fix_vmac: False
    fix_vsini: False
    plot: True
    plot_res: False
    damping: 1
    step_wave: 0.01
    step_flux: 3.0
    minimize: True
    refine: False
    observations: /home/wball/Downloads/ADP.2018-11-14T01_07_37.242.fits
    intervals_file: /home/wball/work/FASMA-synthesis/FASMA/rawLinelist/intervals.lst 
    snr: null
    resolution: 115000
    limb: 0.6

[ipelupessy]

I managed to install and run with the provided instructions. The path limit is annoying; I have made a PR (MariaTsantaki/FASMA-synthesis#17) to fix this..it adds another change in the MOOG source though (maybe its good to communicate it upstream to MOOG developer)

I can confirm @warrickball problem; I think the fits file does have a WAVELMIN keyword in the header with the smae info as CRVAL1 ??

[ipelupessy]

one comment about the code paper proof: it doesn't mention what the improvement/changes are from the previous published version. I think this is needed.

[ipelupessy]

The following issues are open from my checklist:

Functionality.Functionality: related to documentation below I am not sure what all the functionality of the packages is;

Documentation.A statement of need: Its not clearly stated what the problem the software is designed to solve, e.g.: "FASMA delivers the atmospheric stellar parameters (effective temperature, surface gravity, metallicity, microturbulence, macroturbulence, rotational velocity) and chemical abundances of 12 elements." -> from what? Reader has to guess. What is the fundamental method of the package (multidimensional fit?)

Documentation.Functionality documentation: The manual provides a description of the configuration file. missing is a high level description of what the config.yml is needed for (e.g.: "The configuration file provides the input for the fitting procedure and..?")

Documentation.Automated tests: please provide if there are any tests beyond the basic example. (if not its ok)

Documentation.Community guidelines: not clear how to contribute

Software paper.Summary: atm is geared to specialist. Please provide one or two lines describing the software for non-specialist

Software paper.A statement of need: both the problem and the audience can be clarified a bit more

These are not huge issues, but I think they should be adressed to make the functionality of the software a bit more clear.

This concludes my review.

[whedon]

OK. 10.5281/zenodo.3885291 is the archive.

[xuanxu]

@whedon accept

[whedon]

Attempting dry run of processing paper acceptance...

[whedon]

Reference check summary:

OK DOIs

- 10.18727/0722-6691/5117 is OK
- 10.1117/12.2055132 is OK
- 10.1051/0004-6361/201321844 is OK
- 10.1051/0004-6361/201629967 is OK
- 10.1051/0004-6361/201935465 is OK
- 10.1051/aas:1996222 is OK
- 10.1051/0004-6361/201423945 is OK
- 10.1086/152374 is OK
- 10.1051/0004-6361:200809724 is OK
- 10.1093/mnras/stx2564 is OK
- 10.1051/0004-6361/201527120 is OK
- 10.1051/0004-6361/201425433 is OK
- 10.1137/0111030 is OK
- 10.1088/0031-8949/90/5/054005 is OK

MISSING DOIs

- None

INVALID DOIs

- None

[whedon]

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

Check final proof 👉 openjournals/joss-papers#1469

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

@whedon accept deposit=true

[kyleniemeyer]

Hi @MariaTsantaki, we are about ready to wrap this up, but in my review of the article I encountered some minor issues. Could you address these and let us know when you have done so?

• missing comma after "i.e." in the first and fourth paragraphs
• missing comma after the "e.g."s in the second paragraph
• Fortran should be capitalized
• the Tsantaki et al. 2018 citation should probably be changed from "... in (Tsantaki et al., 2018)" to "... by Tsantaki et al. (2018)", by changing in [@Tsantaki:2018] to by @Tsantaki:2018
• missing comma after "Li" in the list of elements on the second page
• it looks like a number of the references are missing the journal names: Adibekyan 2015, Andreasen 2017, Blanco-Cuaraesma 2014, Delgado 2015, Gustafsson 2008, Magrini 2013, Ryadchikova 2015, Sneden 1973, Tabernero 2019, Tsantaki 2018

Thanks!

[MariaTsantaki]

Done

[kyleniemeyer]

@whedon generate pdf

[whedon]

👉 Check article proof 📄 👈

[kyleniemeyer]

@whedon accept

[whedon]

Attempting dry run of processing paper acceptance...

[whedon]

Reference check summary:

OK DOIs

- 10.18727/0722-6691/5117 is OK
- 10.1117/12.2055132 is OK
- 10.1051/0004-6361/201321844 is OK
- 10.1051/0004-6361/201629967 is OK
- 10.1051/0004-6361/201935465 is OK
- 10.1051/aas:1996222 is OK
- 10.1051/0004-6361/201423945 is OK
- 10.1086/152374 is OK
- 10.1051/0004-6361:200809724 is OK
- 10.1093/mnras/stx2564 is OK
- 10.1051/0004-6361/201527120 is OK
- 10.1051/0004-6361/201425433 is OK
- 10.1137/0111030 is OK
- 10.1088/0031-8949/90/5/054005 is OK
- 10.1051/0004-6361/201322068 is OK
- 10.3847/1538-3881/aabc4f is OK

MISSING DOIs

- None

INVALID DOIs

- None

[kyleniemeyer]

@whedon accept

[whedon]

Attempting dry run of processing paper acceptance...

[whedon]

Reference check summary:

OK DOIs

- 10.18727/0722-6691/5117 is OK
- 10.1117/12.2055132 is OK
- 10.1051/0004-6361/201321844 is OK
- 10.1051/0004-6361/201629967 is OK
- 10.1051/0004-6361/201935465 is OK
- 10.1051/aas:1996222 is OK
- 10.1051/0004-6361/201423945 is OK
- 10.1086/152374 is OK
- 10.1051/0004-6361:200809724 is OK
- 10.1093/mnras/stx2564 is OK
- 10.1051/0004-6361/201527120 is OK
- 10.1051/0004-6361/201425433 is OK
- 10.1137/0111030 is OK
- 10.1088/0031-8949/90/5/054005 is OK
- 10.1051/0004-6361/201322068 is OK
- 10.3847/1538-3881/aabc4f is OK

MISSING DOIs

- None

INVALID DOIs

- None

[whedon]

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

Check final proof 👉 openjournals/joss-papers#1476

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

@whedon accept deposit=true

[kyleniemeyer]

@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:

0. Check final PDF and Crossref metadata that was deposited 👉 Creating pull request for 10.21105.joss.02048 joss-papers#1477
1. Wait a couple of minutes to verify that the paper DOI resolves https://doi.org/10.21105/joss.02048
2. If everything looks good, then close this review issue.
3. Party like you just published a paper! 🎉🌈🦄💃👻🤘

Any issues? notify your editorial technical team...

[kyleniemeyer]

Congrats @MariaTsantaki on your article's publication in JOSS!

Many thanks to @warrickball and @ipelupessy for reviewing this, and @xuanxu for editing.

[whedon]

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

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

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

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