PySDM future developers/users @ LEAP

[claresinger]

Discussion on Friday, Jan 26
with: @slayoo @claresinger @jtbuch @kdlamb @kaitlyn-loftus @josephko91 @magpowell

from Sylwester: "contributions welcome":

• new examples (including smoke tests)
• new tutorials (e.g. for course material)
• new physics (e.g. mixed phase, isotopes, ventilation, collision kernels)
• new products (e.g. autoconversion/accretion/washout rates)
• new environments (e.g. cloud chamber)
• hardware-related (Numba ARM atomics, GPU support)
• reviewing/extending documentation (incl. moving-sectional perspective)
• LES coupling (https://github.com/pnnl/pinacles)
• super-particle sources (nucleation, seeding, emissions, or adaptive resolution)
• logo!

interests:

• coupling to radiative transfer (one possible pure python idea: https://github.com/LDEO-CREW/Pythonic-DISORT/tree/main)
• aerosol definitions
• ice processes: depositional growth
• coupling to PyPartMC
• dev hints here: https://github.com/open-atmos/python-dev-hints/wiki
• better documentation for getting started and how to make new contributions

[jtbuch]

Thanks for a great discussion and seminar, @slayoo!

[slayoo]

Thank you All for organising the meeting and the discussion!

As a first "code follow up", here's a PR adding to PySDM the ice-vapour equilibrium fractionation factor formula for deuterium from Lamb et al. 2017 + new Jupyter example notebook reproducing Fig. 4 from this paper:

• PR: adding new isotope equil. fractionation factor formulae for ice-vap 2H (LambEtAl2017, EllehojEtAl2013) + new example notebook (Fig. 4 from Lamb et al. 2017, PNAS) #1271
• Github notebook preview: https://github.com/slayoo/PySDM/blob/lamb_et_al_2017_pnas/examples/PySDM_examples/Lamb_et_al_2017/fig_4.ipynb
• Colab notebook preview (execution will only work after merging and releasing new PyPI package): https://colab.research.google.com/github/slayoo/PySDM/blob/lamb_et_al_2017_pnas/examples/PySDM_examples/Lamb_et_al_2017/fig_4.ipynb

@kdlamb, your feedback and approval would be much appreciated!

Hope this also gives an example of how the code layout in PySDM for formulae looks like, and how to add a new formula exemplified with a notebook and covered with a basic test.

To All: ideas for next examples warmly welcome! (@kaitlyn-loftus, rainprops? -> https://github.com/kaitlyn-loftus/rainprops)

[kaitlyn-loftus]

Thanks, this is very helpful, @slayoo!! I will try to submit a PR with a ventilation coefficient formula soon.

Also is it preferred that all constants associated with a given formula should go into PySDM/physics/constants_defaults.py rather than the formula method?

[kdlamb]

This looks good to me!

[slayoo]

Thanks @kdlamb, merged!

@kaitlyn-loftus, yes we essentially avoid using any numeric literals within formulae for several reasons (just added the points below to a docstring: f30747c):

• it makes it possible for a user to override value of any constant by passing a constants dictionary to the __init__ of Formulae;
• it enforces floating-point cast on all constant values making the code behave in the same way on both CPU and GPU backends, the latter being based on Python-generated C code (e.g., const.ONE/const.TWO instead of 1/2 makes it behave consistently);
• it enables dimensional analysis logic if the code in question is embedded in with DimensionalAnalysis: block - allows checking physical unit consistency within unit tests (disabled by default, no runtime overhead), see e.g.: https://github.com/open-atmos/PySDM/blob/main/tests/unit_tests/physics/test_formulae.py#L68-L82;
• last but not least, it forces us to name all the newly introduced constants (thus resulting in more readable, and more likely reusable code).

[kaitlyn-loftus]

This is super helpful. Thank you for clarifying. I have a few more questions….

Where would be the best place to put calculations for:
air dynamic viscosity
particle Reynolds number ?

Is there a reason there isn’t a ONE_HALF constant?

Do different classes within the same folder (formulae representing the same property) need to have the same arguments?

Thanks!!!

[slayoo]

Where would be the best place to put calculations for:
air dynamic viscosity
particle Reynolds number ?

I'd start with putting everything in one file, making a test that uses all of the new functions and asserts on the output, and then we can brainstorm and refactor leveraging that the test will check if all still works as it used to. So, if that is ventilation, we could start with the already existing (yet effectively empty) PySDM/physics/ventilation/ subfolder.

Is there a reason there isn’t a ONE_HALF constant?

I guess, we use /2 in many places instead, but of course why not to add! :)

Do different classes within the same folder (formulae representing the same property) need to have the same arguments?

Exactly - methods of the same name should have the same arguments. But, as it is done in many cases, different classes might have different sets of methods, which are later grouped together via inheritance (see, e.g., https://github.com/open-atmos/PySDM/blob/main/PySDM/physics/diffusion_kinetics/lowe_et_al_2019.py which inherits from PruppacherKlett and adds two more methods)

Two things worth highlighting:

• all methods within the physics subsystem should, in principle, be one-liners (one of the reasons being that these are used both as Python code within the CPU backend, but also are automagically converted to C for use with CUDA)
• if one method needs to use ouput from another, this needs to be handled by the user in the calling code (which usually anyhow makes sense, as the memory needed for any sotrage needs to be differently allocated for CPU and GPU)

Thank you, @kaitlyn-loftus

[slayoo]

BTW, we have also a Wiki where we try to maintain hints for development of projects at github.com/open-atmos: https://github.com/open-atmos/python-dev-hints/wiki - if there's anything worth adding, clarifying, etc - let us know!

[slayoo]

Let's note here that the particle seeding functionality proposed by @jtbuch and engineered together with @claresinger is now part of PySDM (see #1367)!