xnemogcm

[rcaneill]

as discussed in #154 I make a full submission

Submitting Author: Romain Caneill (@rcaneill)
All current maintainers: (@rcaneill)
Package Name: xnemogcm
One-Line Description of Package: Interface to open NEMO global circulation model output dataset with xarray and create a xgcm grid.
Repository Link: https://github.com/rcaneill/xnemogcm/
Version submitted: 0.4.2
Editor: @ocefpaf
Reviewer 1: @paigem
Reviewer 2: @callumrollo
Archive:
Version accepted: 0.4.3
JOSS DOI: N/A
Date accepted (month/day/year): 04/02/2024

---

Code of Conduct & Commitment to Maintain Package

• I agree to abide by pyOpenSci's Code of Conduct during the review process and in maintaining my package after should it be accepted.
• I have read and will commit to package maintenance after the review as per the pyOpenSci Policies Guidelines.

Description

xnemogcm is an interface to open NEMO ocean global circulation model output dataset and create a xgcm grid. NEMO 3.6, 4.0, and 4.2.0 are tested and supported. It can handle large simulations, is aware of meshgrid files, and makes it easy to handle the netCDF outputs od NEMO.

Scope

• Please indicate which category or categories.
  Check out our package scope page to learn more about our
  scope. (If you are unsure of which category you fit, we suggest you make a pre-submission inquiry):

  • Data retrieval
  • Data extraction
  • Data processing/munging
  • Data deposition
  • Data validation and testing
  • Data visualization[^1]
  • Workflow automation
  • Citation management and bibliometrics
  • Scientific software wrappers
  • Database interoperability

Domain Specific & Community Partnerships

- [ ] Geospatial
- [ ] Education
- [x] Pangeo

Community Partnerships

If your package is associated with an
existing community please check below:

• Pangeo

  • My package adheres to the Pangeo standards listed in the pyOpenSci peer review guidebook

• For all submissions, explain how the and why the package falls under the categories you indicated above. In your explanation, please address the following points (briefly, 1-2 sentences for each):

xnemogcm extracts the NEMO output and adds metadata (+ do some other things as change coordinate names, etc), and produces new xarray datasets. It is thus data processing.

• Who is the target audience and what are scientific applications of this package?

The target audience is anyone working with NEMO outputs and python. The scientific applications are any analyse that one want to do with NEMO outputs.

• Are there other Python packages that accomplish the same thing? If so, how does yours differ?

Yes, xorca. My package differs as 1) it is more recent, updated to work with newer versions of NEMO, and 2) it uses a very different method to sort variables on the proper grid point (center, face, etc) (cf https://xgcm.readthedocs.io/en/latest/grids.html). xorca uses hardcoded variables, while xnemogcm uses attributes (either output directly by NEMO, or they can also be given while calling the processing functions).

• If you made a pre-submission enquiry, please paste the link to the corresponding issue, forum post, or other discussion, or @tag the editor you contacted:

I made a pre-submission enquiry, issue #154

Technical checks

For details about the pyOpenSci packaging requirements, see our packaging guide. Confirm each of the following by checking the box. This package:

• does not violate the Terms of Service of any service it interacts with.
• uses an OSI approved license.
• contains a README with instructions for installing the development version.
• includes documentation with examples for all functions.
• contains a tutorial with examples of its essential functions and uses.
• has a test suite.
• has continuous integration setup, such as GitHub Actions CircleCI, and/or others.

Publication Options

• Do you wish to automatically submit to the Journal of Open Source Software? If so:

JOSS Checks

• The package has an obvious research application according to JOSS's definition in their submission requirements. Be aware that completing the pyOpenSci review process does not guarantee acceptance to JOSS. Be sure to read their submission requirements (linked above) if you are interested in submitting to JOSS.
• The package is not a "minor utility" as defined by JOSS's submission requirements: "Minor ‘utility’ packages, including ‘thin’ API clients, are not acceptable." pyOpenSci welcomes these packages under "Data Retrieval", but JOSS has slightly different criteria.
• The package contains a paper.md matching JOSS's requirements with a high-level description in the package root or in inst/.
• The package is deposited in a long-term repository with the DOI:

Note: JOSS accepts our review as theirs. You will NOT need to go through another full review. JOSS will only review your paper.md file. Be sure to link to this pyOpenSci issue when a JOSS issue is opened for your package. Also be sure to tell the JOSS editor that this is a pyOpenSci reviewed package once you reach this step.

Are you OK with Reviewers Submitting Issues and/or pull requests to your Repo Directly?

This option will allow reviewers to open smaller issues that can then be linked to PR's rather than submitting a more dense text based review. It will also allow you to demonstrate addressing the issue via PR links.

• Yes I am OK with reviewers submitting requested changes as issues to my repo. Reviewers will then link to the issues in their submitted review.

Confirm each of the following by checking the box.

• I have read the author guide.
• I expect to maintain this package for at least 2 years and can help find a replacement for the maintainer (team) if needed.

Please fill out our survey

• Last but not least please fill out our pre-review survey. This helps us track
  submission and improve our peer review process. We will also ask our reviewers
  and editors to fill this out.

P.S. Have feedback/comments about our review process? Leave a comment here

Editor and Review Templates

The editor template can be found here.

The review template can be found here.

[ocefpaf]

Editor in Chief checks

Hi there! Thank you for submitting your package for pyOpenSci
review. Below are the basic checks that your package needs to pass
to begin our review. If some of these are missing, we will ask you
to work on them before the review process begins.

Please check our Python packaging guide for more information on the elements
below.

• Installation The package can be installed from a community repository such as PyPI (preferred), and/or a community channel on conda (e.g. conda-forge, bioconda).
  • The package imports properly into a standard Python environment import package.
• Fit The package meets criteria for fit and overlap.
• Documentation The package has sufficient online documentation to allow us to evaluate package function and scope without installing the package. This includes:
  • User-facing documentation that overviews how to install and start using the package.
  • Short tutorials that help a user understand how to use the package and what it can do for them.
  • API documentation (documentation for your code's functions, classes, methods and attributes): this includes clearly written docstrings with variables defined using a standard docstring format.
• Core GitHub repository Files
  • README The package has a README.md file with clear explanation of what the package does, instructions on how to install it, and a link to development instructions.
  • Contributing File The package has a CONTRIBUTING.md file that details how to install and contribute to the package.
  • Code of Conduct The package has a CODE_OF_CONDUCT.md file.
  • License The package has an OSI approved license.
    NOTE: We prefer that you have development instructions in your documentation too.
• Issue Submission Documentation All of the information is filled out in the YAML header of the issue (located at the top of the issue template).
• Automated tests Package has a testing suite and is tested via a Continuous Integration service.
• Repository The repository link resolves correctly.
• Package overlap The package doesn't entirely overlap with the functionality of other packages that have already been submitted to pyOpenSci.
• Archive (JOSS only, may be post-review): The repository DOI resolves correctly.
• Version (JOSS only, may be post-review): Does the release version given match the GitHub release (v1.0.0)?

---

• Initial onboarding survey was filled out
  We appreciate each maintainer of the package filling out this survey individually. 🙌
  Thank you authors in advance for setting aside five to ten minutes to do this. It truly helps our organization. 🙌

---

---

Editor comments

[rcaneill]

Hi @ocefpaf,
thanks for taking care of this review :)

I can directly mention that some requirements are not fulfilled:

• API documentation: not done
• CONTRIBUTING.md: not done
• CODE_OF_CONDUCT.md: not done
• Issue Submission Documentation: not done

As far as I can say, the other requirements should be fulfilled.

[ocefpaf]

That's awesome! Here are a few minor comments/questions I have after the first pass:

• You mentioned that the GH repo is a mirror of a Gitlab one. IMO this dual repo usually leads to abandoned PRs in one place and/or stale code somewhere. Let alone the confusion to those finding the Software via search engines. I'm not against this setup and sometimes there are strong reasons to do so. However, if that can be avoided, it usually provides a smoother experience to all.
• Are you publishing the docs somewhere? I could not find them. I understand that the API docs are not ready but you do have some examples that can be the first form of user facing docs.
• I started checking the boxes above. Please let me know if I missed one that is already done.

[rcaneill]

That's awesome! Here are a few minor comments/questions I have after the first pass:

• You mentioned that the GH repo is a mirror of a Gitlab one. IMO this dual repo usually leads to abandoned PRs in one place and/or stale code somewhere. Let alone the confusion to those finding the Software via search engines. I'm not against this setup and sometimes there are strong reasons to do so. However, if that can be avoided, it usually provides a smoother experience to all.

Maybe the README is not so clear, the github is mirrored to gitlab (not from gitlab). The reason is that I do not want to force anyone to use github. But I could remove the sentence and keep my email address only.

• Are you publishing the docs somewhere? I could not find them. I understand that the API docs are not ready but you do have some examples that can be the first form of user facing docs.

No, I did not publish the doc anywhere. I started all the readthedoc machinery, but realised that having only these few examples was sufficient. As this packages has been developed only by me, I also had a lot to learn and a proper website for the doc was not urgent.

I can work on a proper website for the doc during this review process. I do not aim to change the content of the examples (unless I get comments from the reviewers), so I think the review can start without this implemented yet.

• I started checking the boxes above. Please let me know if I missed one that is already done.

[ocefpaf]

Maybe the README is not so clear, the github is mirrored to gitlab (not from gitlab). The reason is that I do not want to force anyone to use github. But I could remove the sentence and keep my email address only.

I understand. By making a choice we always end up making some folks unhappy. In my experience, mirroring like that always brings headaches in the long run. With that said, this is not important for your application here and you don't need to change that for PyOS.

I can work on a proper website for the doc during this review process. I do not aim to change the content of the examples (unless I get comments from the reviewers), so I think the review can start without this implemented yet.

@rcaneill we usually only start the review after all those points are checked. The reason is b/c the reviewers will read those docs and give you some feedback. Let me know if you need help setting docs, examples, etc in your repo. Once we are done I'll find two reviewers for your project and start the review process.

[rcaneill]

@rcaneill we usually only start the review after all those points are checked. The reason is b/c the reviewers will read those docs and give you some feedback. Let me know if you need help setting docs, examples, etc in your repo. Once we are done I'll find two reviewers for your project and start the review process.

Ok I understand, I will try to check all boxes in the following weeks!

[rcaneill]

Hi @ocefpaf , I updated the xnemogcm github repository, everything should be checked now! :D

[ocefpaf]

@rcaneill there seems to be a documentation build problem in page https://xnemogcm.readthedocs.io/en/latest/examples/recombing_mesh_mask_domain_cfg/

Also, some of your syntax there is not Windows friendly and users that copy-n-paste may find themselves with errors. Those are not blockers for us to continue but I wanted to give that feedback here before I forget.

We are now looking for 2 reviewers to start the process. Thank you!

[rcaneill]

@rcaneill there seems to be a documentation build problem in page https://xnemogcm.readthedocs.io/en/latest/examples/recombing_mesh_mask_domain_cfg/

thanks for catching this, it is now corrected.

Also, some of your syntax there is not Windows friendly and users that copy-n-paste may find themselves with errors. Those are not blockers for us to continue but I wanted to give that feedback here before I forget.

Are you speaking about the ls commands in the notebooks? If yes, I can change and use python instead.