Add immersion freezing

[tangwhiap]

Add the immersion freezing simulation codes, freezing test case, and freezing scenario.

[slayoo]

IIUC, the lack of these additions was not detected by CI, it would be great to add a mechanism at least parsing all the scenario input on CI

[jcurtis2]

Yeah, this is a fairly common occurrence. The urban_plume scenarios are often fixed but the scenarios that often require more libraries (SUNDIALs for condense, CAMP) are often overlooked. This is often as simple as missing a spec file line change/addition. In this case, it would be a lack of adding things in aero_data.dat for most scenarios or a more special case in terms of the CAMP scenario. The CAMP test caught this, it was fixed in the test but not in the scenario til later.

I think that something that simply attempts to run a 0 second simulation will work in terms of reading in all inputs.

[jcurtis2]

Suggested change

implicit none

[slayoo]

@jcurtis2, are you suggesting to remove it because there is -fimplicit-none in the Dockerfile? (it doesn't seem to be enforced by CMake)

[jcurtis2]

This is suggested because we have an implicit none at the module level - this one here is harmless but it is redundant (and I think we have possibly already removed others from elsewhere in this PR)

[slayoo]

@tangwhiap, codecov reports here that the following three cases are never tested:

• if (env_state%temp > const%water_freeze_temp) never occurs in ice_nucleation_melting
• if (aero_particle_new%frozen) never occurs in aero_particle_coagulate
• if (immersion_freezing_scheme_type == IMMERSION_FREEZING_SCHEME_ABIFM) in ice_nucleation_immersion_freezing_time_dependent_naive

Also, there are two instances where the following comment is placed:

! FIXME: Do this to avoid compiler warning/error, fix it in the future.

[slayoo]

@tangwhiap, @jcurtis2, here I'd suggest to define the rate as a positive number, and introduce a minus sign into the exponent

[jcurtis2]

Agreed - I found this a bit confusing initially (as I didn't check carefully enough that the rate was specified as a negative) so I think we should change it that the user specifies a positive value. While this isn't quite the same, we have these in the file and they have a much more familiar form of an exponential with a minus sign.

temp = (log(1d0 - p) + exp(-S * exp(-INAS_a * T0 + INAS_b))) / (-S)

ABIFM_Pfrz_particle = 1 - exp(-j_het_x_area * del_t)

Related, I don't think we ever check on freezing rate to assure its specified correctly - either making sure it is positive (if we want it positive) or negative if we keep it negative.

[slayoo]

melting covered!

[jcurtis2]

• if (immersion_freezing_scheme_type == IMMERSION_FREEZING_SCHEME_ABIFM) in ice_nucleation_immersion_freezing_time_dependent_naive

This appears to be a false-positive in codecov as I've added print statements that are printed when running test_freezing_4.sh. I tried a few things to try to reorganize the code so it might detect that it is indeed tested with line continuations and optimization reduction.

Also, there are two instances where the following comment is placed:

! FIXME: Do this to avoid compiler warning/error, fix it in the future.

I've changed this to a WORKAROUND so that we do not actually insinuate that we can fix this problem 48b0a85 rather than a FIXME.