Subprocesses with same diagnostic names cause a conflict

[brian-rose]

Currently climlab always passes diagnostic variables calculated by subprocesses up to the parent process:

climlab/climlab/process/time_dependent_process.py

Lines 268 to 269 in 5168ea0

	for diagname, value in proc.diagnostics.items():
	self.__setattr__(diagname, value)

This is convenient since you don't have to go digging through the subprocess tree to find diagnostic values. But it also assumes that every subprocess gives unique names to their own diagnostics, because the names are used as dictionary keys.

This is in contrast to how tendencies of state variables are calculated. Every subprocess has its own tendencies dictionary, but the keys are identical (i.e. the names of the state variables), and the tendencies for the same named state variable are summed up in the parent process.

Currently I'm working on implementing a complete hydrological cycle in a model with a moist convection scheme and a large-scale condensation scheme. If both processes declare a diagnostic precipitation, with the current code in climlab.TimeDependentProcess only one array will be passed the parent, and it's totally arbitrary just based on the order of iteration through the subprocess tree.

A workaround is to use disambiguating labels for every diagnostic. For example, we already do that with radiation diagnostics, for example SW_flux_up vs LW_flux_up.

But maybe it makes more sense to apply the same kind of logic for diagnostics as we do for tendencies:

Diagnostics with identical names in subprocesses should be assumed to be additive in the parent process.

Thus a Radiation processes could have a generic flux_up diagnostic which would automatically be the net upward flux for both LW and SW subprocesses, while the individual diagnostics would always be available within the subprocess objects themselves.

And for a hydrological model, there could be precipitation and evaporation diagnostics computed in various ways by subprocesses (convection, large-scale condensation, boundary layer turbulence) which would automatically be summed in the parent process that couples them together.

[brian-rose]

What are use cases for which the additive assumption for same-named diagnostics would be bad / undesirable?

Is it making too many implicit assumptions, e.g. about unit consistency? Maybe.

[brian-rose]

On the other hand, the current code is worse, since information is silently lost if there are name conflicts.

It might make sense to go ahead with implementing the additive approach with an optional flag to turn it off.