68 smrf integration

[scotthavens]

Focusing on a better integration of SMRF and Pysnobal to reduce code duplication. The old AWSM version had many things as just functions passing around an AWSM instance. This moves to a class based approach to house all the same functionality with expanded testing.

• SMRFConnector class to manage the connection between AWSM and SMRF. This can perform the standard run_smrf or keep a SMRF instance to fun specific timesteps
• Pysnobal class to manage the actual iSnobal simulations. There are 3 ways that this works, 1) reading netcdf files and running pysnobal, 2) running smrf_ipysnobal that runs pysnobal after each SMRF timestep or 3) smrf_ipysnobal threaded where pysnobal is added to the SMRF queue to get data from the queue
• Pysnobal configuration was split up over many files, tried to consolidate. pysnobal_io is still there but will wait until Make netcdf files more verbose #41 and combining the files proposed in AWSM roadmap #71
• Testing was expanded to utilize a few gold files but test many different combinations of the AWSM configurations to ensure that nothing was missed.
• There is a new _only_for_testing in Pysnobal. The gold files were created from SMRF output in NetCDF files which are 32-bit. When running smrf_ipysnobal these are using the 64-bit values to run pysnobal which leads to float errors that are larger than I was comfortable with for assertion. Therefore this function that is only used in testing converts the data type to float32 then back to simulate writing to disk.

This requires the SMRF PR #188 that adds better API functionality to SMRF.

Note: this overhaul is still a work in progress and some scripts like run_awsm_daily are broken.

[scotthavens]

ipysnobal.py is still a bit of a mess and could use still be DRY'd out. Not full sure what else can be smoother but perhaps consolidate how Pysnobal is ran instead of it being broken up into a few methods.

[jomey]

I am torn on this. Did you try to do the casting and then comparison in the test suite with a helper method?
If possible I tend to approach testing specific issues this way.

[scotthavens]

I'm not a huge fan of this either... The problem is that the SMRF data needs to be converted before running pysnobal. Therefore, it has to happen within AWSM and not in testing. Or we do all calculations in 32-bit?

[jomey]

What downside would a 32-bit calculation have? I could not think of any for the current

[scotthavens]

The one downside I see is that numpy is 64-bit by default. The main problem is that iSnobal C code expects double so it'll have to be converted at some point. So a potential solution would be to have an option to do single or double precision and keep everything at 32-bit for testing.

Might actually be able to pull this off within netcdf. It appears that you can write 64-bit variable. I'll look into it but will require a new option for SMRF.