Dati per la test suite

[spanezz]

In #48 on iniziato una test suite.

L'idea al momento è di avere un file .arkimet con gli input necessari per generare uno step di una ricetta, e scrivere un test che la genera per cosmo, per ifs, con arkimet, e con eccodes. Al momento l'ho fatto per hcc.

I dati in input sono però troppo grandi per essere committati in git. L'idea per il workaround sarebbe fare una tarball coi dati di test, e uploadarla all'interno dei dati di una release in github

[brancomat]

Idea iniziale al momento naufragata:

Ho provato a rilanciare con tristissime condivisioni gugoldraive tipo ifs_ita010: https://drive.google.com/uc?export=download&id=1kQZpj63SwgCtBEgSHEPFApcGkVEygMdK cosmo_5M_ita https://drive.google.com/uc?export=download&id=1fQeSgjRUaKgotFYbLHsayia9Rq9ZEcN1

ma sono incappato in una serie di problemi mistici https://stackoverflow.com/questions/37453841/download-a-file-from-google-drive-using-wget (soprattutto per i dati di cosmo che superano i 100Mb)

rimando la questione che ho esaurito le scorte giornaliere di parolacce

[spanezz]

Chiarifico che non mi interessa comunque avere tutto l'output di un run di modello per i test, ma solo casi specifici: non so se ci stiamo in 10Mb, ma probabilmente ci stiamo in 100.

Per dire, al momento son 373k con solo l'input per hcc, immagino che quando iniziamo ad aggiungere test case per ogni ricetta, cresca in proporzione. Per fare una stima cazzara, 400k per 20 ricette son già attorno agli 8Mb.

Facciamo che al momento ci passiamo un tar tra noi, e in futuro ci ritroviamo a parlarne?

[brancomat]

Ok, tieni conto che i due file di cui sopra non sono un output completo ma sono il risultato di arkimaps print-arki-query con le ricette attuali, probabilmente cosmo lievita per i livelli isobarici non filtrati (oltre che per estensione), dovrei vedere quanto si risparmia facendo query sequenziali (isolando i dati necessari alle singole ricette) al posto di una unica.

[brancomat]

Ho fatto dei test con query sequenziali solo sulle attuali ricette implementate, ifs è intorno ai 10Mb ma cosmo si attesta comunque serenamente sui 150Mb.

Propongo la seguente soluzione: https://branchini.info/hosting/2021-01-20_cosmo_5M_ita.tar.gz https://branchini.info/hosting/2021-01-20_ifs_ita010.tar.gz

Lì non ho problemi di spazio, potresti attestare la test suite integrando quegli url poi se riesco a cambiare in qualcosa di meno pezzente più istituzionale modifico io i sorgenti mantenendo il contenuto.

Se preferisci una tarball unica mi adeguo (magari dimmi anche se hai idee su come dividere i dati internamente)

[spanezz]

Aggiungo un data point: ho appena finito di aggiungere test case per le ricette per i quali al momento i bug sono stati chiusi: lcc, mcc, tcc, mslp, r2m, wmax; e per hcc.

Tenendo solo lo step 12h per ognuna ricetta, con un input COSMO e un input IFS, la tarball è al momento piccolina (1.5M).

Possiamo sempre scegliere di fare prove su piú step, e si aggiungeranno varie altre ricette tra cui quelle con le scumulazioni che avranno bisogno di piú di un grib in input, per cui crescerà, però possiamo avere una test suite che ha bisogno di meno dati di test che non siano tutto l'output di entrambi i modelli usato dalle ricette per ogni possibile step

[spanezz]

Per intenderci, questo: testsuite.tar.gz

[brancomat]

L'idea è decisamente più furba che fare pacchettoni bulimici. Provo a tornare al piano originale, ho creato una release dal tag 0.1 mettendo il file che hai creato fra gli assets: https://github.com/ARPA-SIMC/arkimaps/releases/tag/0.1

[brancomat]

Ho abilitato il build in CI spostando (e rinominando) i dati per la test suite da questo commento, ad un allegato alla release: https://github.com/ARPA-SIMC/arkimaps/releases/download/v0.4-1/arkimaps_test_data.tar.gz

Ci sono un po' di fallimenti assortiti: https://simc.arpae.it/moncic-ci/arkimaps/202110251104/master/fedora34/build.log

In generale, ho due dubbi: 1) se al posto di un tar esterno tenere semplicemente una serie di grib minimali insieme ai sorgenti 2) se non valga la pena scriptare in qualche modo il processo di creazione della test suite basandosi sui parametri già presenti specificati nelle recipes

[spanezz]

Questo l'abbiamo considerato? https://docs.github.com/en/repositories/working-with-files/managing-large-files/about-git-large-file-storage (però non mi è chiaro se son piú i problemi che risolve o piú i problemi che introduce)

[spanezz]

È possibile committare i grib minimali assieme ai sorgenti. Se non ci interessano i dati presenti nei grib, ma solo la selezione del grib giusto e l'esecuzione degli step, possiamo anche committare dei grib con la parte dati settata a un valore costante:

$ ls -la workdir-cosmo/pantry/cosmo_2d+0.grib
-rw-r--r-- 1 enrico enrico 335168 Mar 13  2021 workdir-cosmo/pantry/cosmo_2d+0.grib
$ grib_set -s values=0  workdir-cosmo/pantry/cosmo_2d+0.grib /tmp/test.grib
$ ls -la /tmp/test.grib
-rw-r--r-- 1 enrico enrico 120 Nov  3 14:14 /tmp/test.grib

Questo può essere un buon punto di partenza, e se ci saranno da testare situazioni particolari che dipendono dai dati, possiamo valutarli caso per caso.

Anche l'idea di scriptare la creazione di una test suite mi piace: ci penso.

[spanezz]

Ho fatto merge in master di issue52. Ora nel repository, in testdata/, dovrebbe esserci tutto il necessario per far girare i test, alla modica cifra di 136Kb.

Ho testato individualmente tutti i test case che usano quei dati, prima e dopo la minimizzazione, per vedere che la minimizzazione non li rompesse.

Ho provato a far girare i test in un checkout pulito, ma ho un test, che non dipende da quei dati, che mi manda in segfault eccodes, quindi non posso dire "da me va tutto", però è un problema che cercherei di risolvere a parte, senza bloccare il lavoro su questo issue.

Non chiudo quindi il bug, ma ve lo passo per review

[dcesari]

Non so se può servire, il comando di libsim:

vg6d_transform [--trans-mode=s] --trans-type=boxregrid --sub-type=average \
 --npx=4 --npy=4 \
 gribin gribout

trasforma un grib facendo la media su blocchi di 4x4 punti (ovviamente si possono usare altri valori), per cui può essere utile per ridurre la risoluzione e quindi le dimensioni di un messaggio senza ridurne significativamente l'area geografica e mantenendo un contenuto informativo ragionevole, nel caso serva avere dei numeri veri che occupano poco spazio.

[spanezz]

Grazie, ho aggiunto l'appunto nel sorgente di minimize, cosí se in futuro ce ne viene il bisogno, dovrebbe essere piú facile ritrovarlo

[spanezz]

La strada dell'azzerare i values dei grib sembra percorribile. Ho aggiunto al repo (al momento nel branch issue52) uno script testdata/minimize che prende un file uscito da arki-query --inline e sostituisce tutti i valori nei dati dei grib che contiene con degli zeri.

minimize richiede arkimet a partire da questo commit che ho dovuto fare per l'occasione.

ecCodes, in codifica, si accorge che i dati hanno un valore costante e li rappresenta di conseguenza, occupando pochissimo spazio.

Ho provato a lanciare minimize sui dati del test di una ricetta, e i test continuano a passare. A questo punto, per i test dove questa è una via percorribile, provo a percorrerla e inizio a committare i dati minimizzati nel repository.

[spanezz]

A posteriori forse questo non stupirà nessuno, però non ci avevo pensato: quando i dati hanno valori costanti, i test ci mettono di meno a girare:

$ time eatmydata nose2-3 --fail-fast tests.test_lcc
....
----------------------------------------------------------------------
Ran 4 tests in 16.885s

OK

real    0m17.218s
user    0m29.963s
sys 0m0.394s

$ testdata/minimize testdata/lcc/* --verbose
2021-11-03 17:42:33 INFO minimize testdata/lcc/cosmo_lcc+12.arkimet:1: GRIB minimized: 335168b → 120b
2021-11-03 17:42:33 INFO minimize testdata/lcc/cosmo_lcc+12.arkimet: size went from 335372b to 322b
2021-11-03 17:42:33 INFO minimize testdata/lcc/ifs_lcc+12.arkimet:1: GRIB minimized: 29248b → 108b
2021-11-03 17:42:33 INFO minimize testdata/lcc/ifs_lcc+12.arkimet: size went from 29438b to 296b

$ time eatmydata nose2-3 --fail-fast tests.test_lcc
....
----------------------------------------------------------------------
Ran 4 tests in 9.647s

OK

real    0m9.979s
user    0m9.882s
sys 0m0.370s