Runoff is added to lakes

[BernardoTeufel]

While running a test case for a single lake I noticed that lake volume and outflow was higher than expected from precipitation and evaporation. I suspected that runoff might be contributing to the lake, and confirmed by setting <scale_factor_runoff> to values >1, which increased the discrepancies.

Upon looking into the code, I noticed the following line where runoff is explicitly added to the lake: https://github.com/ESCOMP/mizuRoute/blob/8d0fe43eedd96c17838a697000e5a349e0229604/route/build/src/lake_route.f90#L169

This line was added in commit 20dbade2dd3c48f040f2be4812652243c877b8db, it did not exist before.

Is this the desired behavior? From my perspective, only precipitation and evaporation should be controlling the local lake water balance.

[nmizukami]

Hi @BernardoTeufel, local runoff was added because for CESM (NCAR's ESM) coupled run, removing basin runoff input here caused losing water (which CESM does not like), and runoff needs to be added somewhere. In reality, lakebed seepage or recharge occurs depending on water table.

[BernardoTeufel]

Hi @nmizukami, thanks for the clarification. I've successfully modified lake_route.f90 to suit my needs - since I'm driving mizuRoute using runoff from a land surface model, it doesn't make sense to add land runoff directly to the lake water balance for my application. Perhaps it would be possible to add a flag for this use-case? Either way, I'm fine with this issue being closed, thanks!

[ShervanGharari]

@nmizukami Hi Naoki, Just wondering, is BASIN_QR the same as G term in equation 1 here? And is it set to zero, or effectively inactivate, for standalone?

[ShervanGharari]

@nmizukami Hi Naoki, I did a quick test, and it seems the lake's runoff is being added back to the lake. I might be missing something here, but if I understand correctly, this is not only the G term (exchange with groundwater). Just wanted to check if my understanding is correct. I think either the line should be commented out or a flag should be added, allowing users to decide whether the runoff should be added or removed in case if runoff represents the exchange. Looking forward to your thoughts.

[nmizukami]

Hi Shervan, sorry, but I almost missed this. This is not G term (from recharge into lake or seepage from lake). Just not to lose water from land model. I think the best way to handle is to make a flag and let users to decide (would say default is off== not adding runoff in lake). If you are interested in, you can PR or How did you change @BernardoTeufel?

[BernardoTeufel]

Just commented out the lateral flow (L169): ! RCHFLX_out(iens,segIndex)%ROUTE(idxRoute)%REACH_VOL(1) = RCHFLX_out(iens,segIndex)%ROUTE(idxRoute)%REACH_VOL(1) + RCHFLX_out(iens,segIndex)%BASIN_QR(1) * dt ! add lateral flow

And put zero for the water balance (L472): call comp_reach_wb(NETOPO_in(segIndex)%REACHID, idxRoute, q_upstream, 0._dp*RCHFLX_out(iens,segIndex)%BASIN_QR(1), RCHFLX_out(iens,segIndex), &

[ShervanGharari]

Hi Shervan, sorry, but I almost missed this. This is not G term (from recharge into lake or seepage from lake). Just not to lose water from land model. I think the best way to handle is to make a flag and let users to decide (would say default is off== not adding runoff in lake). If you are interested in, you can PR or How did you change @BernardoTeufel?

Hi @nmizukami, I agree—a global flag would be useful. Based on this flag, the lake water balance should either be determined by runoff (which, in this case, can be negative, correct?) or by adding precipitation and subtracting evaporation.

If the flag is set to True, there would be no need to read evaporation or precipitation since they wouldn’t be required—does that sound right?

Additionally, how is negative runoff handled in this context? For example, does it represent water loss from the lake? And how is in-basin routing implemented on negative runoff?

I can implement this change quickly if needed.

[ShervanGharari]

@nmizukami

I’m planning to start implementing this soon. After giving it some thought, I believe two new flags should be introduced to better control how lakes are simulated:

1. Flag to Use Only Runoff for Lake Simulation

This flag ensures that the lake can be simulated using only runoff, while precipitation and evaporation can be ignored or missing.

This might be important because the runoff may already embed all necessary information from the land or hydrological model — such as precipitation, evaporation, snow, ice, and their spring melt contributions. By using only the runoff (whether positive or negative), we simplify the input requirements.

With this flag:

• Only the runoff field is used.
• Precipitation and evaporation are ignored/skipped.
• The standalone model can skip reading precipitation and evaporation from the input files. Or no need to have these variables in the input as well.

Default: False

🔧 Flag name suggestions (feedback appreciated):

• use_only_runoff_for_lake
• use_runoff_for_lake

2. Flag to Suppress Runoff to Lake

This second flag would force the runoff to lakes to be set to zero, even if runoff inputs are available. Suggested name: set_runoff_to_zero_for_lake or ignore_ruoff_for_lake with default being True.

This allows the lake model to operate without considering vertical water balance (runoff contributions), focusing only on inflow/outflow dynamics. It can be especially useful in cases where:

• The hydrological model does not simulate lake-specific runoff.
• The lakes are small compared to the basin, and a simplified lake or reservoir model is preferred.

---

I suggest starting with the second, and then we can look into the first one if needed. Any thoughts or suggestions on these flags and their naming are very welcome!

[nmizukami]

Hi Shevan, yes, sounds good. Let me think Use Only Runoff for Lake Simulation (seem like you just don't have to provide precip and evap data in control, so they are not used.

[ShervanGharari]

@nmizukami I gave it some more thought over the weekend. Perhaps a better approach would be to implement a global flag alongside a per-lake flag. For example, we could use the existing approach for the LakeRegulate flag to override the LakeType setting (LakeRegulate takes precedence over LakeType).

Similarly, we could introduce a variable in ntopo—let’s say LakeInputType—to define the input mode for each lake:

0 → precipitation and evaporation (default when LakeInputType is not specified in control file)

1 → runoff only

2 → precipitation, evaporation, and runoff (for special cases if needed)

Additionally, we might want a global flag like LakeUseRunoff that, when enabled, forces all lakes to use mode 1 regardless of what’s set in ntopo.

This approach also helps accommodate both small and large lakes within the same framework. For instance, large lakes might already be represented hydrologically within a hydrological or land surface model, meaning the runoff implicitly includes precipitation and evaporation (ice formation, snow accumulation/sublimation, and melt over the lake surface). In contrast, smaller lakes may not be explicitly simulated, so we would rely solely on precipitation and evaporation to represent their water balance.

What do you think?

[nmizukami]

Hi Shervan, Yes, if global flag - maybe call LakeInputOption is provided, apply the option provided by a user to all the lake. Default of this flag is 0. If a user really wants to control the lake input for each lake, a user can add LakeInput in a network data. Default is that a user don't have to provide them. Is this how things work?

[ShervanGharari]

Hi Naoki, @nmizukami

Yes, this aligns with what I have in mind as well. I think this can be implemented through two separate PRs:

1. Global Flag – As you mentioned, we introduce a LakeInputOption flag with possible values (0, 1, 2). This global flag will override any network-specific settings (in step 2) when implemented. By default, the value will be 0, which means only precipitation and evaporation are applied over all lakes.

2. Network-Specific Flag – Enables specifying lake-specific input options, if provided. This will be an optional input/variable in the network topology file (not necessarily required to be provided by users for backward compatibility).

The proposed values for the flag in both cases are:

• 0 → Precipitation and evaporation (default when LakeInputOption is not specified in the control file)
• 1 → Runoff only
• 2 → Precipitation, evaporation, and runoff (for special cases if needed)

If you agree, I can make the first PR for the global flag.

[nmizukami]

Yes, that sounds great. Thanks Shervan!