Improve custom forcing

[Daafip]

Look at making more intuitive: want to keep flexible but simple: either define:

• [x] camels txt file: forcing.txt,
• [x] simply provide a xarray forcing.nc

moved to bulletpoint to #18 (https://github.com/eWaterCycle/ewatercycle/pull/393)

• [x] Refactor forcing_file attribute to camel_txt_file -> as essentially its now a txt file of specific class which the from_camels functions is run on in model startup
• [x] Currently the the selection of dates for camels forcing is exclusive, change to be inclusive:
  • ds = ds.isel(time=(ds['time'].values > start) & ((ds['time'].values < end)))
  • or atleast check how it should be: kinda strange now - leads to errors in the las ttime step
• [x] Add a from_nc function to check user supplied datasets for correct dates and variable rather than leaving this for the model to do: docker tracebacks arent most useful
• [x] Currently new timestamped forcing '.nc' file is created each time code is run:
  • either remove timestamped aspect and check if exisits
    • downside is if we move the time window its no longer correct
  • or in finalize remove any forcing objects created (probably better approach?)
• [x] from ewatercycle.forcing import HBVforcing should work, but currently doesn't

[BSchilperoort]

Hi David, the eWaterCycle forcing should be finished and available soon.

You will get a forcing object, from which you can access the variables as such: forcing["pr"] which will return the xr.DataArray containing precip. (Makkink) potential evaporation will also be added.

[Daafip]

Awesome, thanks!

[Daafip]

Tested to work with Makkink forcing. Currently still slightly ''dev' though, should be impoved to be more eWaterCycle like:

• [ ] loading and saving, like Makkink:

  ERA5_forcing = ewatercycle.forcing.sources["LumpedMakkinkForcing"].load(forcingLocation)

• [x] let user handel files rather than temporary ones