[Feature]: Separate original and component plots of global_time_series

[forsyth2]

How will this affect the next version number?

New feature (increment MINOR version)

Is your feature request related to a problem?

Original and component plots have diverged both in terms of use cases and in displayed output (see #22 (comment)). This has caused confusion about expected output (i.e., the design specification matrix at #19 (comment)) and in the code implementation (#19, #22).

Describe the solution you'd like

Possible solutions:

• Make them distinct entry points to zppy-interfaces (and separate zppy tasks?)
• Keep it as one entry point, but separate out the python files for more code clarity.

Describe alternatives you've considered

No response

Additional context

No response

[forsyth2]

@chengzhuzhang I think we need to address this before #22. What we choose here will inform how we handle variable loading elsewhere. It would also be helpful to flesh this out before finishing the larger performance refactoring of #19. That is, I think really all 3 of these issues should be addressed in unison as one PR.

I think my preferred design would be to split global-time-series into 2 zppy-interfaces entry points

Feature	original 8	viewer
Proposed zppy task name	global_time_series_overview	global_time_series_viewer
Proposed entry-point name	zi-global-time-series-overview	zi-global-time-series-viewer
Which variables	pre-determined set	user-chosen
Variable loading (#19)	all variables will be loaded up front	Only requested variables will be read
Variable derivation (#19)	we can derive variables because there's only a small set of variables we need derivation formulas for and we loaded all the variables	no derivations because implementing them would be too complex -- users will have to specify exactly the variables they want, that are available to use
Output	an 8-plot single-page PDF for each of global, N, S	viewer similar to e3sm_diags with HTML pages linking to single-plot PNGs

Note this would be a breaking change, since I can't imagine the parameters not requiring updates for this. So, that would be pretty big split of the functionality. Is that how we want to proceed?

Let me know if you'd prefer to meet to discuss the design. Ideally, I'd like to start work on these changes this week.

[chengzhuzhang]

I think it is a good ideal to separate two modules: global_time_series_overview and global_time_series_component_viewer under global_time_series task. I doubt if it is necessary to bring in breaking change to have separate tasks and change usage of global_time_series task.

[forsyth2]

I doubt if it is necessary to bring in breaking change to have separate tasks and change usage of global_time_series task.

I can start prototyping and see how minimal we can keep the changes. We'll likely have to iterate a few times on design decisions.