Skip to content

Move parameters out 1M options types into Microphysics1MParams - #767

Merged
nefrathenrici merged 5 commits into
mainfrom
ne/params
Jul 24, 2026
Merged

Move parameters out 1M options types into Microphysics1MParams #767
nefrathenrici merged 5 commits into
mainfrom
ne/params

Conversation

@nefrathenrici

@nefrathenrici nefrathenrici commented Jul 21, 2026

Copy link
Copy Markdown
Member

Changes

  • Made the 1M option types singletons.
  • Moved 1M options parameters to new field process_params in Microphysics1MParams. process_params_for(option, toml_dict) reads the parameter values for each selected process.
  • The 1M tendency functions now read values from mp.process_params.<slot> instead of off the option struct. Dropped the now-unused opt argument names.
  • Separated two condensation/deposition timescale kernels out (_conv_q_vap_to_q_lcl_const, _conv_q_vap_to_q_icl_const) so the 2M scheme can reuse them. Temperature-dependent ice stays inlined.
  • Added defaults to Microphysics1MOptions.

Some benchmark tests fail on the 1.12 runner, I would like to increase the time limit since there is no type-stability change.

@codecov

codecov Bot commented Jul 21, 2026

Copy link
Copy Markdown

Codecov Report

❌ Patch coverage is 93.05556% with 5 lines in your changes missing coverage. Please review.
✅ Project coverage is 92.86%. Comparing base (284c88a) to head (1ff156d).

Additional details and impacted files
@@            Coverage Diff             @@
##             main     #767      +/-   ##
==========================================
- Coverage   92.92%   92.86%   -0.06%     
==========================================
  Files          56       56              
  Lines        2896     2889       -7     
==========================================
- Hits         2691     2683       -8     
- Misses        205      206       +1     
Components Coverage Δ
src 93.66% <93.05%> (-0.06%) ⬇️
ext 69.47% <ø> (ø)
🚀 New features to boost your workflow:
  • ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

@haakon-e haakon-e left a comment

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

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

Looks good. some minor inline comments attached.

The biggest piece that it would be useful if this PR documented (at least in the PR description) is why this change is desired. Some motivation is provided in #766 which appear to primarily point to ergonomics:

[currently,] you can't choose a process without a full parameter set, complicating the atmosphere model interface downstream.

If I understood some offline conversations correctly, this change could also be beneficial for performance. It would be useful to spell that out (and test it) in this PR too.

Comment thread docs/bibliography.bib
Comment thread src/parameters/Microphysics1MOptions.jl Outdated
Comment on lines 79 to +80
options::OPT
process_params::PPR

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

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

small nit: I think it would be more intuitive if the naming between options and process_params was uniform. That is, name both either:

  • options, option_params
  • processes, process_params

I have a slight preference towards the latter, but bike shedding like this can also wait until another day.

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

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

Agreed processes / process_params is clearer, I can make the change.

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

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

Actually, it may be a larger effort to get everything named consistently. I think it should be done in a later PR.

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

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

I agree, let's make that suggestion a separate PR. But it'd also be good to hear from @trontrytel if she has thoughts about this bike shed's color:)

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

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

Yes on consistency. No preferences on the color of the bikeshed

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

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

Great, I added the changes to #768

Comment thread src/parameters/Microphysics1MParams.jl Outdated
Comment thread src/parameters/Microphysics1MParams.jl Outdated
Comment thread src/parameters/Microphysics1MParams.jl Outdated
Comment thread src/MicrophysicsNonEq.jl
@nefrathenrici
nefrathenrici requested a review from haakon-e July 23, 2026 18:51
Comment thread src/parameters/Microphysics1MOptions.jl Outdated

# Fields
$(DocStringExtensions.FIELDS)
Parameters (`τ_relax`) are stored in `process_params.cloud_liquid_formation`.

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

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

many docstrings mention where some parameter is stored. could this be made a bit more explicit by mentioning the struct storing them, e.g.,

stored in `process_params.cloud_liquid_formation` in [`Microphysics1MParams`](@ref)

or similar

Comment thread src/parameters/Microphysics1MParams.jl Outdated
# Fields
- `options::OPT`: Microphysics1MOptions — process configuration (carries process-specific parameters)
- `options::OPT`: Microphysics1MOptions — process selection
- `process_params::PPR`: parameter data for each selected process, mirroring `options` (`nothing` when a process is disabled with `nothing` or needs no parameters)

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

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

nit: add newline

@nefrathenrici
nefrathenrici merged commit fc5d5e0 into main Jul 24, 2026
15 of 16 checks passed
@nefrathenrici
nefrathenrici deleted the ne/params branch July 24, 2026 19:54
Comment thread src/Microphysics1M.jl
@inline function conv_q_lcl_to_q_rai(::CMP.Kessler1M, mp, tps, micro, thermo)
q_lcl = micro.q_lcl
(; τ, q_threshold, k) = opt.acnv1M
(; τ, q_threshold, k) = mp.process_params.rain_autoconversion

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

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

Sorry, I'm a little late into this. I thought we wanted the process_params struct to be flat? Since we are no longer dispatching, there is no need for the additional layer of .rain_autoconversion ?

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

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

The per-process key is still needed, but not for dispatch. process_params holds the params for every enabled process at once and some of these parameters have the same name. To flatten this structure, every parameter would need to have a unique name.

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

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

Yes. I thought that was the idea? I don't think there are that many with doubled names tbh. I thought it would be easier on the compiler to have a flat struct here, rather than more nesting?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants