When used via BMI, precip should NOT be scaled any further

[hellkite500]

https://github.com/NOAA-OWP/cfe/blob/0b488a123887100c6304aee3b0149bc97a68283e/src/bmi_cfe.c#L1509C7-L1509C81

During the update step, precip is scaled by 1000 assuming the prcipitation input variable has units of mm/hr which is NOT a valid assumption when precip is coming from a BMI input variable. For example, when copuled with NOM and passing QINSUR as the surface flux, then the forcing comes in the units of m/s.

Also, when used via a framework which uses BMI unit data to perform unit conversion, this becomes prolematic, as the advertised unit of the precip input variable is mm/hr and so, as in the example with NOM, a converting framework will pass in values with the correct units, and they are then divided by 1000.

[andywood]

I agree, hardwired input/output unit conversions in formulations for NextGen are to be avoided.

[SnowHydrology]

I believe this is legacy code from the standalone CFE running with AORC forcing that it reads itself. If we update the code to remove the hard-coded transformation (which we should) we'll also need to update the standalone forcing data to reflect this. Or, account for the change in some other way.

[PhilMiller]

One easy way would be to just change what unit the BMI input variable advertises, to match the scaling. Everything else should just do the right thing then, I think?

In an ideal world, we would not have hard-coded scaling and conversion, of course, but changing the rest of the world around the code may not be the most expedient path.

[ajkhattak]

this should be a pretty straightforward change , unless I am missing something.
so we should change the unit mm h-1 to m h-1 (

cfe/src/bmi_cfe.c

Line 310 in 0b488a1

"mm h-1", //"atmosphere_water__liquid_equivalent_precipitation_rate"

)
and remove the 1000. from denominator.

For the standalone runs, we can do the conversion from mm to m inside the main.c