Shorten time period for model used in paper notebook

[Zeitsperre]

Pull Request Checklist:

• This PR addresses an already opened issue (for bug fixes / features)
  • This PR fixes RavenPy paper notebook timeout on CRIM / birdhouse-deploy CI Ouranosinc/PAVICS-e2e-workflow-tests#154
• (If applicable) Documentation has been added / updated (for bug fixes / features).
• (If applicable) Tests have been added.
• CHANGELOG.rst has been updated (with summary of main changes).
  • Link to issue (:issue:number) and pull request (:pull:number) has been added.

What kind of change does this PR introduce?

• Shortens the modelling example in order to reduce the processing time spent running the Perform_a_climate_change_impact_study_on_a_watershed.ipynb notebook
• Fixes a broken test that was not adjusted in Use pooch #513

Does this PR introduce a breaking change?

Not really.

Other information:

The model example is not as accurate now, seeing as the training period has been shortened from 10 years to 4 years. Unfortunately, if we want to run this notebook in our CI pipelines, we can't have notebook cells that might run for 10+ minutes. @huard Can you double-check that the outputs are still relatively accurate with this adjustment?

[review-notebook-app]

Check out this pull request on 

See visual diffs & provide feedback on Jupyter Notebooks.

---

Powered by ReviewNB

[huard]

Just add in the intro a note about the fact that the periods are shorter than what appears in the paper to speed up the notebook's computations.

[tlvu]

Rubber stamp for me. Did you test directly on CRIM pipeline because this notebook only fail on CRIM pipeline. The original version that was supposed to be too heavy was still passing on our Jenkins.

And this notebook did not change recently and was passing before on CRIM pipeline. Did you find out why suddenly it becomes "too heavy" since the newer RavenPy or RavenWPS refactoring with Pooch? Did we accidentally introduced a performance regression?

[tlvu]

Woo, all the unit test failed ! "tests/test_external_dataset_access.py::TestGet::test_get_CASPAR_dataset - ImportError: HTTPFileSystem requires "requests" and "aiohttp" to be installed" This must be existing before this change?

[Zeitsperre]

Did you find out why suddenly it becomes "too heavy" since the newer RavenPy or RavenWPS refactoring with Pooch? Did we accidentally introduced a performance regression?

There aren't any changes within RavenPy that would affect the running of this particular notebook. pooch isn't used for any of the running code there, and testing data isn't grabbed from GitHub.

Woo, all the unit test failed ! "tests/test_external_dataset_access.py::TestGet::test_get_CASPAR_dataset - ImportError: HTTPFileSystem requires "requests" and "aiohttp" to be installed" This must be existing before this change?

I think what may have happened was that either a new release of xarray may have removed these libraries or a new release of h5netcdf may have added DAP-like fetching to its API (which would require Python HTTP request-supporting libs). Not all unit tests are failing (Python3.10 on tox is passing).

[tlvu]

Did you find out why suddenly it becomes "too heavy" since the newer RavenPy or RavenWPS refactoring with Pooch? Did we accidentally introduced a performance regression?

There aren't any changes within RavenPy that would affect the running of this particular notebook. pooch isn't used for any of the running code there, and testing data isn't grabbed from GitHub.

Then either CRIM Jenkins got slower or this notebook hits our PAVICS prod for data and we are slower to respond over the network? It passes on our side because the data is "local", network round-trip is minimal.

What kind of data is this notebook accessing on our PAVICS prod? Maybe some .ncml we recently changed?

[Zeitsperre]

Then either CRIM Jenkins got slower or this notebook hits our PAVICS prod for data and we are slower to respond over the network? It passes on our side because the data is "local", network round-trip is minimal.

My money is on the throughput speed may be slower; Running the original example on my home workstation had some cells hanging for five to 10 minutes. nbconvert is even slower for some reason (affecting the second pass when running on Jenkins; Francis already mentioned this in Ouranosinc/PAVICS-e2e-workflow-tests#154)

What kind of data is this notebook accessing on our PAVICS prod? Maybe some .ncml we recently changed?

I don't think so. It's pulling CASPAR data that hasn't been touched in years. Has the THREDDS version or twitcher version changed?

[tlvu]

nbconvert is even slower for some reason (affecting the second pass when running on Jenkins; Francis already mentioned this in Ouranosinc/PAVICS-e2e-workflow-tests#154)

That's weird, I do not understand why Francis even mentionned nbconvert because that step is skipped by default on his Pipeline ! nbconvert is enable only if we manually trigger a build, not for builds triggered by the pipeline.

Has the THREDDS version or twitcher version changed?

Not recently on our side. Oh but twitcher changed on the tip of master which the pipeline is testing !

[Zeitsperre]

@fmigneault Can you verify that this branch is working better for your infra? I still have a handful of small documentation changes to make, but it should run without timing out now.

[Zeitsperre]

@fmigneault I'll be merging this in an hour or so. LMK if you want more time to verify changes on CRIM infra.

[fmigneault]

@Zeitsperre Sorry. I did not have enough time to look into it. Ok to have it merged. We'll see how the CI reacts using them.