Unit conversion bug when variable is used by two different schemes (with different units)

[peverwhee]

Description

Scenario 1

If a variable is used in two different schemes and:

1. The first scheme has the same units as the host variable.
2. The second scheme has different units than the host variable.

It produces this error:

Invalid new variable, <variable>, incompatible  between <variable>,

Scenario 2

On the flip side, if:

1. The first scheme has different units than the host variable.
2. The second scheme has the same units as the host variable.

The framework will convert the variable to pass into the first scheme, but not convert it back for the second scheme (thus using the wrong units)

Steps to Reproduce

1. Modify ps in cld_ice.meta in the advection test to have units of "hPa", run the tests and observe the error.
2. Remove your modification to cld_ice.meta. Modify ps in cld_liq.meta in the advection test and inspect the generated code to see the wrong units passed into cld_liq

Output

Generated code for scenario number 2 (where the wrong units are used):

! Compute reverse (pre-scheme) transforms
ps_local(:) = 1.0E-2_kind_phys*ps(:)
! Call scheme
call cld_liq_run(ncol=ncol, timestep=timestep, tcld=tcld, temp=temp, qv=qv,              &
              ps=ps_local, cld_liq_array=cld_liq_array, errmsg=errmsg, errflg=errflg)
...
! Call scheme
call cld_ice_run(ncol=ncol, timestep=timestep, temp=temp, qv=qv, ps=ps_local,            &
              cld_ice_array=cld_ice_array, errmsg=errmsg, errflg=errflg)

[climbfuji]

is this also a problem with prebuild or just with capgen?

[peverwhee]

@climbfuji good question!

I ran a brief test with prebuild and it looks like it works as expected for Scenario 1, but Scenario 2 results in an incorrect conversion before the second scheme. For example, if you have variable unit_conversion_var with units of km in the host model and then Scheme A has units for m (different from host) for that variable, while Scheme B has units of km (same as host) for that variable, you get code that looks like:

tmpvar_1 = 1.0E+3_kind_phys*unit_conversion_var(one:nx)
call schemeA(errmsg,errflg,tmpvar_1)
unit_conversion_var(one:nx) = 1.0E-3_kind_phys*tmpvar_1
...
tmpvar_1 = 1.0E+3_kind_phys*unit_conversion_var(one:nx)
call schemeB(errmsg,errflg,tmpvar_1)
unit_conversion_var(one:nx) = 1.0E-3_kind_phys*tmpvar_1

When you should get code that looks like:

tmpvar_1 = 1.0E+3_kind_phys*unit_conversion_var(one:nx)
call schemeA(errmsg,errflg,tmpvar_1)
unit_conversion_var(one:nx) = 1.0E-3_kind_phys*tmpvar_1
...
call schemeB(errmsg,errflg,unit_conversion_var)

NOTE: I modified the optional arguments prebuild test for this, so the fact that the conversions are being done on optional arguments may be part of the problem!

[climbfuji]

Thanks for testing. This is not what I expected (from my vague memory of how this is implemented)!

[dustinswales]

@peverwhee I think I know what's going on. I had done the same thing for optional args as for unit-transformations, and I fixed the optional-arg bug in my SCM work.

[dustinswales]

@climbfuji @peverwhee I can confirm that this is an issue with Prebuild.

Here are snippets from a cap where I am calling two radiation schemes, first RRTMG w/o unit conversions, and then a second ML based radiation that requires unit conversions. Look at cld_ref_Lliq and tmpvar_1

Local declaration for unit-transfroms (2D)

Input to scheme A, no unit conversion:

Input to scheme B, unit conversion (wrong allocation)

[climbfuji]

@dustinswales Thanks. I am confused though what exactly the problem is (cld_ref_liq / tmpvar_1; "wrong allocation"). What is wrong? Is the problem one:physics%Model%levs vs one:physics%Interstitial%lmk?

[dustinswales]

@dustinswales Thanks. I am confused though what exactly the problem is (cld_ref_liq / tmpvar_1; "wrong allocation"). What is wrong? Is the problem one:physics%Model%levs vs one:physics%Interstitial%lmk?

@climbfuji It's trying to allocate a rank 3 array, when it's declared as rank 2.

[climbfuji]

Oh. That's a different issue though than what is described above (#594 (comment)). It's still a bad bug but should probably have its own issue.

[climbfuji]

As shown in #600, ccpp_prebuild.py does not suffer from this particular bug (but from another #598 which #600 fixes).