Quick changes to improve user experience

[bitterbark]

These are my suggestions. Free free to disagree, discuss and/or add your own here. We can make an issue once there is concensus.

1. Use the keyword syntax in the example config file
   eg.
   #Name of CAM case (or CAM run name):
   cam_case_name: b.e20.BHIST.f09_g17.20thC.297_05
   cam_case_path: /your/path/here #MUST EDIT

   #Location of CAM history (h0) files:
   cam_hist_loc: ${cam_case_path}/${cam_case_name}/hist

(Connection here with the discussion about suggesting workflow
I think if we use the keywords, and also use the section.${xxx} syntax, we could save on the explanation entirely

2. STDOUT should give path to output, at least for figures:
   Eg. Add final path after 'successful'
   Generating Diagnostics webpages...
   ...Webpages have been generated successfully.
   See
   /glade/p/cgd/amp/bundy/ADF/diag_plots/b.e20.BHIST.f09_g17.20thC.297_05_vs_b.e20.BHIST.f09_g16.20thC.125.02_1990_1999/website/index.html

My preference would be to have this output for every 'successful' line: climo, ts, regrid, etc. but I understand the desire to keep the output minimal as well.

3. Run file with environment loading and qsub syntax
   When I lost my connection half-way through testing and then had to dig back through my notes to find the commands I'd run,
   I wrote myself a run.csh file:

module load python/3.7.12
ncar_pylib
module load nco
./run_adf_diag config_dani.yaml

(Yes, it should have had the qsub command but oh well).

I wonder if it is worth it for us to write an example like this: run_cheyenne.csh or something, not make it general or anything complicated, or we if just let users come around to this for themselves.

[andrewgettelman]

I like the idea for item 3. The other advantage of a tiny run script is we could probably also put in someplace to put the standard output (e.g. diag.log) and stick it in the background (automatic with qsub I guess). So once you have it running it's just edit script, fire and forget.