Remove deprecated history output

[wwieder]

Looks like some model output may be written to history files for variables that have been deprecated in CLM5+.

Specifically, state and fluxes related to the unconfined aquifer (QCHARGE and WA) are not needed in CLM5 and CTSM5.1. Removing these from history files will save space and avoid user confusion.

[billsacks]

Two questions on this:

1. What are the namelist flags or logicals in the code that determine whether these variables are interesting? (It's not enough to say that they're not needed in CLM5 / CTSM5.1: we need to base this on specific namelist flags.)
2. Should they be (a) available to be added but off by default, or (b) not even available to be added?

[wwieder]

Both variables should not even be available in any CLM5 or CTSM5.1 namelists flags. I'm assuming this is true for NWP too, but am less familiar with the soil hydrology used for WRF-CLM configurations. Does this help clarify?

[dlawrenncar]

Maybe we need to talk about this. These variables are not appropriate for specific settings of the hydrology lowery boundary condition. Not sure to what extent we embed history output within namelist flags, but I guess this is something we should do and maybe something that should be another checklist item when creating a new namelist switch?

On Sat, Feb 20, 2021 at 5:22 PM will wieder notifications@github.com wrote:

Both variables should not even be available in any CLM5 or CTSM5.1 namelists flags. I'm assuming this is true for NWP too, but am less familiar with the soil hydrology used for WRF-CLM configurations. Does this help clarify?

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/ESCOMP/CTSM/issues/1281#issuecomment-782770508, or unsubscribe https://github.com/notifications/unsubscribe-auth/AFABYVBYOKLNDNUBPJNLU3TTABG33ANCNFSM4XXRRBXQ .

[billsacks]

Would the appropriate logic be: If this function returns a true value, then add those history variables; if not, they should not be available?:

https://github.com/ESCOMP/CTSM/blob/f2faca68cf854a2dd435b779841547e310536b32/src/biogeophys/SoilWaterMovementMod.F90#L220-L236

[dlawrenncar]

I think so, though I don't off top of my head know how lres is subsequently used (and what does lres stand for?)

On Sun, Feb 21, 2021 at 8:24 AM Bill Sacks notifications@github.com wrote:

Would the appropriate logic be: If this function returns a true value, then add those history variables; if not, they should not be available?:

https://github.com/ESCOMP/CTSM/blob/f2faca68cf854a2dd435b779841547e310536b32/src/biogeophys/SoilWaterMovementMod.F90#L220-L236

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/ESCOMP/CTSM/issues/1281#issuecomment-782875190, or unsubscribe https://github.com/notifications/unsubscribe-auth/AFABYVHFQYORTMZ2JNUPXGTTAEQTRANCNFSM4XXRRBXQ .

[billsacks]

lres is just the return value of the function. So use_aquifer_layer returns true if (lower_boundary_condition == bc_aquifer .or. lower_boundary_condition == bc_watertable) is true, and false otherwise.

Unless I hear otherwise, I'll go ahead and make this change in a tag I'm working on in the next day or so.