SpeedyWeather / SpeedyWeather.jl

Play atmospheric modelling like it's LEGO.
https://speedyweather.github.io/SpeedyWeather.jl/dev
MIT License
432 stars 27 forks source link

JOSS review: text comments #480

Closed slayoo closed 6 months ago

slayoo commented 6 months ago

reading through the JOSS paper text, I've noted down the following suggestions/comments:

HTH

navidcy commented 6 months ago

@milankl shall open a PR from a new branch -> #387 to try to address the above?

milankl commented 6 months ago
  1. the "monolithic" statements call for reference[s]

I'm adding this as a reference here. "Monolithic architecture" or "application" is widely used in general software engineering not so much in scientific modelling so thanks for pointing it out. With the reference I believe this should be easy to understand, but I extended the sentence a bit to make it clearer

A monolithic interface [@Mazlami2017], controlling most of the model's functionality through arguments of a single function or through parameter files (often called namelists in Fortran), is avoided in favor of a library-style interface.

  1. ditto for "modern trend sees simulations in Fortran and data analysis in Python" - please add reference[s]

Can I push back here? Almost all weather/ocean/climate models are written in Fortran (ICON, IFS, MITgcm, NEMO, GFS/FV3, exceptions I know, using C++, are SCREAM and COSMO) and many people use python for data analysis and visualisation (see also packages in those organisations github/gitlab profiles). I am not aware of any meta study trying to quantify how much in this field is done in which language and I cannot find one searching for it. If you know a reference to add here please let us know!

  1. why is Cartopy cited as "2010-2015"?

That's their official citation recommendation: https://scitools.org.uk/cartopy/docs/latest/citation.html#bibtex-entry

  1. bib: Malardel et al. 2016 - DOI is missing: https://doi.org/10.21957/zwdu9u5i

Added.

navidcy commented 6 months ago
  1. ditto for "modern trend sees simulations in Fortran and data analysis in Python" - please add reference[s]

Can I push back here? Almost all weather/ocean/climate models are written in Fortran (ICON, IFS, MITgcm, NEMO, GFS/FV3, exceptions I know, using C++, are SCREAM and COSMO) and many people use python for data analysis and visualisation (see also packages in those organisations github/gitlab profiles). I am not aware of any meta study trying to quantify how much in this field is done in which language and I cannot find one searching for it. If you know a reference to add here please let us know!

I'm not sure @slayoo actually meant to cite here something that quantifies how many models are in FORTRAN versus other languages. I read their comment as "provide some evidence for this claim". So I would interpret it as satisfactory if we rephrase to something along the lines of, e.g.,

"... modern trend sees simulations in Fortran (see, e.g., here citations for 3-4 FORTRAN models) and data analysis in Python (cite here xarray, dask, xgcm, ... perhaps some other package)."

Thoughts?

slayoo commented 6 months ago

@milankl @navidcy thanks for the follow ups.

As @navidcy comments, indeed my point was to avoid unevidenced/jargon statements such as "Most weather, ocean and climate models" (-> which models?), "From this tradition" (-> what do you mean by tradition?), "specific programming style" (-> what style?). In principle, this is a software engineering journal - many readers might not be acquainted with this particular niche, but would be interested to understand what is the programming style of weather forecasting systems. Similarly, newcomers to weather forecasting would benefit from these sentences having concrete examples provided.

milankl commented 6 months ago

@slayoo can you check whether you are happy with our changes, see pdf here? Let us know if there's other points. I believe I've addressed all points, to summarise

  1. the "monolithic" statements call for reference[s]

I'm adding this as a reference here. "Monolithic architecture" or "application" is widely used in general software engineering not so much in scientific modelling so thanks for pointing it out. With the reference I believe this should be easy to understand, but I extended the sentence a bit to make it clearer

  1. ditto for "modern trend sees simulations in Fortran and data analysis in Python" - please add reference[s]

Added as

Most weather, ocean and climate models are written in Fortran (e.g. ICON [@ICON], CESM [@CESM], MITgcm [@MITgcm], NEMO [@NEMO]) [...] and data analysis in Python (e.g. NumPy [@Numpy], Xarray [@Xarray], Dask [@Dask], Matplotlib [@Hunter2007]),

  1. what is "large-scale condensation"? (and how would it be different from other-scale condensation?)

In atmospheric modelling we talk about "large-scale condensation" when a grid-cell is saturated as you cannot resolve the droplet formation directly and therefore parameterize large-scale condensation when relative humidity is above 100%. I see that this term might be confusing so I've changed these sentences to use "convection" to avoid the confusion and the need to add an explanation, now reads as

To define a new parameterization for convection in a given vertical column of the atmosphere, one would define MyConvection as a new subtype of AbstractConvection. One then only needs to extend the initialize! (executed once during model initialization) and convection! (executed on every time step) functions for this new type. Passing on convection = MyConvection() to the model constructor then implements this new model component without the need to branch off or overwrite existing model components.

  1. why is Cartopy cited as "2010-2015"?

That's their official citation recommendation: https://scitools.org.uk/cartopy/docs/latest/citation.html#bibtex-entry

  1. bib: Malardel et al. 2016 - DOI is missing: https://doi.org/10.21957/zwdu9u5i

Added.

  1. bib: Moses & Churavy 2020 - add clickable link (https://proceedings.neurips.cc/paper_files/paper/2020/file/9332c513ef44b682e9347822c2e457ac-Paper.pdf or https://doi.org/10.48550/arXiv.2010.01709)

Added.

  1. bib: Rasp et al. 2018 - DOI is missing: https://doi.org/10.1073/pnas.1810286115

Added.

  1. bib: Stompor 2011 - add clickable URL: https://ascl.net/1110.013

Added.

  1. bib: Willmert 2020 - use permalink: http://web.archive.org/web/*/https://justinwillmert.com/articles/2020/notes-on-calculating-the-spherical-harmonics/

Added.

  1. paper mentions that "simple parallelization across vertical layers is supported" but README informs also about "grid point-wise [multi-threading] for physics", and CUDA is among the dependencies - please clarify and elaborate

Clarified in the manuscript as

A simple parallelization (across vertical layers for the dynamical core, across horizontal grid points for the parameterizations) is supported by Julia's multithreading. No distributed-memory parallelization is currently supported, GPU support is planned.

And also similarly in the README.

  1. if distributed-memory parallelisation (e.g., MPI) is not supported, please mention it explicitly

See above.

slayoo commented 6 months ago

Thanks!