Restructure the inputs to GEMB

[chadagreene]

1. The current implementation of GEMB requires the user to manually define >50 constants, variables, and preferences when calling the GEMB function, and I think most of them can be set as defaults that can be overriden according to the user's preference.
2. Some variable names within GEMB are inconsistent between functions and many names are unintuitive and hard to decipher.
3. @alex-s-gardner has been advocating for the time series inputs to the GEMB function to be in table format, and I think that's a good idea because it will force standardization of inputs, eliminate the chance of users inputting variables in the wrong order, and make it easier for code maintainers to follow what's happening inside each function.

To address the points above, I recommend rewriting the input handling of GEMB using arguments, which will allow GEMB to be called in any of the following forms:

Here's simplest-case example:

out = GEMB(input_table)

Above, input_table is a table containing the time series of minimum required variables to run GEMB (air temperature, precipiation, etc).

Overriding the defaults is easy. Here's the same call as above, but overriding the default ice density:

out = GEMB(input_table, ice_density = 917)

Input parsing with arguments makes it easy for the user to manually override multiple defaults:

out = GEMB(input_table, ...
           ice_density = 917, ...
           snow_density = 340, ...
           densification_method = "ligtenberg_2011", ...
           snow_albedo = 0.87)

The ability to restart a run from a previous state could be included like this or something similar:

out = GEMB(input_table, initial_state = restart_structure)

And to save the output, just define an output_filename and the extension will define whether it's a .mat or scientific data format.

GEMB(input_table, output_filename = "myfile.nc") 

Notice that in addition to setting default values, the form I'm suggesting also include renaming variables to be more intuitive and replacing the method-switching index values with descriptive handles like densification_method = "ligtenberg_2011" (which would be defined in the current implementation by S.denIdx = 6).

What do you think about the idea of restructuring the inputs to GEMB as I'm showing above, and propagating those changes into the functions that are called by GEMB?

[alex-s-gardner]

100% on board with all that is mentioned above.