L’aumento della potenza di calcolo e della complessità di analisi permesse dai software moderni permette di considerare modelli numerici sempre più vasti e sofisticati. L’ingegnere strutturista è spinto a questi modelli per ricercare strutture sempre più ottimizzate, avendo a disposizione Norme Tecniche e Codici Internazionali che guidano ad un approccio sempre più prestazionale, e all’analisi accurata di ogni Stato Limite. I calcoli che qualche tempo fa servivano al dimensionamento degli elementi strutturali, oggi sono spesso utilizzabili solo come calcoli di verifica “di larga massima” come li definisce il Capitolo 10.2 delle NTC2008.

Autori

Ing. Luca Ferrari – Ing. Paolo Segala
Commissione Software, Associazione ISI – Ingegneria Sismica Italiana
(www.ingegneriasismicaitaliana.com)

Perché passare a modelli di calcolo sempre più sofisticati?

Va precisato che nel seguito dell’articolo dovremo distinguere tra analisi, ovvero la ricerca di parametri di sollecitazione, tensioni e deformazioni, e dimensionamenti, ovvero le regole che portano al progetto o verifica dei singoli elementi strutturali e delle loro sezioni principali sia in materiale omogeneo (come, ad esempio, i profili in acciaio) che come composti (calcestruzzo armato, acciaio-calcestruzzo, profili composti, rinforzi FRP, etc.).

Le analisi costituiscono la base di un corretto progetto: l’errore di una analisi si ripercuote drasticamente su dimensionamenti errati, anche se formalmente corretti. Le analisi condotte coi moderni software di calcolo, specialmente quelle sismiche e quelle avanzate, richiedono esperienza in nuovi settori: nella modellazione geometrica 3D, nell’abilità di creare correttamente il modello numerico, nella capacità di gestire i numerosi parametri delle analisi lineari (a partire da analisi modali con spettro di risposta) e soprattutto di quelle non lineari (dove almeno la “pushover” è oramai all’ordine del giorno). Nei convegni mondiali di Benchmarking, gruppi di lavoro di esperti accademici, alle prese con lo stesso problema, utilizzando lo stesso software, giungono spesso a risultati diversi senza che nessuno si scandalizzi.

Di fronte a queste nuove potenzialità, l’ingegnere alle prese con la pratica professionale rimane con una preparazione di poco mutata rispetto a quanto fornito dall’università di provenienza, e se i progressi sulle interfacce grafiche gli permettano di creare modelli complessi senza particolari difficoltà rischia tuttavia di creare modelli non più gestibili ed interpretabili.

Citando un recente documento dell’Ordine di Milano, “se i mezzi di calcolo sono molto progrediti, non così i mezzi di controllo”, non stupisce quindi il risultato di una recente statistica di ISI (Ingegneria Sismica Italiana) che ha chiesto ad un campione di 500 strutturisti di buona preparazione quale caratteristica ritiene sia più importante per un software di calcolo. Il 37% ha risposto “la controllabilità dei risultati di analisi e le verifiche conformi alle NTC”, il 32% “il poter affrontare qualsiasi modello strutturale (software polivalente)”, e il 25% “Software certificato, validato, affidabile”. Quasi il 70% degli analisti quindi chiede al software la controllabilità del proprio lavoro cercando di padroneggiarlo in qualsiasi applicazione. Solo un quarto degli intervistati, fortunatamente, chiede al software di risolvergli il dubbio sull’affidabilità del proprio lavoro, cosa che comporta, sempre citando l’Ordine di Milano, una illusione di precisione e di affidabilità che al contrario è si subordinata alla correttezza del software ma soprattutto del suo utilizzo.

L’obiettivo deve dunque essere di controllare i propri modelli di calcolo, una attività che come vedremo coinvolge la preparazione degli ingegneri, la qualità del software e soprattutto la qualità delle attività di modellazione alle quali in ambito internazionale si fa riferimento col termine Modeling & Simulation.

Il controllo dei modelli di calcolo: riferimenti normativi internazionali

La letteratura scientifica ha sempre enfatizzato il rigore che dovrebbe permeare tutta l’attività di analisi numerica: da sempre molti autori si sono cimentati nel descriverne le problematiche. Tuttavia è dagli anni ’90 che la questione ha assunto un interesse per il Normatore, quando la prassi di simulazione numerica ha avuto a disposizione strumenti complessi come quelli della Fluidodinamica Computazionale. In generale il mondo dell’ingegneria meccanica è stato precursore nel creare strumenti e metodi di controllo e validazione. Il NAFEMS, una istituzione in questo campo, ha pubblicato le sue prime Linee Guida alla Pratica degli Elementi Finiti nel 1992, mentre nel 2007 si è concluso un lungo lavoro di ASME, iniziato con la tragedia dello Shuttle Colombia (causata da un errore di calcolo) su spinta della NASA, creando le proprie Linee Guida alla Verifica e Validazione nella meccanica computazionale, e la stessa NASA, nel 2008, ha emanato la propria Guidance sull’argomento. Sul fronte del nucleare, va citato lo Standard IAEA sull’analisi sismica delle centrali nucleari, del 2003. In ambito nazionale, in anticipo, va detto, rispetto agli Eurocodici, il tema è stato trattato al Capitolo 10.2 delle NTC2008, con una evidente continuità rispetto alle CNR 10024 del lontano 1986, bisognose di una doverosa revisione, ma che vengono riprese in più punti dalle NTC.

La proposta: Linee Guida come protocollo volontario di buone pratiche per la validazione dei modelli di calcolo

E’ chiaro che un argomento che ha generato tanta letteratura e norme a livello internazionale non può trovare sufficiente spazio in un paragrafo di normativa ed è ravvisabile la necessità che si affronti la tematica in analogia a quanto fatto con le CNR10024 del 1986, mediante delle Linee Guida, ovvero con un approccio volontario e suggerimenti di buon senso che non precludono all’iniziativa del singolo professionista che nel calcolo numerico esprime la qualità e il valore del proprio operato e ha sviluppato una vera e propria “arte” nel controllo dei modelli di calcolo che applica a tutela delle proprie responsabilità. I paragrafi che seguono riprendono proprio i concetti e le metodologie proposte da Enti di comprovata affidabilità in ambito internazionale.

Modeling & Simulation: il concetto base dell’attività di calcolo

Le linee guida V&V10 sono state redatte daI Comitato V&V10 di ASME. Il V&V10 è un gruppo di lavoro composto, come nella tradizione anglosassone, da molti esperti praticanti la professione, alcuni produttori di software e pochi consulenti accademici. Col nome di Modeling & Simulation (M&S) vengono descritte le operazioni dell’analista di strutture che si appresta ad eseguire un calcolo. V&V10 chiede all’analista di dichiarare, descrivere e giustificare le attività di M&S scomponendole in: elaborazione di un Modello Concettuale, scelta e utilizzo di un Modello Matematico, utilizzo di un Algoritmo Numerico attraverso un Codice di Calcolo, input di parametri fisici nel Codice di Calcolo, scelta di parametri di discretizzazione del modello. Queste attività conducono l’analista ad ottenere un Modello Computazionale. Si riporta in figura 1 il tipico Flow Chart concettuale del M&S e in Tabella 1 un esempio.

Fig. 1: Modeling & Simulation (ASME V&V10)

Tabella 1

Per affrontare correttamente una attività di M&S, non è sufficiente disporre di un software certificato, e come vedremo successivamente è illusorio sperare di certificare un software composto da milioni di righe di codice. Il problema è che qualsiasi attività di M&S è molto più articolata del mero utilizzo di un software.

Il disastro del Columbia fu, in questo senso una lezione per NASA. Lo Shuttle subì un impatto con un piccolo corpo, in orbita, il quale danneggiò il rivestimento termico della navicella spaziale. Tale impatto fu immediatamente simulato con un software ne fu stabilita la non gravità ai fini del rientro. Il veicolo, raggiunta l’atmosfera terrestre, esplose a causa del reale danno al rivestimento. La Commissione di Indagine scoprì che il software utilizzato era stato scritto per valutare impatti di meteoriti sul suolo lunare (applicazione errata, cioè errato Modello Concettuale), utilizzato da un Junior Engineer (che introduce il tema della preparazione dell’utente), con un probabile errore nelle unità di misura introdotte (errati Parametri Fisici nel modello numerico), al termine del quale i risultati della Simulazione segnalavano un leggero superamento dello Stato Limite ricercato. Il Senior Engineer, possiamo immaginare le pressioni sulla sua decisione, ritenne di autorizzare comunque il rientro del veicolo. Non crediamo sia azzardato pensare che analoghi problemi sono affrontati quotidianamente nei calcoli di ingegneria civile.

V&V Validation & Verification: la procedura per la verifica dei modelli di calcolo

Una volta chiariti e documentati i passaggi fondamentali di una attività di Modellazione e Simulazione numerica, ASME evidenzia i metodi per identificare con ragionevole certezza la correttezza di un Modello. I metodi sono quelli di Validazione, per assicurare l’affidabilità, e Verifica, per assicurare l’accuratezza dell’analisi numerica di una struttura. ASME utilizza le seguenti definizioni:

• Validazione (Validation): la procedura per quantificare il grado di accurata rappresentazione della realtà fisica, negli ambiti di interesse, da parte del modello
• Verifica (Verification): l’insieme di attività che determinano che un modello computazionale rappresenti accuratamente gli aspetti di modellazione matematica e la soluzione matematica da essa prodotta. Le attività di Verifica e Validazione permettono di arrivare a giustificare la correttezza di un Modello di Calcolo, considerando che, citando lo statistico George Box, “Qualsiasi modello numerico è errato, tuttavia alcuni di essi rimangono ancora utili”. Per essere più specifici, William Oberkampf (al Transport Task Force Meeting, NNSA, 2004), sottolineava:

Verifica: risponde alla domanda “Ho fatto il modello giustamente (correttamente)? Ha a che fare con la Matematica
Validazione: risponde alla domanda “Ho fatto il giusto modello (per il fenomeno fisico allo studio)?” Ha a che fare con la Fisica

Per rendere complete le attività sopra descritte, è necessario suddividere la Verifica in due parti ulteriori:

• i. Verifica del Codice (Code Verification): stabilire un livello di confidenza, attraverso tests comprovati, affinchè il modello matematico e l’algoritmo risolutivo funzionino correttamente;
• ii. Verifica delle Calcolazioni (Calculation Verification): stabilire un livello di confidenza, attraverso tests comprovati, che la “soluzione discretizzata” del modello matematico sia accurata.

Cercando di specificare anche queste due definizioni, citando P. Roache, a margine del 2008 Lisbon Workshop su “CFD Uncertainty Analysis”, si può dire che:

• i. Verifica del Codice (Code Verification): dimostrare che il codice è corretto; è in grado di fornire una corretta soluzione matematica delle equazioni che governano il continuo al limD®0; il grado di convergenza è verificato almeno per problemi ben posti;
• ii. Verifica delle Calcolazioni (Calculation Verification): riguarda l’accuratezza della soluzione; gli errori di discretizzazione (mesh) e il peso delle incertezze sui parametri dell’analisi sono stimati, nei casi più complessi, senza avere la conoscenza della soluzione.

ASME riporta tutti questi concetti in Fig.2

Fig. 2: Validation & Verification (ASME V&V10)

Nelle definizioni date alle due Verifiche e alla Validazione ciascun ingegnere analista potrà riconoscere alcune delle attività che esegue spesso nel validare il proprio modello di calcolo. La Validazione è forse l’attività meno svolta, non capitando spesso nella fortunata situazione di disporre di test sperimentali che permettano di controllare “la fisica” del nostro modello di calcolo (dobbiamo spesso fidarci e rispettare di buone pratiche apprese all’università, o ai Corsi post laurea), mentre demandiamo (erroneamente) la verifica del codice al produttore software e effettuiamo comunemente una verifica dei calcoli (con formule semplificate, con controlli di sensitività della mesh, con test sulle convergenze, con comparazioni con altri software).

In ogni caso è chiaro che ogni “caso prova”, o benchmark, è da ritenersi valido per un determinato Modello Concettuale e Matematico, per un determinato set di Parametri Fisici e per alcuni scelti Parametri di Discretizzazione. Parlare di “certificazione” di un software, perseguita con un numero limitato di benchmarks, nell’ambito della complessità di un processo di Modeling & Simulation alla luce delle attività di Validazione e Verifica, significa illudere l’utilizzatore che le analisi condotte con tale software siano altrettanto certificate, quando invece, al massimo una parte del Code Verification è stata svolta. Ed è chiaro che ASME, IAEA, NASA, NAFEMS si guardano bene dal trattare il tema della certificazione del software e affrontano invece la validazione del processo di Modeling & Simulation.

Il ruolo del produttore di software

Alla luce del processo di V&V, il ruolo dello sviluppatore di software dev’essere quello di controllare “la matematica”, la robustezza degli algoritmi (intesa come la stabilità di convergenza e la convergenza alla soluzione al lim Dp 0, almeno per problemi ben posti), e minimizzare la probabilità di “code bugs”.

Nel minimizzare la probabilità di bugs, il Produttore deve implementare un Sistema di Qualità, all’interno del quale deve avere implementato valide procedure di gestione degli errori, quando essi vengono scoperti, specialmente quando sono identificati dagli utenti. Inoltre il controllo sui bug e sulla “matematica” implementata dal codice deve essere effettuato su un numero statisticamente rilevante di “regression test” (sono decine di migliaia, nei software più qualificati), mentre i “casi prova” o benchmarks rappresentano solo la punta dell’iceberg dell’intero processo di “Code Verification”, e sono utili piuttosto all’utilizzatore, come spesso sottolineato da NAFEMS. Tra i benchmarks forniti dal produttore del software si possono identificare i “Code Verification”, quando comparano i risultati con formulazioni analitiche, mentre sconfinano nel “Model Verification” quando presentano comparazioni con altri software. Quando i benchmarks riproducono test reali, hanno invece a che vedere con il processo di “Validation”.

Il ruolo dell’analista progettista: la preparazione

Nel valutare l’affidabilità delle analisi numeriche, un parametro deve essere la preparazione dell’analista progettista. Il livello di esperienza nell’esecuzione di analisi numeriche è fondamentale per l’analista. Questo fatto viene estesamente sottolineato nei testi di NAFEMS. I benchmarks codificati da NAFEMS costituiscono il primo step della formazione dell’analista: riprodurre dei benchmarks per la prima volta o su un software di nuovo utilizzo non è una attività semplice, porta a inaspettate sorprese ed è ricca di lezioni da trarre. Riproducendo i “casi prova”, l’utilizzatore del software svolge una attività di apprendimento e di controllo del codice, egli aumenta il grado di confidenza nell’uso del software e la sua preparazione nell’affrontare specifiche analisi. Nelle sue Linee Guida, NAFEMS richiede che nella relazione di calcolo sia attestato il livello di preparazione degli analisti, specificando i curricula, i Corsi, le analisi svolte in precedenza attinenti all’analisi in questione, nonché il grado di confidenza col software utilizzato.

Regole di validazione dei modelli di calcolo

La lettura e la comprensione delle Linee Guida e Buone Pratiche già citate e facilmente reperibili sulla Rete, quali NAFEMS, NASA, ASME, FIB, IAEA, oltre alla consultazione di qualche buon libro sul tema della modellazione, consentono di stilare una lista sintetica delle attività da svolgere per una buona esecuzione delle analisi e di una loro validazione. Si rimanda ad altri testi per una trattazione più estesa.

a) Chiara definizione del flusso di M&S: indicando in premessa gli obiettivi che l’analisi si prefigge, gli aspetti del Modello Concettuale considerati e gli aspetti della realtà che si sono ritenuti non influenti, la motivazione della matematica scelta a sostegno della simulazione ed i limiti di applicabilità, gli algoritmi utilizzati ed il codice che li implementa con i relativi limiti di applicabilità. La giustificazione dei parametri fisici utilizzati e dei parametri di discretizzazione numerica (mesh, intervalli temporali, step di iterazione, parametri di convergenza) con una analisi di sensitività sugli stessi. Il modello Computazionale così ottenuto sarà oggetto di una trattazione estesa sull’interpretazione dei risultati.

b) Controllo del Modello Computazionale: sono possibili una serie di controlli sequenziali, o check list, sulla congruenza dei dati di input e di output. E’ consigliabile organizzare questi controlli in liste per una loro esecuzione sistematica. Una vasta letteratura elenca controlli possibili.

c) Verifica del Codice di Calcolo usato: come il Produttore, alcuni ingegneri hanno l’abitudine di conservare alcuni modelli che eseguono su ogni nuova release del software al fine di controllare i risultati. Possono essere utilizzati i “casi prova” forniti dal produttore o casi sviluppati in proprio, frutto delle passate esperienze. In ogni caso una nuova release del software dovrebbe essere testata prima di sovrascrivere la release precedente. Una release precedente dovrebbe essere mantenuta quando si necessita di esaminare i risultati di modelli molto complessi con tempi di run dell’analisi molto lunghi: i risultati infatti normalmente non saranno leggibili sulle nuove release e dovranno essere rieseguiti.

d) Verifica dei Calcoli: nel caso si possano individuare calcoli di massima ingegneristicamente significativi (semplici equilibri, strutture equivalenti, etc.) l’ingegnere è in possesso di una prova di correttezza quasi definitiva, sufficiente a validare il modello di calcolo e il software almeno in quella determinata applicazione. Nei modelli (e per gli Stati Limite) più complessi, sempre più spesso, questo non è possibile e la verifica dei calcoli è intesa come un indizio, che assieme alla Verifica del Codice, al controllo del Modello Computazionale e talvolta alla Validazione, porta ad una ragionevole prova. La Verifica dei Calcoli affronta in questo caso il lavoro sulle analisi di sensitività dei parametri di input, sulla discretizzazione del modello, al fine di identificare un asintoto di convergenza verso una soluzione stabile. Sono possibili confronti con altri software, avendo presente che ottenere il medesimo risultato non garantisce dall’aver scelto il corretto Modello Computazionale, ma solo che i due software risolvono la “matematica” allo stesso modo.

e) Validazione: è l’attività che permette, mediante test reali, di controllare la correttezza del proprio modello computazionale. Non è in discussione il testare un modello uguale a quello che si deve simulare, il che sarebbe assurdo, ma un test semplificato (una trave semplicemente appoggiata), o parti di struttura (una cerniera plastica, un giunto), che si ritengono significative per validare le assunzioni decise nell’attività di M&S. La significatività dei test è uno degli argomenti più discussi nella comunità di chi si occupa di V&V, tuttavia si è concordi nel dire che non si tratta di calibrare i Modelli Computazionali (nella Calibrazione si modulano tutti i parametri dell’analisi al fine di ottenere lo stesso risultato del test), nella Validazione i parametri sono noti, in discussione è il processo che porta ad ottenere un Modello Computazionale che riproduca fedelmente il test.

Bibliografia

• [1] NAFEMS (National Agency for the Finite Element Methods and Standards): NAFEMS Guidelines to Finite Element Practice. Glasgow, 1992. ISBN 0903640 16 3
• [2] NAFEMS (National Agency for the Finite Element Methods and Standards): NAFEMS Quality Assurance Procedures for Engineering Analysis. Glasgow, 1999. (Disponibile su richiesta a NAFEMS)
• [3] IAEA SAFETY STANDARD SERIES. NS-G-1.6 Seismic Design and Qualification for Nuclear Power Plants. Vienna, 2003
• [4] ASME (American Society of Mechanical Engineers) V&V10, Comitee. Guide for Verification and Validation in Computational Solid Mechanics. 2007
• [5] NASA Technical Standard, STD 7009. Standard for models and simulations. 2008
• [6] P. Rugarli: Analisi modale ragionata. EPC Libri, Roma 2005. ISBN 88-8184-382-X
• [7] M. Fardis: Seismic design, assesment and retrofitting of concrete buildings. Springer Media B.V., 2009. ISBN 978-1-4020-9841-3
• [8] G.A.Rombach: Finite element design of concrete structures. Thomas Telford, London 2004. ISBN 0 7277 3274 9
• [9] Perretti, Ghersi, Sattamino, Brenna: La validazione del calcolo strutturale eseguito con computer. Maggioli Editore, 2007. ISBN 9 788838736728