Problem: currently, the channel_in forcing variable for the lake module is treated as if it has units of mm/timestep, similar to meteorological forcings. Because of this assumption, there is a line in vic_run() that multiplies by grid cell area to convert the units to m3. But this is both inconsistent with the units given for the variable in vic/drivers/shared_all/include/vic_driver_shared_all.h and inconvenient for users, since it requires them to take a quantity that is normally in units of volume/timestep and divide by the area of the grid cell containing the lake that they are simulating, only to have VIC divide by that area again.
Proposed solution: change the logic in vic_run() and any other driver-related code that make the assumption that channel_in has units of mm/timestep to assume it has units of m3/timestep. Make sure the documentation (in .h files and in the documentation files) is correct.
channel_in
forcing variable for the lake module is treated as if it has units ofmm/timestep
, similar to meteorological forcings. Because of this assumption, there is a line invic_run()
that multiplies by grid cell area to convert the units tom3
. But this is both inconsistent with the units given for the variable invic/drivers/shared_all/include/vic_driver_shared_all.h
and inconvenient for users, since it requires them to take a quantity that is normally in units of volume/timestep and divide by the area of the grid cell containing the lake that they are simulating, only to have VIC divide by that area again.vic_run()
and any other driver-related code that make the assumption thatchannel_in
has units ofmm/timestep
to assume it has units ofm3/timestep
. Make sure the documentation (in.h
files and in the documentation files) is correct.