taw read from file depends on X/Y instead of constant

[remicousin]

I ran into a couple of issues in order to this and what I propose here is probably the start of the discussion rather than the final solution. I am also going to add some comments to point out some specific problems that led me to do some changed.

rr_mrg's and taw's X/Y are the same by design but they respectively are double and single precision. That caused the tiling to create tiles of different sizes (by 1 point), resulting in water balance algo to fail (see more details below -- but water balance algo expects coordinates of same name to be identical througout its inputs).

converting rr_mrg's X/Y to single fixed the tiling problem, but water balance was still failing. Turns out that one of the two sets of X/Ys had many values with tailing ...00001. Yet, there are a series of broadcast used in water balance algo to set the stage for the computation, and so as a result, say latitudes y and y+0.000001 were both broadcasted, leading to wrong objects, of differing sizes not allowing the water balance algo to go through.

Inspired by this conversation, I resorted to override-align taw against rr_mrg. This made the initial precision conversion useless and so I commented out to keep it just for the story-telling here for now.

[aaron-kaplan]

This is fine. I don't have a precise explanation for the errors you described, but they both have to do with concurrent access to a global resource by multiple concurrent threads or processes. It might be between python threads (though I don't think so because maproom_monit.py sets threaded=False) or between dask workers. In any case, eliminating the global variable taw is the right solution.