Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

pre-PR for util for condensation #449

Merged
merged 5 commits into from
Apr 30, 2024
Merged

pre-PR for util for condensation #449

merged 5 commits into from
Apr 30, 2024

Conversation

Gorkowski
Copy link
Collaborator

@Gorkowski Gorkowski commented Apr 30, 2024

Pre-PR with utility changes for condensation PR.

Create a sub util.converting for converting mass_concentration to different representations. This could be used to spread out the current convert.py collection.

Added unitless Knudsen number and mean free path of molecules

@Gorkowski Gorkowski added the next prototype for v1 label Apr 30, 2024
@Gorkowski Gorkowski added this to the v0.1.0 milestone Apr 30, 2024
Copy link

github-actions bot commented Apr 30, 2024

PR Preview Action v1.4.7
🚀 Deployed preview to https://uncscode.github.io/particula/pr-preview/pr-449/
on branch gh-pages at 2024-04-30 23:49 UTC

@Gorkowski Gorkowski marked this pull request as ready for review April 30, 2024 01:13
Copy link
Contributor

@sourcery-ai sourcery-ai bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hey @Gorkowski - I've reviewed your changes and they look great!

Here's what I looked at during the review
  • 🟡 General issues: 3 issues found
  • 🟢 Security: all looks good
  • 🟢 Testing: all looks good
  • 🟢 Complexity: all looks good

Sourcery is free for open source - if you like our reviews please consider sharing them ✨
Help me be more useful! Please click 👍 or 👎 on each comment to tell me if it was helpful.

particula/util/mean_free_path.py Outdated Show resolved Hide resolved
particula/util/tests/knudsen_number_test.py Outdated Show resolved Hide resolved
Copy link
Collaborator

@ngmahfouz ngmahfouz left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Two minor comments (non-blocking, so feel free to merge after reading). I disabled the automerge. See if you want to address the comments, but it's okay to disregard them and reenable the automerge 😸

Comment on lines 15 to 17
- mass_concentrations: A list or ndarray of mass concentrations
(e.g., kg/m^3).
- molar_masses: A list or ndarray of molecular weights (e.g., kg/mol).
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Are we actually giving the users flexibility here? Or are we letting them walk into a trap? 😉

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

In reference to the e.g., which implies other options are valid

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

well, other units are possible if they use this in isolation, then that is the users problem. But, the e.g. was to say how next uses it, and give the base SI units

Comment on lines +30 to +33
if np.any(mass_concentrations < 0):
raise ValueError("Mass concentrations must be positive")
if np.any(molar_masses <= 0):
raise ValueError("Molar masses must be non-zero, positive")
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is it possible to have these be part of the typing? I actually don't know if that's a thing.

In general though, we are repeating a lot of code here, so a good place to consider refactoring. Would a random utility like this work? We can refine it later to include more detailed logging... speaking of which, we need to have al logger, but that's a whole different devops task for me to take on later....

import numpy as np
def enforce_nonneg(*args, where="someplace"):
    for some in args:
        if np.any(some <= 0):
            raise ValueError(
                f"{where}:  must be positive, but got {some} ..."
            )
# enforce_nonneg(1, -5, 6, where="somewhere")

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Also, we need to put a lower limit on numpy to use these new features: https://numpy.org/devdocs/reference/typing.html#typing-numpy-typing (I can take care of that later)

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

logger, yes. As for the abstract, I agree it should be done. It wasn't obvious how many spots in the code this should be done. I think through the PRs for condensation, the abstraction format (how many different checks need/should be done and how similar are they) and usage would become obvious.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

oh, as part of the typing... that sounds cool, but my preference is to stick with standard typing (flaots, np.ndarrays) to help others on board with the code.

@Gorkowski Gorkowski removed the request for review from ngam April 30, 2024 23:54
@Gorkowski Gorkowski disabled auto-merge April 30, 2024 23:54
@Gorkowski Gorkowski merged commit ee30f1b into main Apr 30, 2024
8 checks passed
@Gorkowski Gorkowski deleted the pr-util-for-condsationh branch April 30, 2024 23:54
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
next prototype for v1
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants