Propagare il modello agli input derivati

[spanezz]

Questo issue parte da #38.

Al momento, ci possono essere input derivati calcolati diversamente da modello a modello, e input derivati calcolati nello stesso modo per tutti i modelli.

Nel caso degli input calcolati allo stesso modo per tutti i modelli, al momento viene persa l'informazione di quale fosse il modello di partenza, e questa informazione può essere significativa per processazioni future (vedi #38).

Questo al momento permette anche di mescolare dati provenienti da modelli diversi, cosa che in teoria sembra una bella cosa, ma in pratica mi sembra di capire non sia un caso d'uso sensato, e che possa portare a problemi inaspettati.

Servirebbe:

• preservare l'informazione del modello in tutti i passi di postprocessazione degli input
• per input calcolati a partire da piú variabili, scegliere variabili tutte dello stesso modello

[dcesari]

Non mi è chiaro dove risiede l'informazione sul modello? Nella filiera di arkimaps stesso o nel messaggio grib? Nel grib il centre è solo un proxy del modello, un centro potrebbe girare più modelli, ciascuno con le sue tabelle locali specifiche, non è purtroppo stato previsto al WMO un modo standardizzato di codificare il modello nel messaggio.

[brancomat]

@dcesari: dentro arkimaps è possibile specificare un "model" che ti permette di diversificare la stessa variabile se è codificata diversamente. La definizione (e il nome del modello) è interno alla ricetta (vedi ad esempio hzero.yaml) e il modello è deciso con un filtro (custom) che combina chiavi grib quando si usa eccodes come backend o metadati arkimet quando si usa arkimet.

@spanezz: Un possibile problema (più potenziale che reale) che vedo è il seguente: il model finora è stato usato in maniera abbastanza lasca per differenziare una tipologia di modelli solo dove necessario, e potrebbero esserci ulteriori differenze specifiche tipiche solo su alcune variabili che però non portano a ricodificare tutte le variabili con quel modello. Vedi ad esempio wind_inputs.yaml dove erg5 ha il vento espresso in velocità e direzione al posto delle componenti u o v, mentre il resto delle variabili potrebbero rientrare in codifica cosmo o ifs.

Al momento mi pare che erg5 sia l'unica casistica ibrida e le variabili non vengono combinate in maniera mescolata per variabili derivate, ma per essere certo di non avere problemi uno dovrebbe di partenza codificare tutte le variabili di un modello in maniera consistente, e non è sempre agevole.

Se vogliamo mantenere un approccio più morbido un'alternativa potrebbe essere una leggera modifica al punto:

per input calcolati a partire da piú variabili, scegliere variabili tutte dello stesso modello

...e/o con modello non presente (che vorrebbe dire che sono variabili generiche) unito al fatto che magari venga generato un warning in fase di elaborazione quando dentro a pantry convivono variabili elaborate da modelli diversi (eccetto le variabili generiche)

[spanezz]

Appunti extra:

• propago il modello solo se almeno un input ha il modello. Se tutti gli input non hanno un modello, lascio l'output anche lui senza
• per gli input derivati, il model sia tagga l'output che filtra gli input
• vedere se possibile dare warning se una processazione vede dati di piú modelli diversi