Usability improvements for Python-based workflows

[tcmetzger]

The Python interface also makes pyRTE+RRTMGP easier to use in Python-based workflows. Specifically:

• Establish conventions: define a set of conventions for gas names, temperatures, pressures, and potentially other physical quantities, based on FC standards Version 27 (http://cfconventions.org/Data/cf-standard-names/27/build/cf-standard-name-table.html), see Python front-end: Conventions for user facing code #47 for more details!
• Inferring towards those conventions: Use xarray metadata to extract information about the data available in the xarray data set and make it accessible in a standardized way on the frontend (based on the established conventions)
• Wrapping:
  • Update the Python interface to use verbs instead of nouns (solve_lw instead of lw_solver).
  • Add a rte.solve function that automatically infers which solver to use based on the user-provided input data and uses sensible defaults. Specifically, this automates the following two decisions:
    • Retain spectral detail or accumulate on the fly?
    • Is the problem a 1-parameter or 3-paramter problem?
  • Robert and team to provide documentation about how the Fortran interface handles inferring from user input and mapping these choices to the kernel arguments

Related to #47

[RobertPincus]

I was looking at the current spellings with @sehnem. There are two places that seem more complicated to me than is ideal for users.

First: Here's how users make a map from the physical state of the atmosphere to a radiation problem

atmosphere = xr.load_dataset(atmosphere_path)

gas_optics_lw = load_gas_optics(gas_optics_file=GasOpticsFiles.LW_G256)
gas_optics_lw.gas_optics.compute(atmosphere, problem_type="absorption")

I would except something more like

gas_optics_lw = load_gas_optics(gas_optics_file=GasOpticsFiles.LW_G256)
gas_optics_lw.compute(atmosphere, problem_type="absorption")

@sehnem explained that the two dots are required because gas_optics_lw is actually a data set. This doesn't seem quite right - users need not know what the dataset is or what it contains, and they certainly shouldn't mess with the data, they just want to do the computation. Can we add code ("syntactic sugar"?) to streamline the user interaction? @brendancol may have opinions.

Second, solving the radiation problem for currently uses;

solver = RTESolver()
fluxes = solver.solve(atmosphere, add_to_input=False)

I'd really expect something like

fluxes = rte.solve(atmosphere, add_to_input=False)

i.e. no initialization of the solver, which simply gets imported from rte. Are there not other approaches to saving persistent information?

[tcmetzger]

The Python frontend is to be based on those two examples:

• Python front end - encapsulating variables #31 (comment)
• Spelling for all-sky problems #97

[tcmetzger]

As discussed today, @RobertPincus is going to work on an improvement to the gas name dictionary (@sehnem to provide input on where the dictionary is located)

EDIT: location is ⬇️

pyRTE-RRTMGP/pyrte_rrtmgp/config.py

Line 10 in 5e7ceb4

DEFAULT_GAS_MAPPING: Final[Dict[str, list[str]]] = {

[sehnem]

Changes made in PR #108 ready for review, they implement the syntax as in the examples.