Closed whedon closed 5 years ago
Hello human, I'm @whedon, a robot that can help you with some common editorial tasks. @FaustinCarter, it looks like you're currently assigned as the reviewer for this paper :tada:.
:star: Important :star:
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:
For a list of things I can do to help you, just type:
@whedon commands
Attempting PDF compilation. Reticulating splines etc...
π @FaustinCarter, @josephhardinee, @PaulKGrimes β This is where the action happens. You can read about the JOSS Review Process in our documentation. Feel free to ask any questions here, and to open issues in the target repo, as needed.
I've had a go at installing it and had some issues. I'll drop them here now so they can be addressed in parallel with other things.
Attempts at installation:
conda search foo
. Recommendation is to just specify version numbers and let conda sort out which system-specific repo it should pull from.I also ran the tests, which all passed on the first go-around. You might mention in the documentation for the tests that pytest is a dependency that needs to be separately installed in order to use.
Another issue that I see right away is that the documentation doesn't have an API section that contains all the class and function docs. I scanned through the major class docstrings and they appear to be generally in good shape, so I think you can get this most of the way there with Sphinx's autodoc feature.
OK, that's all for now. More as I work through the code base. Once the installation issues are fixed I'll tick that box above in the review.
John has fixed the environment.yml file, and replaced it with environment-qmix.yaml in the repository. The environment creation is currently working on both my Windows 10 Anaconda installs, miniconda on Ubuntu WSL and Anaconda on CentOS 7, although I have to run python setup.py install from the qmix directory after creating the environment.
The pip installer issue looks like an issue with non-standard quotation marks and hyphens in the second reference in README.md - that's often a risk when cutting and pasting references. The pip install method works on Ubuntu WSL and CentOS, so this is a Windows specific issue.
Paul
On Tue, Feb 5, 2019 at 12:08 AM Faustin Carter notifications@github.com wrote:
I've had a go at installing it and had some issues. I'll drop them here now so they can be addressed in parallel with other things.
Attempts at installation:
- I can't use the included environment.yml file on Windows. I'm not sure if this is Windows-specific, but the yml file specifies the exact hash to use for each package version and those don't match the ones I see when I do conda search foo. Recommendation is to just specify version numbers and let conda sort out which system-specific repo it should pull from.
- Straight-up pip install in fresh conda environment (with just python 3.7) failed also because of error trying to read in the long description in setup.py from README.md, which has some non-readable characters (i.e. images?). This suggests the code on PyPI is not the same as the latest code in master on github. However, they both have the same version number, 1.0.0. Recommend bumping the version to 1.0.1 and reuploading to PyPI (and also creating a new release in github to trigger a Zenodo update).
- Trying pip install -e from source... Success! So the current code installs fine after a download and local build.
I also ran the tests, which all passed on the first go-around. You might mention in the documentation for the tests that pytest is a dependency that needs to be separately installed in order to use.
Another issue that I see right away is that the documentation doesn't have an API section that contains all the class and function docs. I scanned through the major class docstrings and they appear to be generally in good shape, so I think you can get this most of the way there with Sphinx's autodoc feature.
OK, that's all for now. More as I work through the code base. Once the installation issues are fixed I'll tick that box above in the review.
β You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/openjournals/joss-reviews/issues/1231#issuecomment-460514835, or mute the thread https://github.com/notifications/unsubscribe-auth/AafsycG5tnT5XwEPz21DYZQwRWae13mpks5vKRHmgaJpZM4ah6f3 .
-- Receiver Laboratory Smithsonian Astrophysical Observatory 60 Garden St, Cambridge, MA 02138 +1 (617) 496-7640
Hi @FaustinCarter, thank you for your feedback.
As Paul mentioned, I have updated the environment file so that it should work on Windows now. I was previously using conda env export > environment.yml
to generate the environment.yml file, but this doesn't work across different platforms. I have rewritten the environment to only include the necessary packages without specifying versions or build codes.
I've also fixed the issue with the setup.py
file. I was previously reading in README.md
in order to generate the description for setup.py
, but README.md
contained some non-ASCII characters. I have now rewritten the description so that this doesn't happen anymore.
I'll take a look at adding the API for the functions and classes ASAP.
I have been able to confirm the operation of the experimental data analysis and impedance fitting example using my own experimental data. This appears to work fairly well, and gives results as expected. There could be some enhancements made to the software to make loading data from a variety of file types simpler - right now the data has to be reformatted to the style of data file used by John.
I have also been able to recreate some of the figures from my PhD thesis, calculating the mixer conversion gain and pumped IV curves for a 4 tone mixer (LO, USB, LSB and IF tones) which used a completely different multitone harmonic balance code, written by myself. John and I use somewhat different definitions of mixer gain (particularly around the available power at the IF), but the calculated mixer gains are similar. To me, this confirms that the software is operating broadly as expected, and accurately calculating the behavior of the SIS junction when used as a superheterodyne mixer.
However, the QMix code is extremely slow for 4 tones, taking approximately 5 hours to calculate the mixer currents using the standard response function in the multitone examplte. The 3 tone version of the calculation (dropping the lower sideband) finishes in about 3 minutes. I have some ideas about how this performance might be improved, but I don't think that that is necessary at this time since no claims are made about the performance of the software.
I think the only box that I'm not ready to tick is the Community Guidelines box.
Hi @PaulKGrimes, thank you for all your work validating the code. I am interested to hear about how to improve the performance of the 4 tone simulations, but we can talk about that later.
With respect to the Community Guidelines, I added more information to the CONTRIBUTING.md file. I also added a CODE_OF_CONDUCT.md (generated using GitHub's template) and some CODE_GUIDELINES.md.
@whedon set v1.0.1 as version
I'm sorry @garrettj403, I'm afraid I can't do that. That's something only editors are allowed to do.
@whedon generate pdf
Attempting PDF compilation. Reticulating splines etc...
I'm very impressed in general with this package. It does a lot of SIS stuff very neatly, and presents the results in a readable way. I have a few more comments/suggestions and once those are addressed I'll be ready to check the final boxes:
There are a lot of helper functions (resp_swap, for instance) that do specific things, but I don't immediately see why they would be needed. I expect that this is because I am not an SIS mixer expert, but I imagine some new grad student might also not appreciate them fully. It would be good to include at least a minimal use case for all helper functions (i.e. this is useful for doing the following thing). If it is a function the user is not ever really supposed to use (i.e. just for internal Class calculations), consider prepending the function name with an underscore
There are several different response function types. It might be useful to say something about when/why each one ought to be used.
There is a lot of SIS specific jargon that I'm not familiar with. One example is the term "photon voltage". Is that the photon energy divided by electron charge, like it sounds, or something else? Probably this is all well understood by field experts, so I'll defer to the field expert as to whether everything was understandable on the first go. You might consider asking a newish grad student to read through your docs and point out all the terms they are unfamiliar with, but I'm not going to hold you to it!
One of the submodules in your exp sub-package is just a dictionary of default parameter values. Although the comments in the code give some explanation, the auto-doc is very garbled. This needs to be fixed. Also, in Examples 1 and 2, there should be some explicit reference to this default parameter list, or all the values for the toy models should be explicitly passed to the constructors. The less that happens under the hood the better for Examples.
In the experimental data sub-package, there is not a clear specification for what data format is required for both RawData0 and RawData classes. There is a link in the docs to some example data files, but those files do not even have column names, so making inferences is hard.
I recommend the following fixes:
Optionally (and for future reference), I think it is good practice to accept a data structure rather than a file into your routines. For instance, if you accept a numpy.ndarray or a pandas.DataFrame or xarray.Dataset or a python dict of iterables, you would give the user the freedom to load up their data in whatever way they like. You can optionally provide a parser that converts your preferred type of files into that data structure. This saves folks from having to load up their data, save their data in your format, and then reload it from file when they run your code.
All of your plotting routines should return a handle to the matplotlib figure object at a minimum. It is very likely that a user will want to continue to annotate, or plot extra stuff, or take your plot and stick it into a larger figure, and they can't do any of this easily with a saved pdf.
The typical way of handling this is to accept a handle to a matplotlib axis as an optional keyword argument and then:
There are also probably other sane variations on this theme, and I'll happily accept any of them, as long as the user has some way of getting a matplotlib object back from the plotting routines.
@PaulKGrimes β I see you've checked all your review items. Are you ready to recommend publication?
π @josephhardinee β Your checklist is still untouched. Have you been able to get started with this review?
Hi @FaustinCarter, thank you for your detailed review.
I think that I have addressed all of your points now.
General documentation
There are a lot of helper functions (resp_swap, for instance) that do specific things, but I don't immediately see why they would be needed. I expect that this is because I am not an SIS mixer expert, but I imagine some new grad student might also not appreciate them fully. It would be good to include at least a minimal use case for all helper functions (i.e. this is useful for doing the following thing). If it is a function the user is not ever really supposed to use (i.e. just for internal Class calculations), consider prepending the function name with an underscore
qmix.respfn.RespFn
(e.g., resp_conj
).qmix.circuit.EmbeddingCircuit
are a bit more straight-forward, but I added use cases to a couple of the methods (e.g., lock
).There are several different response function types. It might be useful to say something about when/why each one ought to be used.
qmix.respfn.RespFn
module's docstring to describe the different types of response functions.There is a lot of SIS specific jargon that I'm not familiar with. One example is the term "photon voltage". Is that the photon energy divided by electron charge, like it sounds, or something else? Probably this is all well understood by field experts, so I'll defer to the field expert as to whether everything was understandable on the first go. You might consider asking a newish grad student to read through your docs and point out all the terms they are unfamiliar with, but I'm not going to hold you to it!
qmix.circuit.EmbeddingCircuit
class contains the most SIS jargon, so I now describe all of the class attributes in detail (e.g., photon voltage: vph
)). Also, the documentation for qmix.circuit.EmbeddingCircuit
now includes an example of how to initialize and setup the class.One of the submodules in your exp sub-package is just a dictionary of default parameter values. Although the comments in the code give some explanation, the auto-doc is very garbled. This needs to be fixed. Also, in Examples 1 and 2, there should be some explicit reference to this default parameter list, or all the values for the toy models should be explicitly passed to the constructors. The less that happens under the hood the better for Examples.
qmix.exp.parameters.params
. There isn't a good way to document dictionaries, so I just describe the different parameters in the module's docstring.RawData0
here, on lines 4-8.Handling user data
In the experimental data sub-package, there is not a clear specification for what data format is required for both RawData0 and RawData classes. There is a link in the docs to some example data files, but those files do not even have column names, so making inferences is hard.
I recommend the following fixes:
* add column names to the csv files, or at least include them in the readme file (along with expected units) * Explicitly spell out what the expected format is for any data files that the user might want to read in.
Optionally (and for future reference), I think it is good practice to accept a data structure rather than a file into your routines. For instance, if you accept a numpy.ndarray or a pandas.DataFrame or xarray.Dataset or a python dict of iterables, you would give the user the freedom to load up their data in whatever way they like. You can optionally provide a parser that converts your preferred type of files into that data structure. This saves folks from having to load up their data, save their data in your format, and then reload it from file when they run your code.
RawData
and RawData0
so that they now accept data in the form of Numpy arrays (in addition to CSV files). You can see an example here, in Example #3, in lines 12-16.Plotting
All of your plotting routines should return a handle to the matplotlib figure object at a minimum. It is very likely that a user will want to continue to annotate, or plot extra stuff, or take your plot and stick it into a larger figure, and they can't do any of this easily with a saved pdf.
The typical way of handling this is to accept a handle to a matplotlib axis as an optional keyword argument and then:
* if they don't pass in their own axis, just create a new figure, plot stuff up, and return the figure. * if they do pass in their own axis, plot directly on the axis passed in
There are also probably other sane variations on this theme, and I'll happily accept any of them, as long as the user has some way of getting a matplotlib object back from the plotting routines.
Thank you again and please let me know if I missed anything!
Hi Lorena,
Yes, I'm ready to recommend publication.
Paul
On Sun, Mar 10, 2019, 15:56 Lorena A. Barba notifications@github.com wrote:
@PaulKGrimes https://github.com/PaulKGrimes β I see you've checked all your review items. Are you ready to recommend publication?
β You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/openjournals/joss-reviews/issues/1231#issuecomment-471362780, or mute the thread https://github.com/notifications/unsubscribe-auth/Aafsybi67X2IS2LFIuDSOcYzNsH88IXwks5vVY20gaJpZM4ah6f3 .
I am ready to recommend publication. There is one minor issue with software version being off a micro version, but that is just due to updates to the package in response to reviewer comments (1.0.0 to 1.0.2). I'm clicking the checkbox on versions match as I assume the micro versions don't matter as much until final proof is ready.
The documentation is quite nice, with several examples showing usage in the documentation as well as separate notebooks in the repository. The package installed using pip into my general environment with no issues. All tests passed out of the box as well. The contributor guidelines are thorough (code of conduct, contributing, style guidelines, etc). Overall it looks like a pretty good package and installation and usage was straightforward with not even any minor hiccups.
At this point, we just wait on you, @FaustinCarter, to approve the author's last changes, and to tick of the remaining items in your checklist. Please let me know here when you're ready to recommend publication.
I am very happy to recommend publication. This is a really excellent job!
@whedon generate pdf
Attempting PDF compilation. Reticulating splines etc...
@garrettj403 Can you delete the last sentence? The JOSS paper format includes links to the software repository and its archive on the right margin of the first page. We don't include the archive as a citation, but create linked DOIs with the Crossref deposit.
After you do this βοΈ, the next step is to create a tagged release (post the version number here), and update your Zenodo deposit to a new version (no need for a new DOI, just a version). Post the archive DOI here.
Hi @labarba, I've removed the last sentence from paper.md
and issued a new release. The new version number is v1.0.3 and the Zenodo DOI is 10.5281/zenodo.2538162 (for the archive as a whole).
@whedon set v1.0.3 as version
OK. v1.0.3 is the version.
Please edit the metadata of your Zenodo deposit so the title and author list match the JOSS paper.
Okay, I've updated the Zenodo archive. The title and authors now match the JOSS paper.
@whedon set 10.5281/zenodo.2538162 as archive
OK. 10.5281/zenodo.2538162 is the archive.
@whedon accept
Attempting dry run of processing paper acceptance...
Check final proof :point_right: https://github.com/openjournals/joss-papers/pull/567
If the paper PDF and Crossref deposit XML look good in https://github.com/openjournals/joss-papers/pull/567, then you can now move forward with accepting the submission by compiling again with the flag deposit=true
e.g.
@whedon accept deposit=true
OK DOIs
- 10.1063/1.2424407 is OK
- 10.1103/PhysRev.147.255 is OK
- 10.1063/1.1576515 is OK
MISSING DOIs
- None
INVALID DOIs
- None
@whedon accept deposit=true
Doing it live! Attempting automated processing of paper acceptance...
π¨π¨π¨ THIS IS NOT A DRILL, YOU HAVE JUST ACCEPTED A PAPER INTO JOSS! π¨π¨π¨
Here's what you must now do:
Party like you just published a paper! πππ¦ππ»π€
Any issues? notify your editorial technical team...
Congratulations, @garrettj403, your JOSS paper is published π
Huge thanks to the reviewers: @FaustinCarter, @josephhardinee, @PaulKGrimes π
:tada::tada::tada: Congratulations on your paper acceptance! :tada::tada::tada:
If you would like to include a link to your paper from your README use the following code snippets:
Markdown:
[![DOI](http://joss.theoj.org/papers/10.21105/joss.01231/status.svg)](https://doi.org/10.21105/joss.01231)
HTML:
<a style="border-width:0" href="https://doi.org/10.21105/joss.01231">
<img src="http://joss.theoj.org/papers/10.21105/joss.01231/status.svg" alt="DOI badge" >
</a>
reStructuredText:
.. image:: http://joss.theoj.org/papers/10.21105/joss.01231/status.svg
:target: https://doi.org/10.21105/joss.01231
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:
That's fantastic! Thank you for all your help @labarba. Thank you also @PaulKGrimes, @FaustinCarter and @josephhardinee for your work testing QMix and your helpful comments. Overall, this was a very constructive and pleasant review process. Cheers!
Submitting author: @garrettj403 (John Garrett) Repository: https://github.com/garrettj403/QMix/ Version: v1.0.3 Editor: @labarba Reviewer: @FaustinCarter, @josephhardinee, @PaulKGrimes Archive: 10.5281/zenodo.2538162
Status
Status badge code:
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) 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
@FaustinCarter & @josephhardinee & @PaulKGrimes, please carry out your review in this issue by updating the checklist below. If you cannot edit the checklist please:
The reviewer guidelines are available here: https://joss.theoj.org/about#reviewer_guidelines. Any questions/concerns please let @labarba know.
β¨ Please try and complete your review in the next two weeks β¨
Review checklist for @FaustinCarter
Conflict of interest
Code of Conduct
General checks
Functionality
Documentation
Software paper
paper.md
file include a list of authors with their affiliations?Review checklist for @josephhardinee
Conflict of interest
Code of Conduct
General checks
Functionality
Documentation
Software paper
paper.md
file include a list of authors with their affiliations?Review checklist for @PaulKGrimes
Conflict of interest
Code of Conduct
General checks
Functionality
Documentation
Software paper
paper.md
file include a list of authors with their affiliations?