This might be useful if ever rerunning a full day of results following
Met Office results. It has the basic dependencies that exist between
EWS components. It's rudimentary, but beats manually waiting and
watching for jobs to finish before starting the next component.

A much better tool would be a workflow manager with some sort of
'backfill' or 'rerun' option...

This relates to developments to ease the maintenance
of the forecast system. With this development, there is no R code to
actively maintain. Moving from git project wheat-source-generation to
ews-source-generation. The python code has been validated for
identical performance to the R version. The only differences are
small changes from the underlying shapefile reading packages
(see notes-on-rewriting-in-python.txt in ews-source-generation).

Keeping the option to used the R code for some time in case any
follow-up investigation is required.

# Conflicts:
#	ProcessorDeposition.py

WRSIS HTTP response should have 'response' in it which contains the survey information, even if it is empty:
{'msg': 'successful', 'response': {'Rust Survey Data': []}, 'status': '200'}

(cherry picked from commit 0f5e125a)

wiring in the newly separated post_processing module into coordinator, rather than the plotting module

The pre-job is meant to exit quietly if the prerequisite data is not
available yet. However, the epi pre-job check was raising an error
if AlternativeSuccessFileTemplate was missing from the config for
either Deposition or Environment. This is now handled quietly too.
CAUTION: This means the epi component will never raise an error
for missing input data, i.e., no email will ever say epi has failed to
run.

The WRSIS download KEY column is an intger which made a problem in the survey data remove subprocess. The solution is to read the KEY column always as a string.

Date formating is necessery for the WRSIS API.

1) There is now a python alternative to the R-based wheat-source-
generation, called source_gen. The functionality to call source_gen
has been added (see ProcessorSurveys.pyL939 and L1032-1040), but not
yet switched on while we await testing of
output at the Met Office.

2) ProcessorComponents was huge (2100 lines!) and the structure was
not apparent. Each component's supporting functions are now in a
separate directory. There is also a ProcessorServer.py relating to
file down/up-loads. ProcessorComponents is now essentially a directory
 to import all the functions. This might inspire a more systematic
 (object-oriented?) structure for each component within coordinator
 in the future.

9-use-mo-nc-files-rather-than-name

See merge request gilligan-epid/wheat-rusts/ews-coordinator!4

reading NAME.nc files rather than NAME.txt files (#19)