Convert wetlands to bare ground

[billsacks]

To remove one source of negative runoff, we are planning to use bare ground in place of wetlands. (Note that wetlands are currently just used to represent ocean points: we currently don't run with inland wetlands.)

The original proposal was to change the surface datasets to specify bare ground rather than wetlands. However, I realized that that plan would make it impossible to do the rigorous treatment of coastal areas described in #1716 . So my plan is to add a flag that allows making this change at runtime. The other advantage of this approach is that this conversion can be turned on or off with the same surface datasets.

One other small change I'll make is to remove the code in mksurfdata that forces soil properties to hard-coded default values in wetland grid cells. This forcing seems unnecessary since soil properties are already given the same default values if no data are found for a given output cell; by removing this forcing for wetland grid cells, we will be able to use any existing soil data for a grid cell where soil properties are available despite the grid cell being considered ocean by the PFT data.

@ekluzek @wwieder @slevisconsulting

[billsacks]

@ekluzek @wwieder @slevisconsulting - I have a few questions:

1. Are you okay with my proposal of doing this at runtime rather than on the surface datasets?

2. Do you agree with the idea that the default for this behavior should depend on the model version, so that CTSM52 uses the new convert-wetlands-to-bare-ground behavior but earlier versions remain unchanged? Or should we change this for all physics versions? If this will depend on model version, it looks like I'll need to add a new 5_2 phys option and compset (at a glance these don't seem to have been added yet).

3. I thought I'd do this on the ctsm5.2.mksurfdata branch, since it will involve some minor changes to mksurfdata. Do you agree? If so, is there any standard testing being done for changes on that branch?

[ekluzek]

1. I agree with the plan to remove this out of the datasets, to the model so that the solution is flexible. It's so much effort to create a new set of datasets for all resolutions, run time flexibility makes this much better.

2. We had proposed that the datasets would be updated for all physics versions, so we could do this either way. We might need a clm5_2 physics option anyway, so nothing wrong with adding that. Although if ctsm5.2 is just the new datasets and we change the datasets for all versions -- maybe ctsm5.2 doesn't really mean much. So we could just do a couple ctsm5.2 tags and then make a new tag for ctsm5.3 where we start changing answers beyond surface datasets.

3. Yes, that makes the most sense to put it on the branch
   The testing depends on what's done. And not all testing actually works, because datasets aren't updated on the branch. So we should probably chat about this to decide what to do. We have been making PR's for important updates and making sure both Sam and I know about them, and approve them. Then we make a branch tag when the PR is pulled to the branch.

[billsacks]

Awesome, thanks @ekluzek . The code changes should be pretty small and isolated to a subroutine that will only be invoked for the new option, so I think it won't be necessary to run full testing on these changes... I think just a subset of (working) tests should be fine. But if desired, I could temporarily rebase the changes onto master in order to run full testing; we can decide once I submit a PR with the changes.

[ekluzek]

Don't worry about rebasing to master for a small change. We will get all the testing working on the branch, and can solve any small problems when that happens.

[slevis-lmwg]

I am on board with the above decisions.

[wwieder]

My only naive question is if this would just be a compset distinction, as I'm imagining it really only matters for coupled runs?

[billsacks]

My only naive question is if this would just be a compset distinction, as I'm imagining it really only matters for coupled runs?

I'm not sure I totally understand your question. Are you asking if we would want the behavior to differ for coupled vs uncoupled runs? We usually try to keep the behavior the same between coupled and uncoupled runs both to keep the CTSM operation more consistent in these two cases and to avoid surprises. So I was imagining that any run using CTSM52 or later – coupled or uncoupled – would use this new behavior, but you can let me know if you feel it's important for this new behavior to only be in place for coupled runs.

[wwieder]

I guess this is true, this issue is really just arising because of a mismatch in surface data used by the land and ocean models (and points where the ocean is assigning us land that we don't know anything about, and applying wetlands to)? If we're using our own internally consistent surface data in an uncoupled run this shouldn't really be an issue?

More broadly, however, the 2nd and 3rd parts of our negative runoff fix in #1835 we only going to applied in coupled cases, but maybe this isn't accurate either?

[billsacks]

I guess this is true, this issue is really just arising because of a mismatch in surface data used by the land and ocean models (and points where the ocean is assigning us land that we don't know anything about, and applying wetlands to)? If we're using our own internally consistent surface data in an uncoupled run this shouldn't really be an issue?

Even in an uncoupled run, we typically use the standard ocean mask so we end up with the same fractional cover. We wouldn't need to do this – and I think the standard for F compsets (AMIP-style runs) is to use a land mask that is unrelated to any ocean grid – but this is what's been done for I compsets for as long as I've been around. I think the rationale is that we want consistency between the operation of I compsets and that of fully-coupled runs. Maybe @ekluzek could provide more historical perspective. One situation to also consider is an I compset for the sake of spinning up CTSM with cplhist data (i.e., forcings from a previous B compset). It seems like we would want the land to work as similarly as possible in this case as it does in the equivalent B compset.

More broadly, however, the 2nd and 3rd parts of our negative runoff fix in #1835 we only going to applied in coupled cases, but maybe this isn't accurate either?

I haven't given this much thought, but for similar reasons, I imagined that we were going to do parts (2) and (3) for all runs, not just fully-coupled runs. But this definitely warrants discussion. Let's talk more at the ctsm-software meeting tomorrow.