les règles de gradient ne fonctionnement pas tout le temps

[jalazawa]

Il manque peut-être une valeur absolue ici

- expr: ((CTY - lag(CTY)) / CTY) < .5 & ((lag(CTY) - CTY) / lag(CTY)) < .5
  name: CTY_LAG_LT_50
- expr: ((CTA - lag(CTA)) / CTA) < .5 & ((lag(CTA) - CTA) / lag(CTA)) < .5
  name: CTA_LAG_LT_50
- expr: ((BZN - lag(BZN)) / BZN)  < .5 & ((lag(BZN) - BZN) / lag(BZN)) < .5
  name: BZN_LAG_LT_50

```

[davidgohel]

Les modifications suivantes ont été réalisées:

- expr: (abs(CTY - data.table::shift(CTY)) / CTY) < .3 & (abs(data.table::shift(CTY) - CTY) / data.table::shift(CTY)) < .3
  name: CTY_LAG_LT_30
- expr: (abs(CTA - data.table::shift(CTA)) / CTA) < .3 & (abs(data.table::shift(CTA) - CTA) / data.table::shift(CTA)) < .3
  name: CTA_LAG_LT_30
- expr: (abs(BZN - data.table::shift(BZN)) / BZN)  < .3 & (abs(data.table::shift(BZN) - BZN) / data.table::shift(BZN)) < .3
  name: BZN_LAG_LT_30

Le seuil a été aussi baissé à 30% pour pouvoir détecter la cassure exprimée ici: https://github.com/rte-antares-rpackage/antaDraft/blob/master/tests/testthat/test-validation-rules.R#L6

[davidgohel]

il y avait également un souci avec la fonction lag car c'était celle de dplyr qui était avant utilisée. J'ai remplacé par data.table::shift

[jalazawa]

OK, j'ai encore un problème avec ces gradients.

Il faut peut-être avoir une liste de principe quelque part ?

Je propose de rajouter ce principe

• Une mauvaise donnée pourra générer seulement une ligne dans un rapport.

Je vais prendre un exemple BE|CTY|BELGIUM le 2017-03-05 19:00:00

On constate qu'on a une donnée manquante à cet instant.

Que va nous dire augment_validation

sur la première ligne BE|CTY|BELGIUM est bien NA !

sur la deuxième ligne, la donnée est invalide ? --> mais en réalité NON !

La règle sur le gradient nous dit que la donnée à 20h est incorrecte or ce n'est pas le cas.

La donnée a 18h est correcte, la donnée à 19h est manquante, la donnée à 20h est correcte et la donnée à 21h est correcte.

On passe donc d'un donnée incorrecte à deux données incorrectes.

Avec les fonctions qualcon et render_quality, je me retrouve avec une ligne dans un rapport BELGIUM_[CTY_NA] à 2017-03-05 19:00:00 et une ligne dans le fichier BELGIUM_[CTA_LAG_LT_30] à 2017-03-05 20:00:00.

Il n'y a pas ici de problème de gradient mais seulement un problème de donnée manquante.

[davidgohel]

le fichier yaml a été modifié pour ne pas indiquer FALSE quand la valeur précédente est NA

- expr: is.na(data.table::shift(CTY)) | (abs(CTY - data.table::shift(CTY)) / CTY) < .3 & (abs(data.table::shift(CTY) - CTY) / data.table::shift(CTY)) < .3
  name: CTY_LAG_LT_30
- expr: is.na(data.table::shift(CTA)) | (abs(CTA - data.table::shift(CTA)) / CTA) < .3 & (abs(data.table::shift(CTA) - CTA) / data.table::shift(CTA)) < .3
  name: CTA_LAG_LT_30
- expr: is.na(data.table::shift(BZN)) | (abs(BZN - data.table::shift(BZN)) / BZN)  < .3 & (abs(data.table::shift(BZN) - BZN) / data.table::shift(BZN)) < .3
  name: BZN_LAG_LT_30

Le cas est testé dans test-validation-rules.R à la section issue 18 with LAG

[davidgohel]

Les formules sont maintenant:

- expr: (is.na(data.table::shift(CTY)) | sign(CTY) < 1 | (abs(CTY - data.table::shift(CTY)) / CTY) < .3 ) & ( is.na(data.table::shift(CTY)) | sign(CTY) < 1 | (abs(data.table::shift(CTY) - CTY) / data.table::shift(CTY)) < .3 )
  name: CTY_LAG_LT_30
- expr: ( is.na(data.table::shift(CTA)) | sign(CTA) < 1 | (abs(CTA - data.table::shift(CTA)) / CTA) < .3 ) & ( is.na(data.table::shift(CTA)) | sign(CTA) < 1 | (abs(data.table::shift(CTA) - CTA) / data.table::shift(CTA)) < .3 )
  name: CTA_LAG_LT_30
- expr: ( is.na(data.table::shift(BZN)) | sign(BZN) < 1 | (abs(BZN - data.table::shift(BZN)) / BZN)  < .3 ) & (is.na(data.table::shift(BZN)) | sign(BZN) < 1 | (abs(data.table::shift(BZN) - BZN) / data.table::shift(BZN)) < .3 )
  name: BZN_LAG_LT_30

Le résultat sur une valeur négative donne ceci:

          country            DateTime       BZN CTA CTY CTY_NA CTA_NA BZN_NA CTY_IS_POS CTA_IS_POS
179678 LUXEMBOURG 2017-08-13 16:00:00    367.00 367 367   TRUE   TRUE   TRUE       TRUE       TRUE
179679 LUXEMBOURG 2017-08-13 17:00:00    386.00 386 386   TRUE   TRUE   TRUE       TRUE       TRUE
179680 LUXEMBOURG 2017-08-13 18:00:00 -36032.64 401 401   TRUE   TRUE   TRUE       TRUE       TRUE
179681 LUXEMBOURG 2017-08-13 19:00:00    399.00 399 399   TRUE   TRUE   TRUE       TRUE       TRUE
179682 LUXEMBOURG 2017-08-13 20:00:00    414.00 414 414   TRUE   TRUE   TRUE       TRUE       TRUE
       BZN_IS_POS CTY_CTA_EQUAL CTY_BZN_EQUAL CTA_BZN_EQUAL CTY_CTA_DIFF_LT_05 CTY_BZN_DIFF_LT_05
179678       TRUE          TRUE          TRUE          TRUE               TRUE               TRUE
179679       TRUE          TRUE          TRUE          TRUE               TRUE               TRUE
179680      FALSE          TRUE          TRUE          TRUE               TRUE               TRUE
179681       TRUE          TRUE          TRUE          TRUE               TRUE               TRUE
179682       TRUE          TRUE          TRUE          TRUE               TRUE               TRUE
       CTA_BZN_DIFF_LT_05 CTY_CTA_DIFF_LT_10 CTY_BZN_DIFF_LT_10 CTA_BZN_DIFF_LT_10 CTY_LAG_LT_30
179678               TRUE               TRUE               TRUE               TRUE          TRUE
179679               TRUE               TRUE               TRUE               TRUE          TRUE
179680               TRUE               TRUE              FALSE              FALSE          TRUE
179681               TRUE               TRUE               TRUE               TRUE          TRUE
179682               TRUE               TRUE               TRUE               TRUE          TRUE
       CTA_LAG_LT_30 BZN_LAG_LT_30
179678          TRUE          TRUE
179679          TRUE          TRUE
179680          TRUE          TRUE
179681          TRUE         FALSE
179682          TRUE          TRUE

Il faudra surement encore les modifier. Je pense que ces tests devraient plutôt être repensés, voire supprimés de validate et réintégrés sous une autre forme.