Su Ars Technica è uscito un articolo sui modelli climatici e sul loro processo di sviluppo: “Perché fidarci dei modelli climatici? E’ una questione di scienza di base – Come i climatologi testano, ritestano e usano i loro tool di simulazione”. Essendo io un professionista di progettazione e sviluppo del software, incluso il test (in generale, la cosiddetta QA, Quality Assurance), l’articolo ha risvegliato vecchie curiosità. Per esempio, quando scoppiò il ClimateGate e parti di codice sorgente usati al Met Office vennero discussi come parte del “leak”, si commentò sulla loro scarsa qualità. In passato ho discusso sulla qualità del codice in ambito scientifico con alcuni colleghi che lavorano in centri di ricerca anche internazionali e mi hanno confermato che possono esserci grandi lacune sulla qualità dal punto di vista ingegneristico. Opinione rafforzata dall’accesso ad alcuni progetti di collaborazione tra università ed industria nel nostro paese. Ma queste sono tutte esperienze anedottiche e relative a contesti molto diversi tra loro: mi rimaneva la curiosità di vedere l’argomento trattato efficacemente da un esperto. Per questo ho letto con interesse l’articolo di Ars Technica; devo purtroppo concludere che è stato una grande delusione e vi spiegherò perché.
Prima di passare all’analisi dell’articolo, permettetemi di fare alcune premesse fondamentali per chi è a digiuno di alcuni concetti di base.
Una veloce introduzione alla gestione della qualità del software
Prima di tutto va fatta una distinzione importante: un modello scientifico basato su software ha, per così dire, due “classi” di qualità. Una è strettamente scientifica, ed è collegata alla validità delle formule matematiche che contiene (su questo campo non ho competenza); l’altra è puramente ingegneristica, ed è collegata alle regole di buona progettazione del software che deve implementare le formule.
Per far capire la differenza, consideriamo questo paragone: un architetto può essere incaricato di realizzare un ponte di nuova concezione. La prima classe di qualità è collegata alla funzione e all’estetica (p.es. è utile al traffico? Risolve un problema urbanistico e/o ne crea altri? E’ bello o brutto?); la seconda alla modalità di realizzazione (Sta in piedi? Ha problemi strutturali? E’ facilmente manutenibile?). Un certo progetto può dare risposte del tutto positive alla prima classe di qualità e negative alla seconda: basta pensare al famoso, o famigerato, ponte di Calatrava a Venezia. Tradotto: nella scrittura di software che implementa un modello scientifico si possono introdurre errori indipendemente dalla bontà del modello di partenza.
Ovviamente, la qualità del software è strettamente collegata allo scopo. Se progetto un sito web o un’ “app” per smartphone, queste cose devono essere belle esteticamente, facili da usare e veloci; ma anche affidabili e in grado di elaborare risultati corretti. Queste ultime qualità saranno meno importanti se stiamo parlando di un gioco, più importanti se parliamo di un sito di commercio elettronico o home banking. Un software scientifico non deve essere necessariamente bello o facile da usare, visto che deve essere maneggiato da esperti; però, come qualsiasi altro software, deve essere affidabile e produrre risultati corretti. Nel mondo della QA software c’è una massima: “se non è testato, non funziona”. Cioè: se non ho verificato la qualità, allora come faccio ad sostenere che un certo software ha un valore? Un’utilità?
L’ingegneria del software descrive una serie di pratiche per aumentare la qualità del software: alcune sono collegate alle modalità di realizzazione e agli strumenti usati durante la costruzione (ricorrendo di nuovo al paragone con i ponti, per esempio: ottimizzare il ponte per il terreno dove saranno posati i piloni, usare cemento di qualità adatta, strumenti di costruzione che garantiscono alta precisione), altre vengono eseguite a fine lavori o periodicamente (prove di stabilità, di carico, di resistenza allo stress, il collaudo prima dell’esercizio, la manutenzione durante tutta la vita operativa). Ora, il paragone con l’ingegneria civile è utile all’inizio, ma ad un certo punto diventa inadeguato. Un ponte, una volta costruito, resta a lungo così com’è: subirà manutenzione ogni tanto e molto raramente, in certi casi mai, verrà modificato per nuove esigenze. Invece il software, vista la sua natura virtuale, può essere disfatto e rifatto facilmente, tanto più che si dice essere in “evoluzione continua”: siamo tutti abituati ai continui aggiornamenti di sistema operativo dei nostri tablet o laptop, per correggere bug o introdurre nuove funzioni. Uno dei problemi base della QA è proprio aggiornare un software, correggendo difetti o aggiungendo funzioni, stando ben attenti a non “rompere” quello che prima funzionava bene; e a fare questo lavoro in continuazione: in questo modo si è sicuri che il software mantiene un “valore”, cioè è in grado di erogare un servizio di qualche utilità (far guadagnare soldi ad un’azienda, o aiutare il processo scientifico). La frequenza di aggiornamento di un software varia: chi è bravo usa i cosiddetti “metodi agili” che consentono di mettere a disposizione nuove versioni anche ogni 1-2 settimane; metodi più tradizionali in generale ragionano in termini di mesi. Lo stato dell’arte nella progettazione di software si chiama “integrazione continua” e prevede che un team di sviluppo competente sia in grado di coniugare questa dinamicità con una prassi di QA consistente e un livello di qualità garantito.
Un punto chiave differenzia un software industriale da uno scientifico come nel contesto che stiamo affrontando: nel primo caso, le “regole del gioco” (che potrei anche chiamare modello) non sono in discussione. Che sia un videogioco o una banca, c’è un esperto che vi sa dire che, a partire da certe condizioni iniziali, una certa sequenza di operazioni vi porterà ad un ben certo stato finale. Il succo della QA è di testare un gran numero di scenari e verificare la conformità dei risultati dell’elaborazione con i risultati attesi definiti dall’esperto (e a fare tutto con il costo più basso possibile). In caso di mancanza di conformità, il software è bacato e si applicheranno quindi azioni correttive finalizzate ad aggiustarlo. Mai viene messa in dubbio la validità del modello. Nel secondo caso, quello scientifico, le “regole del gioco“ dovrebbero essere in discussione. Infatti, quando manca la conformità nel confronto con un dato sperimentale (ad esempio una serie storica di temperature), come si può capire se l’errore sta nel software o nel modello scientifico? Il dubbio che mi pongo è: non è possibile che un’azione correttiva venga focalizzata esclusivamente sul software, “forzandolo“ così impropriamente a produrre un certo risultato? Onestamente, già nel mondo industriale vedo forzature indescrivibili; perché non devo pensare che esistano anche in ambito scientifico? Quali prassi operative esistono per gestire queste situazioni? Io speravo di leggere risposte nell’articolo di Ars Technica, ma non le ho trovate; anzi, ho trovato un curioso modo di ragionare…
L’articolo di Ars Technica
Ars Technica ha intervistato Steve Easterbrook, informatico presso l’Università di Toronto, che ha visitato una sede dell’UK Met Office e ha analizzato i processi di qualità del software che stanno dietro ai modelli climatici ivi sviluppati. L’articolo è stato commentato anche su Bishop Hill e farò riferimento anche ad alcuni interessanti osservazioni comparse su quest’ultimo sito.
Prima di tutto, anche riallacciandomi ad una recente discussione di CM sulla necessità di mantenere ruoli separati in ambito scientifico, si noti che Easterbrook lavora per un dipartimento che si occupa di Climate Change… Non voglio pensare male, ma con così tanti esperti di qualità del software che ci sono per il mondo, non se ne poteva prendere uno che non ha interessi in climatologia? Vabbè, il conflitto di interessi sembra davvero un problema sottovalutato…
Vediamo le prime affermazioni:
Easterbrook has argued against the idea that an independent verification and validation protocol could usefully be applied to climate models. One problem he sees is that climate models are living scientific tools that are constantly evolving rather than pieces of software built to achieve a certain goal. There is, for the most part, no final product to ship out the door. There’s no absolute standard to compare it against either.
Easterbrook ha contestato l’idea che verifiche indipendenti e protocolli di validazione possano essere utilmente applicati ai modelli climatici. Un problema che vede è che i modelli climatici sono strumenti scientifici “vivi” che sono in costante evoluzione piuttosto che pezzi di software creati per un certo scopo. In molti casi, non c’è un prodotto finale da vendere. Non ci sono standard assoluti a cui fare riferimento.
In base a quanto ho scritto sopra a proposito dell'”evoluzione continua” del software, questo commento è privo di senso. Certamente esistono differenze tra un software scientifico, uno industriale ed uno per “utenti finali”, ma non è l’aspetto evolutivo che fa la differenza: qualsiasi software è in continua evoluzione e le pratiche di integrazione continua tengono conto di questa esigenza. Non posso pensare che non esistano standard di riferimento per il test del software scientifico: le prassi di QA sono state sviluppate con molte varianti proprio per adeguarsi opportunamente a diversi contesti.
Forse Easterbrook si riferiva a problemi sul costo della QA? E’ un’obiezione frequente. Le attività di QA hanno un certamente costo aggiuntivo rispetto allo sviluppo, così come ce l’ha il collaudo di un ponte. Ma se non ci si può permettere il costo di un collaudo, credo che siamo tutti d’accordo che il ponte non s’ha da fare: non si spreca denaro per un’opera inutilizzabile o poco sicura. Voi salireste su un ponte non collaudato? Prima vi avevo parlato di diversa importanza dell’affidabilità nel contesto (videogioco o home banking); bene, mi aspetto che l’investimento nella QA sia proporzionato al ritorno dell’investimento atteso: per il videogioco spenderemo un tot in QA, per l’home banking molto di più. Ora, se parliamo di scienza che definisce policy mondiali, non stiamo ragionando ai massimi livelli? Per dirla con Bishop Hill:
How can you have a model that can’t be built and tested to engineering standards informing policy?
Come puoi avere un modello che non può essere costruito e testato su standard ingegneristici e [allo stesso tempo] condiziona una policy?
Quanto all’esistenza di verifiche indipendenti, cioè effettuate da persone diverse dagli sviluppatori, non sono un problema del software in sé, ma del contesto in cui è usato. Certamente, se io ho un’azienda che sviluppa un certo prodotto, non sono obbligato a farlo verificare da terzi, anche perché ho il diritto di mantenere un segreto industriale. Il rischio è tutto mio: se non sono capace di farlo funzionare, la mia azienda fallirà ed amen. Ma qui stiamo parlando di scienza: la verifica indipendente dev’esserci già sui concetti, figuriamoci se non dev’esserci sul software. E il prezzo del fallimento non sarà l’investimento privato di un singolo imprenditore, ma lo spreco di grandi quantità di denaro pubblico a causa del condizionamento delle policy (per tacer del fatto che policy sbagliate possono produrre danni ben peggiori della semplice perdita di denaro).
Easterbrook poi afferma:
“One of the biggest sources of confidence in the models is that they give results that are broadly consistent with one another (despite some very different scientific choices in different models), and they give results that are consistent with the available data and current theory,”
Una delle maggiori fonti di confidenza dei modelli è che danno risultati che sono grandemente consistenti l’uno con l’altro (nonostante alcuni approcci scientifici molto differenti in differenti modelli), e che danno risultati che sono consistenti con i dati disponibili e la teoria corrente.
Non commento la parte sulla consistenza dei modelli perché l’argomento non ricade nello scopo di questo post. La seconda parte della frase, sulla consistenza dei risultati con la teoria, è il ragionamento curioso di cui vi parlavo nella mia introduzione. E’ un ragionamento circolare: sembra che per Easterbrook la conferma della qualità del software di simulazione un modello derivi dalla consistenza che il software ha con la teoria. Ma è proprio il contrario: siccome il software deve dare una conferma o una smentita alla teoria, esso dovrebbe avere un criterio di validazione di qualità indipendente! Un mondo alla rovescia…
Infine, un commento sempre su Bishop Hill, a difesa del pezzo di Easterbrook, dice che:
You shouldn’t throw out all of the information that you gain from the models, because one small part of the model is inadequate or experimental. It would be foolish to ignore robust information gained from these things – and no matter which way you slice it, lots of the information from climate models is robust. Climate science isn’t the only place that you see these big models being used. There is lots of literature on galaxy formation, nuclear physics etc.
Non dovremmo buttare via tutte le informazioni fornite dai modelli, solo perché una piccola parte del modello è inadeguata o sperimentale. Sarebbe sciocco ignorare informazioni consistenti fornite da quste cose – e non importa come lo presenti, molte informazioni fornite dai modelli climatici sono robuste. La climatologia non è l’unico posto dove vedi usare questi modelli complessi. Ci sono grandi quantità di letteratura [scientifica] sulla formazione delle galassie, la fisica nucleare, eccetera.
E’ ragionevole pensare che se un software è difettoso non è necessariamente vero che sia tutto da buttare… ma come faccio a distinguere le parti corrette da quelle sbagliate? Solo una buona prassi di QA che mi permetterebbe di capirlo. Che fondamento ha quell’asserzione sulla robustezza di informazioni? Mi sembra che ricadiamo nella precedente logica circolare. Per quanto riguarda il paragone con problematiche analoghe in altre branche della scienza, come l’astrofisica, faccio mia la risposta di Bishop Hill:
Can we think of other models on the scale of a GCM with policy relevance?
Possiamo pensare ad altri modelli della scala di quelli climatici che abbiano rilevanza politica?
In altre parole: se la nostra conoscenza sull’evoluzione delle galassie si rilevasse sbagliata per via di un modello farlocco, non subiremmo grandi conseguenze, visto che questa conoscenza incide ben poco sulla vita quotidiana. Altre scoperte della fisica nucleare, invece, incidono potenzialmente tantissimo, ma pensate solo a quanto lavoro sperimentale è stato fatto per verificare il modello che prevede il Bosone di Higgs. Come dicevo prima: non è che hanno validato il software dei modelli del Bosone perché produceva risultati consistenti con la teoria; hanno piuttosto messo in piedi un grandioso esperimento, facendosi guidare dai modelli per non andare a casaccio, e l’esperimento ha validato i modelli, che a cascata hanno validato la teoria.
Conclusione
Francamente, quando si parla di qualità nel software c’è solo un concetto chiave da spiegare, dal punto di vista ingegneristico: senza una robusta prassi di QA non si può sapere se un software è affidabile e produce risultati corretti; quindi non si può sapere se serve a qualcosa. Nell’ambito scientifico ero curioso di leggere quali prassi permettono di distinguere gli errori nel modello da quelli della sua implementazione in software. In tre pagine, invece, Ars Technica ci ha propinato delle grandi arrampicate sugli specchi o ragionamenti circolari. Rimane poi la mia delusione per il fatto che Easterbrook è rimasto molto generico nelle sue affermazioni e avrei invece voluto leggere qualche riferimento dettagliato alle prassi e agli strumenti di QA utilizzati dal Met Office…
Consiglio la lettura dei commenti al post di Bishop Hill (su Ars Technica purtroppo i commenti svaccano subito): trovere ulteriori esempi e paragoni per capire meglio la questione.
Mi senbra abbastanza ambizioso pretendere un QA sul cosiddetto “software scientifico” dei modelli climatici. Infatti con questa definizione si intende, mi pare, l’insieme di equazioni che tentano di descrivere la fisica, chimico-fisica, fluodinamica, termodinamica del clima, comprese le ipotesi di interazioni e feedbacks vari. In pratica, la scienza del clima. E chi farebbe il QA? Qualcuno ci ha provato (Science is settled!). Evidentemente, ad oggi il “software scientifico” dei modelli climatici NON E’ SETTLED. Infatti come si sa, c’e’ un certo dissenso a livello scientifico su tante delle ipotesi assunte (climate skeptics etc).
Ci sono ancora molti aspetti della scienza del clima da sviluppare e cè ancora molta ricerca da fare. E forse, ……science will never be settled.
Caro Carlo, se segui il link che ho fornito e comprendi cosa è il QA, capisci che la tua osservazione non è pertinente. Il processo di QA per definizione si occupa di assicurarsi che l’implementazione del software sia confacente alle specifiche; non si occupa di verificare la correttezza delle specifiche. Il QA non serve quindi a validare il modello scientifico del clima, che come dici spetta agli scienziati e non è neanche detto che mai si avrà; ma serve ad evitare che, oltre alle imperfezioni del modello, il software poi faccia ancora un’altra cosa.
Esempio. Immaginiamo che un’azienda che si occupa di satelliti GPS sviluppi un modello per la loro gestione basato sulla fisica classica. Farebbe un errore, perché la precisione sulla misura del tempo richiede un modello relativistico. Comunque, ad un certo punto farebbe realizzare un software di gestione basato su questo modello. Oltre agli errori inerenti al modello, il software può contenere errori di implementazione, perché i programmatori non sono perfetti. Se l’azienda mi incaricasse di seguire il processo di QA per quel software, il mio compito sarebbe esclusivamente di verificare l’assenza di non conformità tra l’implementazione del software e il modello; non sarebbe mio compito contestare il modello (io potrei benissimo non capirci niente, perché non è il mio lavoro). Il QA quindi serve solo ad eliminare il “secondo livello” degli errori, non quelli relativi al modello teorico.
Caro Fabrizio, ti ringrazio della tua esaustiva precisazione su cui concordo
“sono nient’altro che la solita solfa, sentita centinaia di volte e centinaia di volte”
Traparentesi, è veramente patetico come dici tu. Nel mio lavoro sono abituato a fornire consulenza ad aziende sul versante del testing e uno dei tormentoni più ricorrenti è “eh, sì, la QA è importante, ma questa cosa non si può testare facilmente / non si può testare a basso costo / non si può testare e basta”. Se ci sono difficoltà nella QA è quasi sempre perché l’engineering è scarso in partenza. Ma soprattutto un esperto di QA non giustifica questo atteggiamento! Semmai lo contrasta.
“la confidenza nei risultati dei modelli deriva dall’agreement che i modelli stessi mostrano fra loro”
Qui avevo scritto una divagazione che ho poi rimosso in fase di editing, perché usciva dall’ambito puramente ingegneristico che mi ero dato. Ma mi ricordavo, per esempio, che qui su CM tempo fa si commentava che i modelli esibiscono agreement non uniforme, ma raggruppabile in “famiglie” (ad es. i modelli fatti negli USA vs quelli nel resto del mondo); come dire, mi sembra fosse un commento, che questo comportamento può essere un segnale di bias, e non certo una conferma di validità.
Complimenti anzitutto a Fabrizio per il bellissimo articolo pieno di cose sagge e che condivido in tutto.
Rimarco solo che le perle propinateci da Steve Ruscello di Pasqua sono nient’altro che la solita solfa, sentita centinaia di volte e centinaia di volte contestata, senza alcun risultato concreto:
Easterbrook dice in sostanza che:
– i modelli non si possono verificare perché continuamente cambiati dagli sviluppatori (patetico)
– la confidenza nei risultati dei modelli deriva dall’agreement che i modelli stessi mostrano fra loro (e qui immagino che Galileo, per il quale l’unico metro di giudizio era il confronto con la realtà, si rivolterà nella tomba. E qui io mi domando dove sono i fisici figli di Galileo che dovrebbero contestare tali bestialità?).
Vedete, il dramma sta nel fatto che nessuno (maistream scientifico, politica, media, industria, ecc.) ha il benché minimo interesse a contestate queste castronerie (che poi sono in sostanza l’ideologia fondate dell’allegra confraternita dei gestori di GCM), per cui ci terremo i modelli e i loro risultati.
E dato che poi i modelli vengono continuamente cambiati, immagino che nel giro di 30-40 anni i modelli stessi finiranno per dar ragione a Lindzen, il quale da decenni sostiene che al raddoppio di CO2 l’incremento di temperatura al suolo sarà in media di 1-2°C rispetto al pre-industriale. Peccato che a quel punto la bolla speculativa della green economy si sarà mangiata tutto il mangiabile.
Good bye occidente!
Ottimo articolo!
Qualche giorno fa ho postato un breve articolo avente ad oggetto la scarsa conoscenza della fisica alla base dei modelli climatici che, pur limitata a qualche sottosistema del modello, era in grado di generare errori che, propagandosi alle altre parti del modello, inficiavano gli output di tutto il modello.
Oggi scopro che i modelli lasciano a desiderare anche dal punto di vista delle verifiche di qualità: andiamo di male in peggio!
Ritornando all’esempio del ponte è come se io progettassi il ponte sulla base di formule sbagliate o applicando le leggi della Scienza delle Costruzioni in modo approssimativo e, alla fine, mi rifiutassi anche di sottoporre a collaudo la struttura! A me capiterebbe di essere soggetto a procedimento penale e, se dimostrata la colpevolezza, condannato alla galera ed alle pene accessorie (sospensione dall’esercizio della professione di progettista di strutture).
Da poco, per esempio, ho ricevuto un file in cui il progettista del mio software strutturale mi comunica, con tanto di dati a corredo, che il software, utilizzato per il calcolo di un ponte, ha previsto delle deformazioni che si sono rivelate perfettamente consistenti con la realtà sperimentale (collaudo).
Si vede che i climatologi sono “più uguali” degli altri professionisti! 🙂
Ciao, Donato.