Break up parameters struct in CloudMicrophysics.jl 0, 1, 2 - moment microphysics schems

[charleskawczynski]

The parameters (

CloudMicrophysics.jl/src/Parameters.jl

Line 16 in abec798

Base.@kwdef struct CloudMicrophysicsParameters{FT, TP} <:

) is a huge struct, and it looks like (at first glance) that it could be broken into smaller parts (like how surface fluxes handles parameters).

Tasks

Beta Give feedback

No tasks being tracked yet.

[trontrytel]

Hi @charleskawczynski - Thank you for taking a look. I don't think I full understand what you are suggesting. If I end up defining a couple of different structs would I end up having to pass different parameter structs inside CM.jl functions?

Right now all the functions look like foo(param_set::AbstractCloudMicrophysicsParameters, ...)

Would it turn into foo(aerosol_param_set::AbstarctAerosolMicrophysicsParameters, ...) bar(micro_param_set::AbstractMicrophysicsParameters, ...)

If yes, I think it would create too much friction with creating those different parametr sets and passing them in different fucntions. I would rather have everything in one place

[charleskawczynski]

I suspect that we can use composition— are there subsets of parameters that cannot be used together? If so, then those incompatibilities outline the exchangeable parts.

I think we do this in surface fluxes.

[trontrytel]

What is the benefit of splitting it up?

[trontrytel]

First example thanks to @sriharshakandala: #201

[charleskawczynski]

What is the benefit of splitting it up?

I think there’s two benefits, one is modularization, and the other is performance. Very large structs, as I understand it, are a performance issue. I think the reasoning is that the struct may not fit into registers, resulting in register spilling (hurting performance). We can benchmark to confirm, but it’s also probably just not a pattern that we want to use (or spread).

[trontrytel]

Agreed. It was making things easy while developing CloudMicrophysics. Because you just had to pass in one struct everywhere and not think which parameter lives in which struct. But I agree that with 100+ parameters and on the way to add more thats just not sustainable

[trontrytel]

This is done. I'll open a new issue to track the parameter struct updates in the remaining modules of the library