Un ricordo di Daniele Fraternali

Perdita…

Non è passato nemmeno un mese, da quando Daniele ci ha lasciati.

Passo davanti alla sua scrivania vuota, e mi viene da piangere. Mi manca, moltissimo. M mancano le discussioni con lui, le litigate a volte (cosa che non accadeva spesso: era una persona mite). Mi mancano le sue osservazioni sintetiche, acutissime, sul cuore delle persone (che riusciva a radiografare sin nel profondo, con un solo sguardo). Mi mancano le nostre conversazioni profonde, intime, sul mondo, sui possibili futuri…

Ma inutile ne dica: chi lo ha conosciuto tutto questo lo ha veduto da sé, e sa di cosa sto dicendo.

E in molti hanno avuto avuto la fortuna di conoscerlo, e immagino che come me ne avranno avuta la viva impressione come d’una delle ultime persone rinascimentali.

Ora, però, non vorrei raccontare del Daniele personaggio pubblico,  la sua veste più conosciuta. Desidero dire, semmai, di un Daniele più invisibile. E di un’avventura cominciata ormai un quarto di secolo fa, e che prosegue oggi.

Retrovia

Senza strumenti, non si arriva da nessuna parte.

Questa cosa vale per il signor Pinco, meccanico, come per la signora Pella, tornitrice, o … E certamente non valeva per Roberto Sozzi e Daniele Fraternali quando nei primi anni ’80, al CISE, si buttarono nella nuova esperienza di far funzionare i modelli di dispersione.

Questi, i modelli di dispersione, oggi come allora avevano bisogno, per funzionare, di vari dati di ingresso, tra i quali “la meteorologia”. Questa, però, era costituita da lunghissimi file contenenti non solo dati del tipo normalmente misurato dalle stazioni, ma, anche, indicatori dell’intensità di rimescolamento turbolento, e grandezze come lo spessore dello Strato Limite Atmosferico.

Questi dati “in più” a quei tempi non si misuravano: gli strumenti che lo avrebbero permesso, ad esempio gli anemometri ultrasonici tri-assiali, erano ancora ben nascosti in qualche sperduto laboratorio di ricerca. C’era dunque la necessità di stimarle, cosa che richiedeva di scrivere e usare un “processore meteorologico”.

Permettetemi, qui, una digressione. Scrivere processori meteorologici era, ed è, un lavoro orribilmente noioso. Si rischia di compiere ad ogni passo errori minimi, che però hanno un impatto devastante sui risultati.

E di più: è un’attività invisibile. Agli occhi dei Clienti non riveste alcuna importanza, e non conferisce alcun prestigio. Ma, se non la fai, non puoi dare alcun reale servizio.

Chi non è del ramo, sottovaluta spesso e volentieri le lunghe ore passate davanti ad un terminale, cercando di far funzionare cose complicatissime, senza documentazione, e con la sensazione di non poter ricevere alcun aiuto. Si può dire che ogni ora di lavoro visibile compiuto dalle persone “di linea” ne richiede, o ne ha richieste, tre o quattro di preparazione.

In questo racconto, desidererei rendere visibile, per una volta, questo lavoro sotterraneo.

Ma torniamo, ora, e scusatemi per lo sballottamento, alla noia dei processori meteorologici. Non ne ho certezza, ma mi piace immaginare che l’idea di una libreria capace di alleviare la fatica, che raccogliesse a fattor comune le operazioni più frequenti, abbia preso forma allora. Nelle retrovie. Lontano dai riflettori e dal prestigio.

La PBL_MET

Siamo nel 1993, e intanto sono accadute molte cose.

Tra queste, un fatto piccolo, ma importante: la libreria di codice per facilitare la costruzione di processori meteorologici ha preso una forma tangibile, e con essa un nome, anzi, una sigla insieme imperscrutabile e poco appariscente: PBL_MET.

Quanto a me, più o meno negli stessi giorni in cui Daniele e Roberto presentavano al mondo la nuova nata al workshop di Manno, in Svizzera, ancora mi occupavo di altre cose, di “sistemi programmabili per applicazioni rischiose”. Tutt’altro, insomma. Ma conoscevo da tempo Daniele e Roberto, ed avevo sentito spesso parlare da loro della mitica PBL_MET, e dei suoi molteplici usi, in corso di esplorazione.

Probabilmente non ne avrei saputo più nulla, se non fosse accaduto un evento fortuito: mi chiamarono all’ufficio del personale, e lì il capo delle risorse umane, personalmente di persona, mi informò che il gruppetto di persone che dirigevo sarebbe passato sotto la responsabilità di uno nuovo, con un curriculum meno lungo, ma con il giusto physique du role (personaggio che avrei dovuto “supportare stando nell’ombra, come ogni moglie fedele deve fare” (il corsivo è mio). Il supporto durò tre anni, sino alla chiusura del reparto, e si concluse con le mie dimissioni, nel 1996, ed il mio ingresso in Servizi Territorio. Dovetti (e fu, posso assicurarlo, molto dura) ricominciare da zero, imparando la fisica dell’atmosfera (ed infine innamorandomene), e, cosa che conta qui, partecipando alle attività ed all’uso della PBL_MET.

Una strage annunciata

No, no, non aspettatevi nulla di drammatico. Le vittime non furono persone, né altre creature, ma stazioni meteorologiche.

Uno degli usi meno convenzionali della PBL_MET fu in appoggio allo studio che, intorno al 1996, Daniele e Roberto fecero sulle stazioni meteorologiche presenti in Lombardia. Il lavoro, commissionato dalla Regione, aveva il fine di capire se tra le seicento e più stazioni meteo in carico alla Regione (l’ARPA non esisteva ancora) ve ne fosse almeno qualcuna capace di produrre dati di una qualche utilità. In quella commessa ebbi una particina minore, che mi permise però di vedere i due all’opera.

Il lavoro, nelle sue dimensioni, sembrava scoraggiante. Per ogni stazione, nastri e floppy disk contenenti campioni di dati, dei tipi e nei formati più svariati. Unica costante, il fatto che avevano tutti più o meno a che fare con la meteorologia.

Il piano consisteva, più o meno, nel confrontare i dati di tutte le stazioni con i criteri di qualità della US-EPA, cosa non banalissima ma tutto sommato semplice, se si trascura la logistica. Il vero problema era, però, quest’ultima. Ogni stazione era un mondo a sé, con propri strumenti e finalità. L’anemometro poteva esserci, o no. Alcune avevano un termo-igrometro, altre un termometro (o magari anche due). Una minoranza disponevano di sensori un po’ esotici, per quegli anni, come radiometri globali ed altri. Un confronto diretto dei dati con i criteri EPA non era possibile, senza prima trasformare questi ultimi, e unificarli almeno in parte ad un insieme di grandezze minimo e comune. E fu lì, che la PBL_MET dimostrò la sua utilità. Ciò che non era disponibile per misura, lo divenne per stima.

La fatica improba ve la lascio immaginare tutta: non dico che fu necessario scrivere un processore meteo per ciascuna stazione, ma poco ci mancò. Saranno stati anche abbastanza simili tra di loro, ma i processori scritti ed usati ammontarono a qualche decina…

Ne uscirono vivi, però, ed alla fine la verifica delle stazioni fu compiuta.

Del totale, ne “sopravvisse” una quarantina.

Fumi fosforescenti

Ovvero, l’epopea del modello Radiopuff.

Ma permettetemi un passo indietro. 1994, credo, o giù di lì. L’ISMES, un centro di ricerca dell’ENEL, vinse un bando europeo per la messa in sicurezza della centrale nucleare di Ignalina, in Lituania.

E contattò Servizi Territorio (anzi, nella fattispecie, direttamente Daniele, o Roberto), ponendo loro un problema che avrebbe gelato il sangue di Homer Simpson.

La centrale, letteralmente, faceva acqua. La Lituania si era resa da poco indipendente dalla Russia, ed i Russi per ricompensa avevano abbandonato lì tutta una serie di ricordi, tra i quali, appunto, la centrale di Ignalina (tecnologia Chernobyl, per intenderci: un sito ideale, da lasciare senza manutenzione).

Di spegnerla, non se ne parlava proprio. Mezza capitale lituana era teleriscaldata dalla centrale, e da quelle parti spegnere i termosifoni non è proprio esattamente una cosa pratica.

Però, appunto, la centrale faceva acqua.

E non soltanto quella.

L’ISMES si mise all’opera, per realizzare a tempo di record un sistema per il monitoraggio delle emissioni al camino di… radionuclidi.

Si poneva, a quel punto, il problema di capire dove questi andassero a finire, una volta rilasciati.

La prima parte del problema era, capire dove ricadessero i radionuclidi, una volta emessi. Compito da modello di dispersione, ma che non era trattabile con i normali modelli stazionari allora in uso. Ci voleva qualcosa di più accurato, e la scelta cadde sul modello lagrangiano Mesopuff II.

La seconda, consisteva nel comprendere dove finissero poi i radionuclidi arrivati al suolo, una volta che gli abitanti li avevano inalati. Questa fu, ricordo, una parte piuttosto “divertente”, della quale si occupò Roberto, nella sua veste di ingegnere nucleare. Il modello dedicato (di cui non ricordo il nome) prendeva in esame alcuni organi-bersaglio (polmoni, scheletro, gonadi, …), e per ciascuno di essi stimava la quantità fissata per ogni radionuclide.

A monte dei due passaggi, serviva un qualcosa – un processore meteorologico – capace di trasformare i dati della stazione meteo predisposta da ISMES nell’input meteorologico di Mesopuff II. In tempo reale. Nel 1997, più o meno.

Daniele e Roberto si misero all’opera alacremente, ed alla fine ne uscì il processore OLMET.

Voglio augurarmi che il sistema Radiopuff nel suo complesso, e la centrale di Ignalina tutta, non esistano più da molti anni, per il bene dei lituani.

Ma non posso giurarci…

Ufficio Sinistri, Scrivania Quarantatre Bis, Ragionier Fantozzi Ugo

A volte, l’impatto era inevitabile.

No, non mi riferisco ad incidenti stradali, né al ruolo che in essi aveva la Megaditta. Più modestamente (forse) all’impatto delle ricadute al suolo di inquinanti sull’ambiente, e sulla salute.

Accadeva, di tanto in tanto, che Servizi Territorio venisse interpellata per valutare l’impatto di un impianto sull’ambiente. Cosa che, di regola, prevedeva uno studio di cui la parte più “rognosa” era invariabilmente la componente atmosfera: le emissioni reali erano spesso accuratamente nascoste, i dati meteorologici come minimo bucherellati, i dati d’impianto segreti.

Per affrontare il problema si usavano modelli di dispersione (al mio arrivo a Servizi Territorio, soprattutto ISC). Che andavano alimentati con i dati meteorologici. Cosa che richiedeva un processore meteo. Che, poco prima del mio arrivo, era “adattato al nuovo caso” (eufemismo per significare “rifatto completamente per tener conto dei dati disponibili”).

Vedere lo svolgimento di questi studi era cosa piuttosto interessante: Daniele teneva i rapporti con i Clienti, identificava insieme a loro i fattori di emissione, e una volta disponibili i risultati elaborava le statistiche finali e componeva la relazione tecnica da consegnare ai Clienti. Roberto, invece, prendeva in carico i dati meteo, scriveva al volo un processore meteo adatto allo scopo, lo faceva funzionare, avviava il modello vero e proprio con i dati emissivi passati da Daniele, e verificava che il modello avesse prodotto qualcosa di utile. Una sorta di balletto, con una coreografia consolidata (e qualche improperio, soprattutto da parte di Roberto, quando si presentava qualche intoppo; Daniele, invece, nelle avversità manteneva un atteggiamento compassato, di calma imperturbabile).

Una cosa disturbava i due: la necessità di fare e disfare ogni volta il processore mete. Sì, c’era la PBL_MET, e non era necessario ripartire ogni volta da zero, dalle equazioni di Newton. Però, era comunque una faticaccia.

Un giorno, Daniele chiese: “Ma non potremmo fare un processore meteo unico, una buona volta?”

La proposta implicita cadde nel vuoto, per un po’. Ma alla fine si materializzò in un programma, che se non sbaglio di chiamava PROMET (non brillavamo, quanto a fantasia per i nomi). Me lo ricordo ancora. Un incubo. Una ragnatela di IF-THEN-ELSEIF-ELSE, secondo me infinita, per tener conto di tutti i casi possibili. Così, quando si presentava un nuovo tipo di stazione meteo, bastava aggiungere un nuovo blocco di ELSEIF-ELSE-IF-machecavoloaltro. Poi, quasi nascosto dietro lo sbarramento di istruzioni condizionali, il processore vero e proprio (e trovarlo non era facile: era un po’ come, mi hanno detto, “cercare il motore della Diane 6” – non so cosa voglia dire di preciso, ma rende l’idea).

Fumi di C18H24O2

Il successore del PROMET fu, o meglio avrebbe potuto essere, METPRO. Posso dirlo: fu un’invenzione tutta mia. Devo, qui, però, aggiungere due delle mie solite premesse.

La prima, era che Roberto continuava a parlare sempre più spesso, e con frequenza ormai allarmante, di Reti di Petri.

La seconda, che al tempo il mio Sistema di Funzionamento a Corrente Alternata Mensile andava ancora, e benissimo. Chiariamo qui un concetto: sono una scarpa. Ma nei due-quattro giorni di picco del ciclo non me ne rendevo conto, e nella mia euforia generale mi lanciavo in imprese che sana prudenza avrebbe suggerito di evitare accuratamente.

L’Impresa delle Imprese fu la realizzazione (non chiedetemi in che modo) in due giorni di un interprete di Reti di Petri agganciato alle chiamate della PBL_MET, che battezzai appunto METPRO. Nulla di che, ma, in pratica, un processore meteo configurabile.

Credevo di avere inventato la geniata del secolo.

Invece, ne ho combinata una delle mie. Temo.

Ricordo ancora l’espressione perplessa di Roberto, quando vide il mio parto d’ingegno (diciamo così) per la prima volta.

Daniele è stato molto più carino. Però mi ha chiesto, “Mi spieghi, per favore, come funziona?” E questa volta è la mia risposta, che ricordo bene: “Ehm… Veramente… Ecco, se me lo chiedevi due giorni fa, allora te lo dicevo. Però, se mi applico, lo capisco!” (Il “se mi applico”, naturalmente, voleva dire “tra una ventina di giorni”).

Alla fine, non chiedetemi in che modo, fui capace di mostrare che in effetti il coso più o meno funzionava, ma ciò pose un ulteriore problema: e, se fosse caduto in mani concorrenti?

Tenemmo una (burrascosa) riunione a tre, per l’occasione. La tempesta di cervelli che ne seguì, per un paio d’ore, valutò gli scenari più svariati ed impressionanti. Ed alla fine decidemmo che no, forse non era esattamente il caso di procedere per quella via.

E il mio povero, incolpevole METPRO, cucciolo virtuale, finì sepolto in un cassetto, con la promessa solenne da parte mia che mai e poi mai avrei ripetuto “imprese” del genere.

Va bé.

$ ?

Però, un lato positivo nel mio disastro c’era, ed innegabile: con la PBL_MET tra le mani, anche una scarpa come me in fatto di fisica dell’atmosfera poteva realizzare un processore meteorologico funzionante.

Che la cosa potesse valere per qualunque altra scarpa?

Di qui, l’idea di provare a venderla, la PBL_MET.

Fu, con i limiti intrinseci di tutti i prodotti di nicchia, un successone autentico: ne piazzammo ben sei (il corsivo non è ironico: il carattere specialistico della cosa mi faceva dubitare che ne avremmo venduto anche solo uno – ma, tendo al pessimismo…). Le licenze PBL_MET, nella versione sorgente, costavano circa quanto la libreria IMSL, e chi ha più o meno lavorato nel campo sa cosa intendo dire. Decisamente, ben pagata.

Un conto però è scrivere una libreria propria e farne un impiego interno. Tutt’altra cosa, invece, distribuirla come prodotto.

Bisogna, intanto, scrivere manuali e brochures. Occorre compiere test che, diversamente, avremmo fatto solo in base a necessità.

Ed è anche necessario rendere la libreria in qualche modo visibile, scientificamente e commercialmente. Il secondo aspetto precede necessariamente il primo, perché afferma non solo una titolarità intellettuale, ma una proprietà.

La scheda di primissima registrazione della PBL_MET

Che storie… Al tempo, brevettare codici di calcolo non era proprio previsto in Italia (non so nemmeno se oggi lo è, a dire il vero). La sua registrazione avveniva come per la musica, ed altri oggetti d’arte. E mi piace pensare che anche il software, pur nel suo carattere obbiettivo ed ineluttabile (o almeno si spera), sia una forma d’arte. Minore, certo. Più simile agli oggetti meravigliosi di un Cellini, che alle “vere” opere di un Leonardo, o di un Michelangelo. Contiene al suo interno un elemento importante: non si limita a passare ordini e dati ad uno stupido pezzo di vetro drogato con impurità, ma, comunica qualcosa alle persone.

Decidere di registrare il codice, o no, non avvenne senza dibattiti e ripensamenti. Alla fine, però, si decisero, e la scheda testimonia oggi un passaggio. Una traccia visibile.

La presentazione scientifica, invece, avvenne in occasione del secondo workshop sull’armonizzazione dei modelli di dispersione, che si tenne a Manno (Svizzera), a fine Estate del 1993. La PBL_MET, ed i nomi di Daniele e Roberto, compaiono nell’elenco ufficiale dei lavori

https://www2.dmu.dk/atmosphericenvironment/Harmoni/manpaper.htm

Anatomia di un processore meteorologico

Mi rendo conto, ripensando a tutto quello che ho scritto, che mica l’ho detto che cos’è un processore meteorologico, e perché è così importante scriverne uno personalizzato invece che scaricarne uno già fatto da Internet.

Proverò, a memoria, a dire com’era fatto il nostro PROMET (perdonatemi: è archeologia tecnica – ma aveva una struttura si-fa-per-dire-semplice, ed è più facile parlarne).

Dunque. Quando si progetta un processore meteorologico, la primissima cosa è darsi un obbiettivo di “uso del processore”. Nel nostro caso la cosa era chiara: doveva alimentare il modello di dispersione ISC, con i dati nella configurazione massima.

Nel momento in cui scegli l’uso, implicitamente vai anche a dire quali informazioni dovrai produrre. E tra queste ve n’erano due piuttosto, scusate il termine, “rognose”: la categoria di stabilità dell’atmosfera, e la quota di rimescolamento. Tra queste due, quella di gran lunga meno amichevole è la seconda: per stimarla, mancando al tempo la possibilità di misure dirette continue, dovevi fare uso di opportuni modelli fisici, che nelle situazioni stabili erano semplici parametrizzazioni, e nelle convettive le equazioni (differenziali ordinarie) di Gryning-Batchvarova. Parametrizzazioni, e modello G-B, avevano una cosa in comune, piuttosto tragica: la conoscenza di alcuni indicatori di turbolenza atmosferica: velocità di frizione, flusso turbolento di calore sensibile, e lunghezza di Obukhov.

A quel punto si poneva la domanda fatale: quali strumenti doveva avere una stazione, perché dalle sue misure fosse possibile stimare gli indicatori di turbolenza (e le categorie di stabilità) senza abbandonarsi ad un puro procedimento di invenzione creativa?

Detto in modo più aulico, il passaggio da fare è scegliere un percorso di stima. Nel caso di PROMET, scegliemmo un percorso fatto più o meno così:

Percorso di stima del processore meteo PROMET
Percorso di stima del processore meteo PROMET

Implicita nella scelta del percorso di stima, c’è la dotazione strumentale minima. Nel caso del processore PROMET la dotazione minima è composta da:

  • Un termometro.
  • Un anemometro (tipicamente a coppe e banderuola).

Se, poi, la stazione fosse stata dotata di un radiometro globale, o netto, allora avremmo tenuto in debito conto i relativi dati in più: tutto grasso che cola. Il percorso di stima, nel caso, prevedeva dei “bypass” che evitavano di stimare le grandezze misurate.

Perché non un processore meteo già fatto?

E, già: perché no? Dopotutto ce ne sono: AERMET, per esempio.

La ragione che ha spinto Daniele e Roberto a non adoperarli, e che loro hanno condiviso con me, era molto semplice, ma gravida di implicazioni: non esiste un processore meteo definitivo ed univoco. La mera scelta di un percorso di stima non porta da nessuna parte, se ci si ferma lì. Occorre, anche, scegliere il particolare metodo di stima, per ciascuno dei passi del percorso. E vanno, poi, definiti i parametri geognostici di riferimento, se si desidera comporre un processore meteo che non sia esageratamente complicato da usare.

In queste scelte sta il problema. La fisica dello Strato Limite Planetario è ormai bene assestata, dopo decenni di osservazioni. Ma dietro a lei non c’è una “teoria” con potere predittivo intorno alla quale si sia raccolto il consenso di una parte abbastanza grande della comunità scientifica. Micro-climatologia e micro-meteorologia sono oggi discipline eminentemente osservative, simili alla geologia strutturale. Esistono, per queste discipline, dei modelli fisico-matematici: ma questi modelli hanno ancora una natura semi-empirica. Secondo me (per quanto può contare la mia opinione) tale resterà a lungo: la natura stessa della turbolenza atmosferica la rende molto resistente ad ogni tentativo di predizione dettagliata.

La natura semi-empirica della disciplina ha portato ad una lunga evoluzione, che si è manifestata nella comparsa di una vasta pluralità di metodi. “Vasta pluralità”, in funzione delle diverse campagne di misura che si sono succedute nel tempo, nei luoghi più svariati: dall’Antartide, a salire, sino alle Svalbard. Molte decine, e forse centinaia di campagne. Ognuna riflette, anche, le caratteristiche del sito nel quale sono state condotte.

La grandissima maggioranza dei processori meteorologici scaricabili da Internet sono stati scritti negli USA. Ad una latitudine che è collocata molto meno a Nord che in Italia ed in Europa. In siti, caratterizzati mediamente da una topografia dolcemente ondulata, con variazioni relativamente piccole nella rugosità e negli altri parametri. Chi ha fatto questi processori ha scelto le relazioni semiempiriche più appropriate per quella situazione particolare. Chi ha detto, che relazioni valide per la California, a latitudini tropicali, si adattino alle latitudini nordiche dell’Europa? (Per dire solo una cosa molto intuitiva: nei libri americani di micro-meteorologia, quando si parla di situazioni stabili e convettive si ha sempre la sensazione che si presentino circa per lo stesso numero di ore, con forti variazioni stagionali; alla latitudine di Milano, invece, le situazioni stabili prevalgono nettissimamente sulle convettive: vuoto per pieno, 70% contro 30%).

Prudenza dunque richiede che si utilizzino relazioni scelte bene. Adatte al sito. Alle latitudini nordiche – e l’Europa, da Pantelleria in su, è molto a Nord rispetto agli USA. A terreni con una tessitura complicatissima, specchio di una geologia rimaneggiata da migliaia di anni di coltivazioni compiute con pratiche diversissime. Ad un contesto dominato da vasti mari interni (Mediterraneo, Mare del Nord), relativamente molto caldi. Ad una distribuzione di foreste e coltivi molto particolare. Eccetera.

La possibilità individuata da Daniele e Roberto non prendeva scorciatoie: si sono rimboccati le maniche, ed hanno scritto processori dedicati.

Non per tutt*

Scrivere un processore meteorologico funzionante non è cosa da tutt*, quanto a conoscenze. Ma, applicandocisi, “si fa”. Basta studiare, con molta pazienza.

C’è un fatto, però: come accennavo all’inizio dell’articolo, scrivere processori meteorologici richiede molto tempo, che non può essere usato per mettersi in mostra. Il ritorno è nella pura utilità funzionale, non nell’immagine personale.

Un po’ come tutte le attività “fuori linea”, anche questa è a forte minaccia di basso prestigio, non riconosciuta dai sistemi premianti di molte aziende.

Che Daniele e Roberto ci si siano, scusate il termine, “buttati” secondo me rivela un qualcosa. Una passione per l’argomento. Una cura non comune per la qualità e la sensatezza dei risultati. Che, poi, è onestà intellettuale.

Open source!!

Vicissitudini. Nel 2002, Roberto lasciò Servizi Territorio, ed iniziò una brillante carriera in ARPA Lazio.

Daniele, e noi che siamo rimasti*, abbiamo continuato a usare modelli di dispersione.

E la necessità di processori meteorologici non è diminuita. Anzi!

I tempi, però, erano cambiati. Servizi Territorio aveva ricavato dalla PBL_MET di allora tutto ciò che poteva, in termini economici e di utilità, oltre che di soddisfazione.

Aveva senso, proteggerla come un prodotto commerciale?

Ricordo che ne discutemmo, io e Daniele. Il mio cuore propendeva per liberare la PBL_MET, rilasciarla come oggetto open source, e permetterne l’uso a chiunque lo desiderasse. Fu Daniele, però, a prendere la decisione finale.

Il primo rilascio avvenne in sordina, nella pagina di scarico del sito web di Servizi Territorio srl.

Il vero passaggio importante avvenne, però, nel 2012, quando decidemmo insieme di predisporre una nuova libreria meteorologica, che si sarebbe chiamata pbl_met (molta fantasia…)

 

Lascia un commento

Il tuo indirizzo email non sarà pubblicato. I campi obbligatori sono contrassegnati *