wip: nonnegativity element limiter

[haakon-e]

This pull request introduces improvements to how scalar nonnegativity is enforced. The main focus is on ensuring that condensate mass variables remain physically valid (non-negative) throughout computations.

Physical Constraints Enforcement:

• A new function preserve_scalar_nonnegativity! is introduced in dss! (src/prognostic_equations/dss.jl) to explicitly enforce nonnegativity for condensate mass fields (e.g., ρq_liq, ρq_rai, ρq_ice, ρq_sno, ρq_tot). This function clips negative values to zero and applies the limiter, ensuring physically meaningful results for these quantities.
• The call to preserve_scalar_nonnegativity! is added to the main dss! routine, so nonnegativity is enforced every time dss! runs.

[tapios]

You don't want to clip q_tot--we'd lose water mass conservation.

[szy21]

If I understand correctly, it decreases q_tot in other nodal points within the element if it is clipped, so that it conserves water mass within the element.

[tapios]

Why should we mess with q_tot here? Isn't it more natural to deal with this through vertical water borrowing?

[haakon-e]

How is vertical water borrowing more natural than horizontal water borrowing?

That said, I'm fine removing q_tot for now.

[tapios]

There are large gradients in the vertical but not necessarily in the horizontal.

[sajjadazimi]

What if q_tot becomes negative because of the horizontal dynamics? Also if there are large gradients in vertical and not necessarily in horizontal, isn't it better to borrow horizontally to not affect those large gradients?

[tapios]

If we adjust q_tot horizontally, we create spurious transport over O(100 km) and change total column water, which controls precipitation. It will lead to precip errors.

If we adjust q_tot vertically, we create spurious transport over O(100 m) and leave total column water unchanged. It is less likely to lead to precip errors.

For condensate, the spurious transport argument over large horizontal distances also applies. But it's generally a less severe problem because condensate << total.

[trontrytel]

I was also thinking that transporting tracers in the vertical is the worse option than in the horizontal. I agree that distances are larger in the horizontal, but to the first approximation the vertical velocity is zero in the atmosphere. Also the saturation vapor pressure differences are larger in the vertical. So we might end up creating clouds in the vertical due to issues with horizontal transport. Especially since with stretched grid, higher up the spacing is larger than O(100m).

[tapios]

I'm fine with whatever works in the end. However, I am worried about creating a pathway that can hide O(1) errors (in q_tot).

[trontrytel]

Lets test with and without applying those changes to q_tot. I hope there is a way to set up other numerics flags (diffusion/hyperdiffusion, limiters) that will allow us to run without it applied on q_tot