Rainy Euler equations with implicit condensation

[benegee]

Part of #95

I suggest merging only the Euler equations with rain and implicit condensation in a first pass. I added just enough tests to achieve good coverage.

[codecov]

Codecov Report

❌ Patch coverage is 96.05911% with 24 lines in your changes missing coverage. Please review.
✅ Project coverage is 97.21%. Comparing base (7de9867) to head (e206fd5).
⚠️ Report is 2 commits behind head on main.

Files with missing lines	Patch %	Lines
src/equations/compressible_rainy_euler_2d.jl	96.43%	18 Missing ⚠️
src/equations/compressible_moist_euler_2d_lucas.jl	94.11%	4 Missing ⚠️
src/callbacks_stage/nonlinear_solve_dg2d.jl	90.47%	2 Missing ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##             main     #100      +/-   ##
==========================================
- Coverage   97.30%   97.21%   -0.10%     
==========================================
  Files          30       33       +3     
  Lines        3903     4491     +588     
==========================================
+ Hits         3798     4366     +568     
- Misses        105      125      +20     

☔ 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.

[benegee]

Unfortunately the errors for macos and ubuntu differ by more than the default tolerance. Interestingly, this only happens for the elixir involving a parabolic part.

@tristanmontoya observed discrepancies here as well trixi-framework/Trixi.jl#2431 but for other parts of the code.

Here as well: #94 (comment)

[tristanmontoya]

I still have to go through this in more detail, but I am fine with this PR as a first step. Ultimately, I want to make sure we implement the different model options in an extensible way, as there are so many choices that we need to handle (e.g. gravitational potential term, choice of prognostic variables, condensation model).

[benegee]

Ultimately, I want to make sure we implement the different model options in an extensible way, as there are so many choices that we need to handle (e.g. gravitational potential term, choice of prognostic variables, condensation model).

That is my goal as well! The intention of this PR rather is to make sure that @FnHck's implementation makes it into our initial release.

[benegee]

For the time being I just increased the tolerance to make the macos tests pass.

Could some mac user maybe check if this is just an issue with the github runners?

[benegee]

I tried to address all points raised during review, and included unit and type stability tests as done in #117 .

I also tried to apply our Float32 convention everywhere, as well as switching to our global constants like EARTH_GRAVITATIONAL_ACCELERATION. The latter causes CI to fail because we get small deviations from the reference values. In particular, I confirmed that the shallow water tests and alike finish successfully with g = 9.80616 while the moisture and potential temperature tests rather use g = 9.81. I think the concrete value is not important here, but it would make sense to unify the used constants. For the time being, both values would be fine for me. What do you think @amrueda @tristanmontoya?
(In the long run we should come up with a more flexible global constants set. Something that at least supports delivering values with a predefined floating point type).

[tristanmontoya]

I tried to address all points raised during review, and included unit and type stability tests as done in #117 .

I also tried to apply our Float32 convention everywhere, as well as switching to our global constants like EARTH_GRAVITATIONAL_ACCELERATION. The latter causes CI to fail because we get small deviations from the reference values. In particular, I confirmed that the shallow water tests and alike finish successfully with g = 9.80616 while the moisture and potential temperature tests rather use g = 9.81. I think the concrete value is not important here, but it would make sense to unify the used constants. For the time being, both values would be fine for me. What do you think @amrueda @tristanmontoya? (In the long run we should come up with a more flexible global constants set. Something that at least supports delivering values with a predefined floating point type).

Can we just modify the reference values so CI passes with the unified value of the gravitational acceleration? I'm not sure I understand correctly. The values I used like EARTH_GRAVITATIONAL_ACCELERATION come from the Williamson et al. test suite for shallow water, which is standard in that context.

[benegee]

Can we just modify the reference values so CI passes with the unified value of the gravitational acceleration? I'm not sure I understand correctly. The values I used like EARTH_GRAVITATIONAL_ACCELERATION come from the Williamson et al. test suite for shallow water, which is standard in that context.

All good! I had just been playing around with the constant to see which tests fail. We have to either adjust the values for the shallow water test, or for the Euler tests. I am fine with adjusting the Euler test cases.

But now we are at it, what will be our ultimate standard choice in the future? Williamson? Maybe this one: https://physics.nist.gov/cgi-bin/cuu/Value?gn
(I have no opinion, but it would be nice to have to adjust the reference values only once. 😉 )

[tristanmontoya]

Can we just modify the reference values so CI passes with the unified value of the gravitational acceleration? I'm not sure I understand correctly. The values I used like EARTH_GRAVITATIONAL_ACCELERATION come from the Williamson et al. test suite for shallow water, which is standard in that context.

All good! I had just been playing around with the constant to see which tests fail. We have to either adjust the values for the shallow water test, or for the Euler tests. I am fine with adjusting the Euler test cases.

But now we are at it, what will be our ultimate standard choice in the future? Williamson? Maybe this one: https://physics.nist.gov/cgi-bin/cuu/Value?gn (I have no opinion, but it would be nice to have to adjust the reference values only once. 😉 )

I would keep them as the Williamson values for no other reason than it being what was used in my paper. If DCMIP or some other more recent project has standardized values, we could use that instead. Are the reference values the only reason for the failing tests, @benegee?

[tristanmontoya]

Aside from the above comments about constants and integer values, I'd say this is good to merge.

[benegee]

I would keep them as the Williamson values for no other reason than it being what was used in my paper. If DCMIP or some other more recent project has standardized values, we could use that instead. Are the reference values the only reason for the failing tests, @benegee?

This is of course some good reason!

Yes, I now switched back to "your" constants and your test are now working again. On the other hand, potential temperature test case are now failing. I could update the references for these test cases, or we would need to use non-common constants. What is your opinion @MarcoArtiano ?

[MarcoArtiano]

I would keep them as the Williamson values for no other reason than it being what was used in my paper. If DCMIP or some other more recent project has standardized values, we could use that instead. Are the reference values the only reason for the failing tests, @benegee?

This is of course some good reason!

Yes, I now switched back to "your" constants and your test are now working again. On the other hand, potential temperature test case are now failing. I could update the references for these test cases, or we would need to use non-common constants. What is your opinion @MarcoArtiano ?

We do not need to use particular values for the constants in the potential temperature test cases, so I'm in favor of that change.

[benegee]

This is now ready to merge! I would like to accept the slight decrease in coverage. If I understand correctly this is mainly due to the new equations having about 96% coverage because of the sanity checks, such as #100 (comment). I would however like to keep those checks for the time being.

[tristanmontoya]

Looks good! The only other thing I noticed was that the new elixirs are in a subdirectory examples/moist_euler, but the older moist Euler elixirs are not in that subdirectory, which could appear confusing. But reorganizing the examples (i.e., addressing #29) could be left to another PR so feel free to leave it as-is for now.

[benegee]

Thanks a lot @tristanmontoya !

You are right, the examples still need to be re-organized; added to #101

I need another approval because of a small adaption to upstream Trixi.jl changes.

[tristanmontoya]

All good now!