Lo sviluppo delle recenti normative e l’entrata in vigore, ormai da tre anni, delle NTC2008, ha spinto la maggioranza dei progettisti coinvolti nella progettazione strutturale verso un utilizzo dei software di calcolo strutturale sempre più massiccio e sempre più caratterizzato dalla generazione di modelli di calcolo tridimensionali, corredati da molteplici tipologie di calcolo (statica equivalente, dinamica modale, ecc.) e da una fase finale di rielaborazione (post processing) dei risultati molto complessa.

Image credits: kkstudio (Katerina Kamprani)

 

Autore

Bruno Finzi – Ingegnere strutturista
Presidente Commissione Strutture
Ordine Ingegneri  della Provincia di Milano
CeAS – Centro di Analisi Strutturale (www.ceas.it)

 

Introduzione

Le Norme Tecniche per le Costruzioni si pongono come obiettivo di regolamentare l’uso dei software di calcolo attraverso una serie di indicazioni contenute nel Capitolo 10.2. Questo capitolo non rappresenta una innovazione in questo ambito. Già nel lontano 1986 erano state emanate delle raccomandazioni (le CNR 10024) che si ponevano come una sorta di linea guida nei confronti sia degli sviluppatori, sia verso gli utenti di software di calcolo strutturale. Nelle raccomandazioni

contenute nella CNR10024 venivano introdotti due aspetti molto importanti:

1. la necessità da parte dei progettisti utilizzatori di software di eseguire un esame critico dei propri modelli di calcolo;
2. la necessità di eseguire una validazione delle proprie calcolazioni allo scopo di determinare un giudizio motivato di accettabilità dei risultati.

Queste tematiche sono state riprese dalla normativa NTC2008 dove viene confermato che la responsabilità dell’intera progettazione strutturale è del progettista, indipendentemente dal software utilizzato.

Di fronte a questo quadro normativo, è importante analizzare il punto di vista dei progettisti. Gli aspetti inizialmente descritti non rappresentano una novità assoluta per i professionisti. Già in passato, nei casi di strutture molto importanti e di notevole complessità, diversi ingegneri hanno potuto sviluppare competenze di carattere numerico sia sul metodo degli elementi finiti, sia sulle insidie caratterizzate dall’utilizzo di un software di calcolo.

A differenza di quanto avveniva in passato, quando queste attività erano sporadiche ed esperienza di pochi, l’entrata in vigore della normativa NTC2008 ha reso l’attività di modellazione numerica praticamente
sistematica per tutti i progettisti.

L’impatto determinato dalle nuove normative nei confronti dei progettisti si è rivelato, proprio per questo motivo, dirompente. Se facciamo riferimento alla categoria media del libero professionista, essa è costituita in generale da ingegneri con esperienza spesso limitata e con conoscenze nei confronti delle tematiche di calcolo strutturale automatico molto superficiali.

Ci sono numerosi progettisti che hanno avuto difficoltà  ad aggiornarsi e che, di fatto, non conoscono ancora completamente parte delle tecniche di calcolo oggi considerate consolidate e alle quali la normativa fa riferimento (per esempio l’analisi modale).

Questi ingegneri o hanno deciso di non occuparsi più della progettazione strutturale, oppure hanno frequentato corsi e dedicato tempo per cercare di aggiornarsi arrivando a dotarsi di software che dovrebbero consentire di affrontare le nuove tipologie di analisi strutturali.

Ci sono molti ingegneri, invece, che hanno maturato una significativa e durevole esperienza che li pone in grado di valutare con particolare attendibilità ed attenzione le ricadute che certe prescrizioni possono avere sull’effettivo lavoro di progettazione, calcolo e
supervisione nel mondo dell’ingegneria reale.

Questa ampia disomogeneità di preparazione dei progettisti ha ancora una volta un impatto notevole con riferimento, ad esempio, al tema della validazione dei modelli di calcolo. Il progettista deve non solo prestare attenzione e conoscere la normativa in modo da poter usare il software di calcolo in modo corretto, ma anche capire in quale modo il produttore del software, che non essendo un estensore della normativa si pone dalla stessa parte del progettista, ha interpretato e implementato i vari punti della normativa.

Questo aspetto spesso sfugge agli utenti progettisti e, purtroppo, in diversi casi neppure la manualistica a corredo dei software è in grado di fornire adeguate informazioni.

Il produttore di software deve affrontare infatti nel modo più chiaro e trasparente possibile la tematica, delicata e foriera di conseguenze pericolose, relativa alla traduzione in un codice di calcolo delle procedure che all’interno di una norma regolano, ad esempio, le combinazioni di carico, l’input sismico da associare in base al sito sismico in cui la struttura verrà edificata, le eventuali regole di modifica delle azioni di calcolo per imporre la sequenza della crisi nei diversi elementi strutturali (è il caso quest’ultimo delle regole di applicazione per la verifica secondo il metodo di gerarchia delle resistenze).

Altro aspetto molto delicato riguarda la fase di verifica degli elementi strutturali. È infatti in questa fase che, ancora di più, diviene indispensabile affidarsi a strumenti automatici, in quanto gli unici in grado di eseguire la verifica di centinaia, o forse è meglio dire migliaia, di sezioni di elementi strutturali estratte da un modello strutturale, moltiplicandole per tutte le combinazioni di carico richieste dalla normativa.

Rispetto alla validazione della soluzione numerica, si tratta di un ulteriore livello: capire da un lato se i parametri di verifica dati in pasto al verificatore siano quelli corretti, dall’altro quali formule siano esattamente state usate; il software infatti potrebbe non avere considerato alcune formule, altre potrebbero essere state implementate in modo particolare oppure essere attive solo all’interno di certi casi e, molto probabilmente, risulteranno diverse confrontando differenti software che di fatto implementano la stessa norma.

Gli scenari normativi ormai entrati a pieno regime hanno imposto pertanto un’importante evoluzione dal punto di vista della competenza del progettista che deve fare uso dei software di calcolo strutturale.

Accanto alla conoscenza di base di ogni ingegnere, riferita alle tematiche storiche della Scienza e della Tecnica delle Costruzioni, è ormai obbligatorio affiancare nuove nozioni più proprie della Meccanica delle Strutture e del Calcolo Numerico.

La conoscenza deve anche essere di carattere metodologico. Di fronte ad un generico problema strutturale è necessario che il progettista conosca la sequenza delle fasi utili alla soluzione del problema in esame, indipendentemente dal software in uso.

Un altro aspetto che conferma il continuo aggiornamento culturale richiesto all’ingegnere – progettista è quello relativo all’investimento di tempo sempre più importante nello studio approfondito delle normative, non limitandosi all’elenco delle formule e alla ricerca delle diverse prescrizioni, ma invece analizzando le procedure richieste e comparandole anche con le norme da cui la norma italiana deriva (tipicamente gli Eurocodici).

Un altro tipo di competenza richiesta al progettista è quella legata all’interpretazione dei casi test (benchmark) di analisi, ormai quasi sempre forniti dalla manualistica del software, ma spesso scritti nel linguaggio tipico dei solutori agli elementi finiti e quindi corredati da informazioni di carattere computazionale, spesso poco o per niente note alla media dei professionisti che non hanno nozioni di Calcolo Numerico.

Nei confronti di questo materiale, presente nella documentazione di quasi tutti i software di calcolo, il progettista dovrebbe essere in grado di capire gli esempi trattati, di riprodurli ed in alcuni casi diviene anche necessario acquisire la capacità di sviluppare nuovi esempi test su tematiche inizialmente non contemplate ma comunque affrontabili dal software in uso. I nuovi approcci computazionali impongono ai progettisti di sviluppare una competenza trasversale nei confronti delle metodologie di analisi e verifica disponibili nei diversi software usati come termine di confronto. Ma la conoscenza, in questo caso, viene purtroppo spesso erroneamente intesa come limitata al solo carattere operativo (conosco bene un software perché l’ho usato in passato).

Deve invece trattarsi della consapevolezza degli ambiti e dei limiti per i quali è noto che i diversi software possono arrivare in termini di tipologie di analisi, tipologia di elementi finiti ecc..

A fronte di tali complessità è chiaro che, nel caso di modellazioni complesse, di strutture complesse, a fianco della modellazione tridimensionale il progettista dovrà prevedere modellazioni più semplici di preverifica delle capacità del software e di post-verifica, confrontando il risultato del modello generale complesso con calcoli semplificati manuali.

Oltre a questo, ci si può porre come obiettivo un altro livello di validazione, che possiamo definire globale, tramite il quale il progettista può arrivare a capire quanto sia ampio l’intervallo di comportamento utilizzato nei nostri calcoli.

Allo scopo di chiarire il concetto possiamo considerare il caso di una struttura a contatto con il terreno dove i parametri geotecnici possono far variare in un intervallo molto ampio le caratteristiche delle sollecitazioni e la risposta dinamica globale. Nell’ambito di una procedura di validazione, dovremmo ad esempio verificare che, in relazione allo spettro di progetto utilizzato, le variazioni di periodo causate dall’uso di un intervallo di valori delle caratteristiche geotecniche del suolo non modifichino in maniera significativa le accelerazioni spettrali o gli spostamenti.

Validare il calcolo secondo quest’altra modalità significa dichiarare quale sia la nostra fascia di comportamento, rendendo pubblica la cosiddetta “fascia di ignoranza”. Si tratta di imparare a valutare la dimensione dell’intervallo di comportamento; ovvero conoscere (e quindi dichiarare) l’ampiezza della fascia di comportamento prevista dal calcolo.

Un conto è farlo alla luce dell’esperienza, un conto è quantificarlo numericamente. Nonostante una maggiore potenza di calcolo, esisteranno sempre delle variabili che influenzano la qualità del calcolo indipendentemente dalla modalità di risoluzione delle equazioni. Risolto a mano o meccanicamente, i dati di input rimangono sempre affetti da un certo grado di aleatorietà ineliminabile.

È importante non sottovalutare il criterio di fascia di comportamento, in quanto nell’ingegneria civile i dati con poche cifre significative sono la maggioranza. Il criterio di fascia di comportamento è un criterio di qualità progettuale ed esecutiva, in quanto una fascia di comportamento molto ampia è sintomatica di incertezze sui dati alla base del calcolo.

Un’altra tematica importante e delicata, ormai sempre più all’attenzione dei progettisti, è la fase del controllo di un modello di calcolo realizzato da altri utenti, oppure situazioni in cui il modello di un calcolo viene esaminato da un ente o da un professionista esterno incaricato come validatore. Nelle situazioni di controllo esterno, la figura del validatore, oltre al controllo della relazione di calcolo prodotta dal progettista, in molti casi arriverà anche alla rigenerazione del modello di calcolo tramite un altro software che il validatore riterrà essere lo strumento di paragone adeguato.

Se da un lato l’analisi della relazione deve consentire al validatore di ricostruire quanto fatto dal progettista, dall’altro la validazione numerica porterà ad un confronto tra analisi eseguite con software probabilmente diversi e quindi certamente si confronteranno risultati tra loro non uguali.
Purtroppo spesso i confronti vengono eseguiti tra modelli molto diversi perché basati su modellazioni solo apparentemente simili, innescando una fase di confronto “improprio” nella quale, più che il confronto numerico, si instaura una disputa in termini di ruoli all’interno della fase di progettazione (il validatore cerca in generale di imporsi come referente e il progettista ad abdicare il suo ruolo creando un incrocio pericoloso di responsabilità).

La fase di validazione e verifica affidata al progettista presenta un ulteriore aspetto delicato ed interessante. È il caso in cui la modellazione e le fasi successive di controllo passano attraverso “le mani” di diverse persone che a turno si cimentano sullo stesso modello .
In queste condizioni è importante capire in che termini la competenza metodologica sia diffusa all’interno dello stesso gruppo di lavoro.

Negli studi di progettazione, la conoscenza di un certo software di calcolo non è in generale equamente condivisa. Spesso l’utente che meglio conosce i comandi del programma risulta essere il più giovane, meglio orientato all’utilizzo rapido dei software, ma, in molti casi, anche la figura con minore esperienza.
In queste condizioni, il controllo e la validazione richiedono che più persone esaminino lo stesso modello contemporaneamente in modo da integrare i diversi tipi di competenza.
Il rischio è altrimenti quello che da un lato la validazione si traduca in un efficiente utilizzo dei comandi del software, in quanto nel minor tempo possibile si è raggiunto un certo risultato, oppure che si ottenga una maggiore capacità di analisi critica dei risultati non corroborata da una conoscenza dei limiti del software.
Allo stato attuale dello sviluppo della Scienza e della Tecnica delle Costruzioni, ci si trova in una fase intermedia, nella quale le procedure di calcolo automatico rese possibili dal progresso tecnico-scientifico degli ultimi trent’anni consentono di affrontare problemi di notevole complessità e di impossibile soluzione mediante tecniche di tipo tradizionale (operazioni con carta e penna, regolo calcolatore, calcolatrice da tasca), senza tuttavia che siano effettivamente possibili controlli sulle elaborazioni, se non a prezzo di una sostanziale duplicazione del lavoro.
Purtroppo a fronte di mezzi di calcolo sempre più progrediti non si ha un’uguale progressione nei mezzi di controllo.

Dal punto di vista dei progettisti, le prescrizioni del Capitolo 10 NTC 2008, di validare o motivare i risultati (stante il fatto che le formule, le procedure e gli algoritmi, che la norma rende in molti casi imprescindibilmente necessari, sono spesso impossibili da validare, se non mediante la duplicazione del lavoro fatta da terze parti con procedure software differenti), porta spesso ad uno stato di utilizzo “senza controllo” degli strumenti software.

Sembra quindi necessario ed imprescindibile affiancare alle procedure di calcolo più complesse e sostanzialmente destinate ad essere implementate su calcolatore, altre procedure, che possano essere facilmente messe a punto anche usando mezzi di calcolo molto più semplici.
Il progettista (responsabile e conscio del proprio ruolo) si trova sempre pertanto in una situazione decisamente complessa da risolvere. Da un lato auspica un miglioramento ed una semplificazione normativa, dall’altro è ormai consapevole dell’importanza di disporre di strumenti software tramite i quali sia possibile eseguire un adeguato controllo dei modelli realizzati e delle analisi (troppi software si dimostrano essere delle “scatole nere” poco controllabili); infine, inevitabilmente, ha l’esigenza di un costante miglioramento nella produzione dei risultati da parte dei software di calcolo stessi.

Come conseguenza naturale di questa situazione, il progettista dovrebbe essere interessato ad utilizzare, a fianco dei diversi strumenti automatici di calcolo, delle “linee guida” alla corretta modellazione, al controllo e alla validazione dei modelli di calcolo (non alla progettazione) che lo assistano metodologicamente nelle diverse fasi di lavoro.

Le linee guida agirebbero come strumento di ausilio al controllo di ciò che il progettista ha concepito, modellato e calcolato e consentirebbero all’ingegnere di sviluppare la propria capacità, creatività e preparazione. I software, a quel punto, diverrebbero a pieno titolo strumenti per creare e verificare un modello di calcolo, senza mai diventare strumento di progettazione.

Solo attraverso un atteggiamento critico nei confronti dell’uso dei software e quindi dei relativi modelli di calcolo, il progettista può
ambire di esercitare un ruolo primario all’interno della comunità scientifica.

Nei confronti degli estensori della norma, questo atteggiamento rappresenterebbe un sicuro stimolo verso una chiarificazione delle prescrizioni (probabilmente inevitabili anche all’interno di una normativa che si pone come prestazionale); per le software house si rivelerebbe una spinta a produrre strumenti sempre più performanti (tenuto conto dell’inevitabile e positivo aumento delle capacità di calcolo dei computer) da un lato, ma più controllabili e quindi più orientati alla validazione dei modelli di calcolo dall’altro.

Il punto di vista di ASSOBETON

Il grado di preparazione, il livello di esperienza, nonché la possibilità di tenersi costantemente aggiornati fanno sì che il problema dell’affidabilità dei software di calcolo strutturale sia particolarmente sentito da parte dei progettisti.
La situazione è aggravata dalla presenza sul mercato di software “chiusi”, per i quali è molto difficile, se non impossibile, conoscere come le diverse prescrizioni della normativa siano state implementate.

Nel caso specifico delle strutture prefabbricate, occorre sottolineare che sono attualmente disponibili software che contengono formulazioni non sempre appropriate, come ad esempio il calcolo di q o l’ampiezza della zona critica. La corretta soluzione di questi problemi è dunque demandata al progettista che si trova nella situazione di dover al contempo interpretare la normativa vigente e i dati forniti dal software di calcolo.

L’esigenza di disporre di criteri che guidino nell’interpretazione della normativa e dell’implementazione delle analisi strutturali è stata l’idea ispiratrice delle Linee Guida ASSOBETON per la Progettazione Sismica delle Strutture Prefabbricate.

Riferimenti

Articolo estratto da: IMC – Assobeton
Industrie manufatti cementizi – n°21 – del 31.12.2011
Link: http://www.prefabbricazione-web.it/