Closed tlvu closed 1 year ago
I think I know what the issue is with the error on 03_Extract_geographical_watershed_properties.ipynb
. It looks like the link to that layer is broken. The strange thing is nothing in RavenWPS/RavenPy is asking for that layer. I'm going to remove it and see if that fixes the issue.
I was right. I've removed that broken datastore and the cells for notebook 03 are passing now. This may cause problems elsewhere, but we'll deal with them as they arise.
I spoke too soon. Looks like Birdy v0.8.0 isn't converting objects properly right now:
Birdy has three options for GeoTIFF conversion here, so where's the issue? https://github.com/bird-house/birdy/blob/24dbbd1f1d431b22f918486ab2974019edea4888/birdy/client/converters.py#L252
@huard Do you have any ideas here?
For 05_Extracting_external_data.ipynb
, the notebook relies on a file that is created by another notebook:
basin_contour = 'input.geojson' # Can be generated using notebook "04_Delineating watersheds"
If we can assume that the notebook will run sequentially (can we?), we could add a call to write out this input.geojson
after we've collected it in notebook_04:
I personally don't like this approach, though, as it relies on outputs from another notebook that could fail independently. Is there a better method?
For 06_Raven_calibration.ipynb
, this looks oddly familiar and could be an issue that we've already resolved in a new version of RavenPy. @cjauvin, can you confirm?
Sorry I'm not sure I understand what goes on here, as this is not an area of RavenPy I'm very familiar with.
If we can assume that the notebook will run sequentially (can we?), we could add a call to write out this
input.geojson
after we've collected it in notebook_04:I personally don't like this approach, though, as it relies on outputs from another notebook that could fail independently. Is there a better method?
Richard numbered the notebooks so he implies the user will run them sequentially manually but I think this assumption do not hold under Jenkins. We have to find an alternative.
About this, which can be found in a stacktrace above:
model.rvh.hrus=(GR4JCN.LandHRU(**salmon_land_hru_1),)
this has been deprecated for a while in RavenPy: the way to reference rvh
(and others) is now model.config.rvh
.
For 06_Raven_calibration.ipynb, this looks oddly familiar and could be an issue that we've already resolved in a new version of RavenPy. @cjauvin, can you confirm?
And I now realize, many months later, that the answer to this question is thus: yes, that's the case!
The underlying issue with files requiring data from previous-run notebooks has been solved in ravenpy, storing data on raven-testdata for the tutorials. I think this can be closed now.
Description
Since our notebooks are unable to test Geoserver from a dev machine (issue https://github.com/Ouranosinc/pavics-sdi/issues/183), this error is caught only after a go-live on prod of PR https://github.com/bird-house/birdhouse-deploy/pull/136.
Steps to Reproduce
http://jenkins.ouranos.ca/job/PAVICS-e2e-workflow-tests/job/master/1277/consoleFull
There are more errors, but they mostly are variations of the following errors.
03_Extract_geographical_watershed_properties.ipynb
05_Extracting_external_data.ipynb:
06_Raven_calibration.ipynb
Additional Information
Similar Finch issue https://github.com/bird-house/finch/issues/206