Memory management improvements

[sjordan29]

I used memory_profiler for instantiation of Clearwater-riverine and running a few timesteps. The following were interesting findings:

• the calculate_required_parameters method is very memory intensive, because transport calculations require a few key variables with dimensions of time by the number of edges, which get very large as the time dimension grows.
• turning off printing intermediate variables in clearwater-modules helped with memory management

Next steps:

• Delete unnecessary intermediate variables from Clearwater-riverine
• Investigate if we can remove FLOW_ACROSS_FACE variable via Comparison of EDGE_VELOCITY versus FLOW_ACROSS_FACE #60 to reduce memory-intensive redundancy
• Leverage lazy loading. See this pangeo discussion and the reading/writing xarray docs.

[aufdenkampe]

@sjordan29, this is great stuff. Thanks for finding and figuring out how to use memory_profiler!

I created this complementary issue that documents some of the approaches we discussed this week.

• Reduce memory usage: zero-copy ClearWater-modules#62

[sjordan29]

A few key findings from the commit above:

1. Unsurprisingly, variables with dimensions of ('time', 'nedge') take up the most memory (the number of edges will always be greater than the number of faces (cells))
2. coeff_to_diffusion has the largest memory of all the variables, even though it has the same dimensions ('time', 'nedge') as the others. this is because it's a float64 whereas the others are float32 (I think because they are read directly from the HDF file and that must be the precision of the RAS output).
3. Leveraging dask and lazy loading appears to have trade-offs between memory and time. It was faster to sel data from the xarray in memory than from a lazy-loaded xarray (when loading the values).
4. I still need to do some exploration of the lazy writing. Not currently working as I had expected.