file path problem in Hydrological_hindcasting notebook and process

[richardarsenault]

A problem occurs when running the Hydrological hindcasting notebook. After the WPS call is made to wps.hindcasting, we attempt to open the wps response:

[hydrograph, storage, solution, diagnostics, rv] = resp_hind.get(asobj=True)

This fails with this error:

If I try to open it using asobj=False, it works, but the paths are as follows and are not openable:

Clearly the first three (hydrograph, storage and solution) are problematic, so probably this plays a role in the above error?

Any ideas on what could be going on? Thanks!

[huard]

The fact that we end up with * in the file name seems like a bug. Also, it's named aven instead of raven.

The fact that you're not able to open the links is expected since you're not running a web server hosting those files (it's on localhost).

[richardarsenault]

Agreed that it looks like a bug. Looks like the path generation is problematic, but I have no idea where this is being generated. Any ideas I could check out?

Edit: I just checked and in the ravenpy "base.py" there is this:

 patterns = {
            "hydrograph": f"{run_name}*Hydrographs.nc",
            "storage": f"{run_name}*WatershedStorage.nc",
            "solution": f"{run_name}*solution.rvc",
            "diagnostics": f"{run_name}*Diagnostics.csv",
        }

Is it possible this could be causing the notebook via WPS to interpret the pattern incorrectly?

[cjauvin]

Salut Richard, si tu me donnes une recette précise pour reproduire le problème, je peux essayer de regarder ça.

[richardarsenault]

OK, en fait je ne le reproduis que dans les Notebooks de Raven-wps. Il suffit de rouler les 3 premières cellules du notebook "hydrological_hindcasting.ipynb", et le code va planter.

Tu peux changer, dans la cellule 3, asobj=True pour asobj=False pour avoir les paths brisés.

Merci!

[cjauvin]

Donc tu roules RavenWPS localement? Si oui tu le démarres comment au juste? On peut jaser dans Slack aussi si tu préfères, pour une conversation un peu moins à bâtons rompus :smile:

[cjauvin]

Quand plusieurs runs de Ravens sont exécutées en parallèle, RavenPy tente tout d'abord d'agréger les fichiers NC de résultats multiples (pour les hydrographes et les watershed storages) en des fichiers NC unifiés, dans ce bout de logique :

https://github.com/CSHS-CWRA/RavenPy/blob/f63e1e5b967c0d7c17e679c8f9d6d309a94096e6/ravenpy/models/base.py#L476-L482

En passant on peut remarquer que le "r" manquant pour les noms de fichiers que tu listes ci-haut est dû au fait que le nom de ces fichiers provient de l'expression pattern[1:] ici :

https://github.com/CSHS-CWRA/RavenPy/blob/f63e1e5b967c0d7c17e679c8f9d6d309a94096e6/ravenpy/models/base.py#L461

Je ne sais pas pourquoi c'est comme ça, mais ça serait un bug à corriger, et je proposerais ceci : pattern.replace('*', '_ALL_'), pour éviter les problèmes avec l'étoile dans le nom du fichier (qui provient du pattern de glob utilisé).

Donc une fois que ce petit problème est corrigé (il n'est pas la cause de ton bug en fait) et que ces fichiers unifiés ont été créés, quand birdy fait son get pour récupérer les résultats, je vois ceci dans la console du serveur RavenWPS :

ERROR: exceptions.__init__(): Exception: code: 400, description: service, locator: service
NoneType: None
INFO: _internal._log(): 127.0.0.1 - - [18/Nov/2021 20:52:01] "GET /outputs/474e5ffd-48db-11ec-b076-b42e9936cbdd/raven-gr4j-cemaneige-sim_ALL_Hydrographs.nc.dds HTTP/1.1" 400 -
INFO: _internal._log(): 127.0.0.1 - - [18/Nov/2021 20:52:01] "GET /outputs/474e5ffd-48db-11ec-b076-b42e9936cbdd/raven-gr4j-cemaneige-sim_ALL_Hydrographs.nc HTTP/1.1" 200 -
ERROR: exceptions.__init__(): Exception: code: 400, description: service, locator: service
NoneType: None
INFO: _internal._log(): 127.0.0.1 - - [18/Nov/2021 20:52:01] "GET /outputs/474e5ffd-48db-11ec-b076-b42e9936cbdd/raven-gr4j-cemaneige-sim_ALL_WatershedStorage.nc.dds HTTP/1.1" 400 -
INFO: _internal._log(): 127.0.0.1 - - [18/Nov/2021 20:52:01] "GET /outputs/474e5ffd-48db-11ec-b076-b42e9936cbdd/raven-gr4j-cemaneige-sim_ALL_WatershedStorage.nc HTTP/1.1" 200 -
INFO: _internal._log(): 127.0.0.1 - - [18/Nov/2021 20:52:01] "GET /outputs/474e5ffd-48db-11ec-b076-b42e9936cbdd/raven-gr4j-cemaneige-sim_ALL_solution.zip HTTP/1.1" 200 -
INFO: _internal._log(): 127.0.0.1 - - [18/Nov/2021 20:52:01] "GET /outputs/474e5ffd-48db-11ec-b076-b42e9936cbdd/input.txt HTTP/1.1" 200 -
INFO: _internal._log(): 127.0.0.1 - - [18/Nov/2021 20:52:01] "GET /outputs/474e5ffd-48db-11ec-b076-b42e9936cbdd/rv.zip HTTP/1.1" 200 -

Les deux appels vers les NC semblent s'accompagner automatiquement d'appels supplémentaires à des fichiers correspondants .dds, qui ne sont pas là, et qui font donc planter ton birdy avec des erreurs 400.

J'ai l'impression que ceci est une tentative préliminaire de downloader le fichier avec OpenDAP (pas certain) et que peut-être que c'est l'ordre des essais qui est pas bon.. J'ai essayé de regarder dans le code de birdy, dans le bout de cette logique assez ésotérique :

https://github.com/bird-house/birdy/blob/24dbbd1f1d431b22f918486ab2974019edea4888/birdy/client/outputs.py#L43-L73

mais je n'ai rien trouvé d'évident à priori.. @huard as-tu une idée plus précise de ce qui pourrait expliquer ce problème?

[huard]

@cjauvin D'accord avec les solutions proposées pour le pattern. Aucune idée pourquoi on a [1:].

Pour le get, dans birdy on tente en effet d'utiliser opendap pour streamer le fichier, plutôt que de faire une copie locale: https://github.com/bird-house/birdy/blob/1fa66cf314d5276c14b9008ac70408ec2278a489/birdy/client/converters.py#L199

On voit donc une erreur 400 pour l'essai opendap, et ensuite succès pour la copie du fichier netCDF. Quand on roule en mode local, il n'y a pas de serveur THREDDS, donc normal que opendap ne marche pas.

@richardarsenault Quelle est ta version de birdy et owslib ?

[cjauvin]

En fait je viens de me rendre compte que l'erreur produite par birdy (celle qui est reproduite en haut de ce thread) n'est pas une exception, et n'affecte donc pas le flow de contrôle: les objets retournés par resp_hind.get sont valables et utilisables, en dépit de l'erreur. C'est juste l'erreur qui est indigeste et user-hostile, comme tout bon message XML qui se respecte.

[richardarsenault]

@huard C'est une VM toute fraiche de la semaine passée, j'ai tout réinstallé en suivant les procédures dans readthedocs. Donc c'est :

birdy = 0.8.0 owslib=0.25.0

Merci pour le coup de main!

[cjauvin]

@richardarsenault Est-ce que ça fonctionne si tu ignores tout simplement l'erreur (i.e. tu la traites comme un warning) et continues l'exécution du notebook, avec les objets retournés par resp_hind.get? Selon ma compréhension, ça devrait.

[richardarsenault]

C'est un peu embarrassant... la réponse est oui, ça marche pour la suite. Je ne sais pas pourquoi j'ai bloqué là! Je pense que quand j'ai vu le message en rouge, j'ai essayé de faire "asobj=False" et j'ai vu que le path était brisé alors je me suis dit que ça devait être un bug.

Mais le code continue après le rouge, et même le path brisé avec "asobj=False" peut être cliqué et le fichier téléchargé. Donc en somme je pense que ce n'est pas tant un bug qu'un warning étrange avec des conséquences étranges mais pas graves?

Désolé pour ce trouble, clairement ce n'était pas sur le chemin critique...

[cjauvin]

Ce n'est pas du tout embarassant à mon avis.. les erreurs de WPS (avec leur XML épeurant) sont particulièrement "user-hostile" et peu informatives, et c'est complètement normal d'avoir eu l'impression que le flow de contrôle était bloqué, au-delà de ça. En fait je m'en suis même rendu compte un peu par hasard moi-même! Faudrait trouver un moyen de faire en sorte que ça ait plus l'air d'un warning que d'une erreur en fait..

[richardarsenault]

Ouais ça serait définitivement un plus pour l'expérience usager, ou au moins on pourrait indiquer dans le notebook que c'est normal qu'un message popup en attendant et que ce n'est pas grave...