Fix VERBOSE level not registered in multiprocessing workers

[samc24]

Summary

• Move VERBOSE level registration from setup_logging() to module-level in log_settings.py, so it's available in any process that imports the module
• Fixes all physics methods silently returning NaN on macOS/Windows (spawn) and Linux with Python 3.14+ (forkserver)

Problem

The custom VERBOSE level and logger.verbose() method are registered inside setup_logging(), which only runs in the main process. Worker processes created by multiprocessing.Pool don't inherit this on:

• macOS/Windows (default start method: spawn)
• Linux + Python 3.14 (default changed from fork to forkserver)

This causes params.logger.verbose() in the physics method decorator (decorator.py:61) to throw AttributeError. The broad except in populate_method catches it and replaces the method's real result with NaN -- for every method, every shot.

Verification

Tested with MAST shot 30420, num_processes=1, macOS + Python 3.11 (spawn):

• dev: 0/33 parameters have data (100% NaN, every method errors with AttributeError)
• This branch: 32/33 parameters have data (1 expected NaN: power_nbi missing for this shot)

Greg also confirmed: dies on Linux + Python 3.14 (forkserver), works from this branch.

Test plan

• Reproduced on macOS with spawn — all NaN on dev, real data on fix branch
• Greg confirmed reproduction on Linux + Python 3.14 (forkserver)
• CI (Linux + fork, unaffected but should pass as before)

References [edit by GLT]

https://docs.python.org/3/whatsnew/3.14.html#concurrent-futures

concurrent.futures

• On Unix platforms other than macOS, ‘forkserver’ is now the default start method for ProcessPoolExecutor (replacing ‘fork’). This change does not affect Windows or macOS, where ‘spawn’ remains the default start method.

[gtrevisan]

yes, I was able to replicate it on a linux laptop:

export REPO="git+https://github.com/mit-psfc/disruption-py"

• 🟢 uvx --python 3.13 --from "$REPO@dev" disruption-py -m get_kappa_area
• 🔴 uvx --python 3.14 --from "$REPO@dev" disruption-py -m get_kappa_area

this hinges on using uvx because a normal git clone + uv sync would rightfully detect that python 3.14 is unsupported -- uvx bug tracked at https://github.com/astral-sh/uv/issues /8206 ...
(just FYI: I pinned python below 3.14 due to some packages back in the day, so we might unpin it soon.)

with your fix, both work:

• 🟢 uvx --python 3.13 --from "$REPO@0fe51d0" disruption-py -m get_kappa_area
• 🟢 uvx --python 3.14 --from "$REPO@0fe51d0" disruption-py -m get_kappa_area

BUT it does not look like I can switch log level anymore with python 3.14 (!):

• 🟢 uvx --python 3.13 --from "$REPO@0fe51d0" disruption-py -m get_kappa_area -l critical
• 🔴 uvx --python 3.14 --from "$REPO@0fe51d0" disruption-py -m get_kappa_area -l critical

I read again the release notes for 3.14, but I could not see anything that might help.
I did check and in both cases we run the same loguru version:

• uvx --python 3.13 --from "$REPO@0fe51d0" python -c "import loguru; print(loguru.__version__)" = 0.7.3
• uvx --python 3.14 --from "$REPO@0fe51d0" python -c "import loguru; print(loguru.__version__)" = 0.7.3

[gtrevisan]

@samc24 please LMK whether you can replicate this loglevel behavior from your macbook!

[samc24]

@samc24 please LMK whether you can replicate this loglevel behavior from your macbook!
Re @gtrevisan :

Confirmed on macOS (Python 3.11, spawn): passing log_settings="CRITICAL" still shows VERBOSE/DEBUG output from worker processes. Same root cause , setup_logging() configures handlers in the main process only, workers get default loguru handlers.

This is pre-existing and separate from the VERBOSE registration fix in this PR ; on dev, the AttributeError masked it because methods never got far enough to log. Now that methods run successfully, the unfiltered worker logging becomes visible.

Reproduction:

# /tmp/test_loglevel.py
if __name__ == '__main__':
    from disruption_py.workflow import get_shots_data
    result = get_shots_data(
        shotlist_setting=[30420],
        num_processes=1,
        log_settings="CRITICAL",
    )

$ poetry run python /tmp/test_loglevel.py
# Expected: only CRITICAL messages
# Actual: VERBOSE and DEBUG output from worker still appears:
#   2026-04-07 16:07:24.968 | DEBUG    | disruption_py.inout.xr:__init__:41 - ...
#   2026-04-07 16:07:34.978 | VERBOSE  | disruption_py.core.physics_method.decorator:timed_wrapper:61 - ...

Can address the handler config in a follow-up PR (e.g., Pool(initializer=...) to configure handlers in workers). Want me to keep this PR scoped to just the level registration, or bundle the handler fix here?