8000 Convert warnings to Python by timothy-nunn · Pull Request #3680 · ukaea/PROCESS · GitHub
[go: up one dir, main page]
More Web Proxy on the site http://driver.im/
Skip to content

Convert warnings to Python #3680

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

Open
wants to merge 4 commits into
base: main
Choose a base branch
from
Open

Conversation

Copy link
Contributor

Convert error_handling.f90 to Python with a warning handler (a singleton class). The warnings are defined in the code rather than a separate json file.

@timothy-nunn timothy-nunn requested a review from jonmaddock June 11, 2025 12:48
@codecov-commenter
Copy link
codecov-commenter commented Jun 11, 2025

Codecov Report

Attention: Patch coverage is 35.13514% with 96 lines in your changes missing coverage. Please review.

Project coverage is 38.38%. Comparing base (9201e19) to head (6a6cd6c).

Files with missing lines Patch % Lines
process/superconducting_tf_coil.py 5.88% 16 Missing ⚠️
process/physics.py 6.25% 15 Missing ⚠️
process/build.py 11.11% 8 Missing ⚠️
process/pfcoil.py 11.11% 8 Missing ⚠️
process/tf_coil.py 27.27% 8 Missing ⚠️
process/scan.py 12.50% 7 Missing ⚠️
process/warning_handler.py 79.41% 7 Missing ⚠️
process/fw.py 16.66% 5 Missing ⚠️
process/stellarator.py 20.00% 4 Missing ⚠️
process/blanket_library.py 25.00% 3 Missing ⚠️
... and 10 more
Additional details and impacted files
@@            Coverage Diff             @@
##             main    #3680      +/-   ##
==========================================
+ Coverage   38.13%   38.38%   +0.24%     
==========================================
  Files          88       89       +1     
  Lines       22470    22400      -70     
==========================================
+ Hits         8570     8598      +28     
+ Misses      13900    13802      -98     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:
  • ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

@timothy-nunn timothy-nunn linked an issue Jun 11, 2025 that may be closed by this pull request
@timothy-nunn timothy-nunn self-assigned this Jun 11, 2025
Copy link
Contributor
@jonmaddock jonmaddock left a comment

Choose a reason for hiding this comment

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

Massive improvement, and would work nicely. Just wondering about using logging rather than a custom solution.

_warnings: ClassVar[list[ProcessWarning]] = []

def __init__(self):
raise NotImplementedError(f"{self.__class__.__name__} cannot be instantiated.")
Copy link
Contributor

Choose a reason for hiding this comment

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

Isn't this what an abstract base class decorator is for?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I think that decorator would only stop you instantiating a class that doesn't fully implement the abstract methods, of which we have none here.

raise NotImplementedError(f"{self.__class__.__name__} cannot be instantiated.")

@classmethod
def create_warning(cls, msg: str, **diagnostics):
Copy link
Contributor

Choose a reason for hiding this comment

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

Would it not make more sense to use logging's warn(), with an appropriate handler? This would allow us to use info, warnings and errors in the same way, using custom handlers if we want, as well as being able to change log level as required. I think it's designed for this exact purpose, but maybe there's something I'm missing!

Copy link
Contributor Author

Choose a reason for hiding this comment

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

@jonmaddock I think the motivation behind a custom solution is the way model warnings have historically been used in PROCESS:

  1. We often only care about warnings which occur in the final iteration of PROCESS as it is the solution point. I see logging as the tool we would use when we always want to see a warning whereas this solution discards 'irrelevant' ones.
  2. I don't think we could get the model warnings output into the .OUT file in the same way if we used a logging solution.

@timothy-nunn timothy-nunn requested a review from jonmaddock June 12, 2025 10:02
@timothy-nunn timothy-nunn force-pushed the convert_warnings_python branch from b83ecb0 to 6a6cd6c Compare June 13, 2025 08:09
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Convert error_handling.f90 to Python
3 participants
0