Patrizia Favaron
Carta, penna, calamaio?
Insomma, mica tanto. Oggi, “occuparsi di modelli” (che siano di dispersione in atmosfera, di circolazione a mesoscala, oppure dei sistemi Large Eddy Simulation, o chissà che altro) vuol dire, in concreto, passare una fetta della propria vita davanti ad un computer, scrivendo codice: il vecchissimo modo carta-penna-e-calamaio, oramai, credo si sia estinto da molti decenni.
E comunque, obiettivamente, i computer sono molto comodi: quando non esistevano la gente ne faceva a meno, ma i calcoli della meteorologia dinamica o della micro-meteorologia doveva farli lo stesso: con un regolo calcolatore, o una calcolatrice da tavolo, magari direttamente a mano. Ma, avojja.
“Usare un calcolatore per scrivere codice”, nel campo delle scienze dell’atmosfera, oggi vuol dire lavorare per lo più in Fortran: qualcosa si fa anche usando altri linguaggi di programmazione, ma davvero poco, e la mia impressione è che le cose resteranno a questo modo ancora a lungo, per le ragioni che dirò in seguito.
Animo!
“Ouch. Devo imparare il Fortran…”
Lo si sente dire, o accennare con sguardi sconsolati, ancora oggi. Leggi in rete, e trovi di tutto, ricavandone per lo più l’impressione che imparare il Fortran invece, che so, di Python o C++, sia una condanna a morte, la strada certa a doversi rassegnare alla disoccupazione, o peggio. Che il Fortran è irriducibilmente e irrecuperabilmente vecchio, e che la sola lettura di un manuale che lo riguardi comporti la comparsa di numerosissime rughe.
Chissà, forse per un programmatore le cose stanno davvero così.
Ma la realtà è che la persona che si occupa di modellistica e usa il Fortran per scrivere codice non è un programmatore.
Il mestiere del programmatore informatico è di realizzare applicazioni, sistemi operativi, algoritmi contabili, persino sistemi IA. Ma la maggior parte di queste attività, oltre alla necessità di scrivere codice, ha in comune altre cose interessanti:
- La stragrande maggioranza dei programmi “generici” non ha alcun contenuto fisico, o matematico, di livello non banale. Infatti, tutti, e con qualunque livello di preparazione accademica, possono scrivere programmi “generici” – e a mio avviso fanno benissimo a farlo.
- Al contrario, per le applicazioni scienze dell’atmosfera sono rilevanti cose come l’analisi numerica, l’algebra lineare, la teoria-e-pratica delle equazioni differenziali alle derivate parziali, ed altre cose così. Se per un programmatore informatico la “computer science” può rappresentare il 90% del bagaglio professionale, per una persona che si occupi di modellistica questa parte arriverà si e no al 10%. È puramente strumentale. Arriverei quasi a dire un male necessario – se solo i computer fossero meno stupidi e capissero gli algoritmi formulati in linguaggio naturale, il problema nemmeno esisterebbe.
Quindi, la prossima volta che un amico nerd tenterà di sommergerti con un panegirico a favore di Rust, o di qualche altra novità informatica, potrai rispondere con un’alzata di spalle e dirgli “Ma mica sono una programmatrice, io.” E lasciarlo nel suo brodo a sbollire, o indurlo a cercare qualche altro programmatore con cui attaccare bottone e fare allegramente a cornate (non chiedetemi il perché, ma in quella comunità va spesso a finire così, e non solo tra i maschietti).
Un addendum: quanto a me, l’ho scampata bella. Quando mi sono laureata in matematica i computer esistevano già. Persino quelli personali! Solo che, paragonati anche solo al più scarso dei cellulari di oggi, facevano davvero poco. E per ottenerne qualcosa di utile si doveva, di tanto in tanto, ricorrere all’Assembly, protagonista di horror stories anche più pittoresche di quelle che riguardano il Fortran.
Al liceo, però, ricordo benissimo quando il nostro prof di matematica ci faceva tracciare per punti il grafico delle funzioni che ci aveva dato da studiare: “Sì, sì, derivate, minimi, massimi. Ma come fate a sapere che non avete sbagliato?” (In effetti…) Piccolo dettaglio: provaci, a determinare i valori di una funzione del tipo di “tanh(pi*x/exp(-sin(pi*x/4)))” con una calcolatrice: ti troverai più o meno nel mezzo della scena clou del film “Il diritto di contare”, in cui le signore del Reparto Ingegneria fanno i calcoli con assordanti calcolatrici elettromeccaniche, ai tempi in cui la parola computer designava un mestiere.
Però, le storie dell’orrore che si trovano in rete sono sempre lì, e…
Tutta una questione di spelling?!
E, che dire. Spezzoni di codice come
B = 0.0
IF(X-A) 10, 10, 20
10 B = A – X
20 B = -B
proprio proprio belle, e comprensibili…
Solo che questo non è il Fortran, ma il FORTRAN.
Quello, per intenderci, di quando ero bambina io. Con le righe che cominciavano dopo sei spazi. Le etichette. Le linee di continuazione con un carattere non-spazio nella prima posizione. Gli IF aritmetici. Gli statement DATA, EQUIVALENCE, e robe così.
Poi nel 1990 (in realtà un po’ prima) il linguaggio si è evoluto, ha abbandonato il “formato fisso” a favore del “formato libero” (però, se sei masochista, nulla ti impedisce di usare il formato fisso di una volta, o di piantarti il bisturi nella coscia come il Dottor Frankenstin se per quello).
E questo, solo trentacinque anni fa!
Negli anni successivi il Fortran è andato incontro ad una evoluzione relativamente rapida, che lo ha arricchito dell’estensione per la programmazione a oggetti, e di numerose novità legate per lo più alla programmazione parallela.
Nel frattempo ha anche cambiato nome: da FORTRAN è divenuto Fortran (che qualcuno chiama Modern Fortran).
Solo che molte persone della Vecchia Guardia (ehm, la mia…) non lo ha saputo. In effetti nessuno glie lo ha detto. E chissà, molte di loro ancora ricordano benissimo i tempi in cui per mettere le mani su un calcolatore dovevi essere, minimo minimo, professoressa ordinaria – ed anche in quel caso i Tecnici ti guardavano con un’espressione tra il preoccupato e il sospettoso.
Non poche delle persone che si erano laureate a quei tempi hanno, poi, conservato il disgusto provato da cucciole e cuccioli per tutta la vita.
Proprio mentre sto scrivendo queste righe, in parallelo (o insanità profonda del multitasking, e un accidente a colui che ha detto certe persone esservi più portate d’altre: la verità è che il multitasking nobilita chi non ne fa) sto scrivendo la prossima versione di un sistema eddy covariance in tempo reale, e, guarda un po’, sto usando il Fortran. Non su qualche polveroso mainframe dei tempi andati, ma su un “umile” Raspberry Pi 5 (‘nzomma, umile: surclassa da tutte le parti il Mitico CRAY X-MP del Cineca di Bologna, il supercomputer cui Pochissimi Eletti potevano accedere quando ero studentessa io – per inciso e doverosa completezza d’informazione, io no).
Perché uso il Fortran? Potrei adoperare altri linguaggi (qualcuno lo conosco, Python, R, C/C++, persino un po’ di Rust), ed in alcune aree dello sviluppo del sistema certamente farei più in fretta.
Ma, problema: un “sistema Eddy Covariance” non è un normale registratore di dati (per quello avrei potuto benissimo adoperare un linguaggio “da programmatori generici”). In quanto “sistema Eddy Covariance” deve fare un mare di conti. Non complicatissimi, per carità. Ma, tanti. E da svolgere in fretta, senza ammazzare la macchina, e senza indurla ad un consumo di energia eccessivo (conta anche quello, nel mondo reale).
Dirò di più: in un sistema Eddy Covariance, il 90% del tempo il computer lo trascorre facendo calcoli complicati. E in casi del genere il Fortran è, ad oggi, imbattibile.
Una questione etica
Un moderno “modello” è un modello, appunto: un’approssimazione della realtà.
Come tale, è un “oggetto progettato”, che qualcuno o qualcuna ha concepito in vista di un proprio scopo, e di una agenda (etica, politica, aziendale, Weltanschauungisch, eccetera eccetera). E sì, è anche, spesso, un programma di calcolo.
Di solito, le ragioni della scelta di proprio quelle approssimazioni e non altre è scritta da qualche parte, ed accessibile (in caso negativo, diffidare, diffidare…).
Lavorare con i modelli, quindi, vuole anche non solo scrivere codice, ma leggere quello scritto da altre persone.
Esperienza non sempre necessariamente piacevolissima. Esistono persone, per esempio, che quando scrivono codice non cercano di farsi capire, ma, magari, di far vedere quanto sono geniali a inventare algoritmi strambi, oppure a rendere noto al Mondo tutto quanto gli ha fatto schifo abbassarsi al livello dei comuni mortali etrovarsi costretti a scrivere le loro equazioni in FORTRAN, oppure ancora a mandare al loro capo un messaggio trasversale su quanto sono stressati, od anche… – tutte ragioni, sia chiaro, legittime. E che però, obiettivamente, a noi che ci troviamo a dover leggere e magari correggere o cambiare le cose rendono solo la vita più difficile.
In questo esercizio di comprensione, capita spesso di dover capire perché una cosa che dovrebbe sulla carta comportarsi in un certo modo, invece, fa tutt’altro.
Una programmatrice “generica”, in casi come questo, avvierebbe un processo di refactoring e debug.
Magari noi, che ci troviamo di fronte dei numeri, potessimo limitarci a questo!
Più spesso che no, dovremo comprendere dei “perché” piuttosto profondi.
Per esempio, dopo aver scoperto che il metodo numerico impiegato nel lavoro originale era “numericamente instabile”. Cosa possibilissima, soprattutto nelle fasi iniziali, “prototipali”, dello sviluppo di un nuovo modello. Un metodo numerico è “numericamente instabile” quando gli errori (di arrotondamento e di altra natura – i calcolatori rappresentano i numeri solo con un numero finito e piccolo di cifre dopo la virgola) si amplificano durante i calcoli, al punto che il risultato finale potrebbe non avere alcuna attinenza con il risultato “vero”.
Oppure, prima ancora: le semplificazioni compiute per arrivare alle equazioni del modello sono troppo brutali per il caso in esame, e così il modello, bellissimo, rappresenta una cosa altra rispetto a quella che interessa.
Aspetti come questi, di taglio pochissimo informatico, e moltissimo fisico e matematico, sollevano un problema etico: qual’è la responsabilità che esercitiamo, scegliendo un metodo oppure l’altro? E, scegliendo un modello, ne adottiamo, ne sposiamo anche le scelte fatte a priori da chi lo ha progettato?
Problema, questo, che un informatico generico incontrerà di rado nella sua vita.
Ma che toccano ogni giorno, o quasi, nella vita di una “modellista”.
Di sicuro è, anche, una questione di conoscenza
Fare modellistica è, conseguenza di ciò che ho detto, per il 90% occuparsi di aspetti matematici e fisici.
Solo per il 10% di questioni informatiche.
Per formare un programmatore, una programmatrice, “generici” serve un training legato ad aspetti profondi di Computer Science e linguaggi di programmazione, di regola complessi e “per iniziati”.
Per formae un, una “modellista”, invece, servono cose come:
- Elementi di calcolo numerico e analisi numerica
- Calcolo matriciale e tensoriale
- Equazioni differenziali ordinarie e alle derivate parziali
- Probabilità e statistica
- Meteorologia dinamica
- Meteorologia del Planetary Boundary Layer
- Tecniche osservative e di misura
- …
Insomma: l’è un alter mestée.
C’entra con la programmazione? Massi, anche: con un linguaggio che sia semplice, aiuti a non compiere errori stupidi dalle conseguenze devastanti, facile da imparare. Ad oggi, il Fortran. Poi, se proprio proprio dovesse servire l’aiuto di un programmatore o una programmatrice “generica”, bé, si può senz’altro fare: i programmatori generici abbondano. Sono i e le modellisti/e ad essere rari.
Sarebbe bellissimo, se questa distinzione divenisse cosa assestata nel linguaggio comune: vorrebbe dire che il nostro Paese ha salito qualche gradino di civiltà.
Purtroppo, ad oggi la confusione abbonda, segnalando una consapevolezza sul tema della scientific computing e dei campi affini sostanzialmente uguale a zero.
Ma siamo qui, e dunque, vediamo di cercare noi di cambiare le cose. 😊