L’uso corretto dei codici di calcolo

La potenza di calcolo sempre crescente dei personal computer e di conseguenza la nascita e lo sviluppo di software di progettazione sempre più sofisticati e complessi hanno indubbiamente da un lato semplificato la vita degli ingegneri, ma hanno anche introdotto enormi fonti di errore se usati in un modo che non sia critico e consapevole.

Quando i calcoli venivano fatti con programmi che erano in grado di risolvere al massimo telai piani, o comunque solo modelli molto semplici, il progettista doveva analizzare a fondo il progetto per individuare e comprendere quali fossero le vere componenti strutturali e quali fossero invece gli elementi secondari da progettare in un secondo momento. In questo modo il progettista riusciva a creare un modello matematico che non solo consentiva l’analisi degli stati di sollecitazione della struttura, ma ne rifletteva il comportamento statico essenziale.

Il calcolo degli elementi secondari era sempre demandato ad una fase successiva, ma l’analisi preliminare aveva comunque consentito di considerarne e prevederne l’effetto sulla struttura principale, senza però modificarne il comportamento fondamentale. Ad esempio un balcone era generalmente considerato solo come un carico applicato e l’effetto torcente sulla trave, se significativo, si compensava con armature “a bilancia”, altrimenti si trascurava. L’armatura del balcone stesso era uno standard ripetibile che non necessitava di analisi specifiche.

Mentre cresceva la potenza di calcolo crescevano anche le possibilità di modellazione, ma di conseguenza cresceva anche il moltiplicarsi di comportamenti non previsti e capaci a volte, se non correttamente interpretati e gestiti, di portare ad un progetto sbagliato della struttura. Vediamo alcuni aspetti critici nella storia dei programmi di calcolo vissuta da chi li ha visti nascere, ed in alcuni casi le loro conseguenze.

Che bello, la nuova versione del mio software adesso gestisce anche le travi su suolo elastico, non devo più dalle reazioni vincolari calcolare la sigma sul terreno e fare il calcolo di una trave continua, ma posso fare l’interazione suolo-struttura!”. Purtroppo non tengo conto che per colpa dei cedimenti differenziali posso stimare in modo completamente sbagliato i momenti nelle travi in elevazione… non riflettendo che una buona parte del cedimento la struttura lo prende durante la costruzione… e che i carichi accidentali non ci sono mai tutti. Qualcuno ha mai visto un edificio residenziale completamente caricato con 200 kg/mq di accidentale sui solai e con 400 kg/mq su balconi e scale? Ed il coefficiente di sottofondo del terreno? Che grado di certezza ha?

Finalmente ho il modello tridimensionale e mi svincolo dall’individuazione dei telai!”. Ma ho pensato che le travi su suolo elastico sotto i pilastri vengono ovviamente valutate due volte come area di influenza? E che ora mi trovo le torsioni secondarie sulle travi? Sarà bene prenderle in considerazione o no?

Nella nuova versione gli elementi bidimensionali mi permettono di modellare le solette e non ho bisogno di trovare le risultanti di appoggio da applicare sulle travi usando le formule del Belluzzi!“. E la qualità della mesh? Fino a questo momento nessuno aveva mai pensato una situazione simile a quella in cui fosse necessario modellare le aste potendone sapere solo il momento in mezzeria e quindi spezzettandole in più parti. I bidimensionali introducono invece prepotentemente il concetto di elemento FINITO in quello che fino ad ora era solo un sostituto dei vecchi metodi manuali. Inoltre, se la soletta appoggia su travi, chi si preoccupa mai di come e quanto interagiscono fra di loro aste e bidimensionali?

Da oggi ho anche i bidimensionali su suolo elastico!”. A parte le stesse considerazioni sui cedimenti fatte per le travi, ma le “punte” di sollecitazione sotto i pilastri, hanno un senso? La mesh in quelle zone è abbastanza fitta? Il taglio fuori piano riflette davvero gli sforzi di punzonamento? Poi nasce la tentazione di modellare platee nervate, modellazione in cui conciliare corretta rigidezza e correttezza dello stato di sollecitazione è praticamente impossibile.

Il metodo master-slave per la simulazione del piano rigido semplifica molto il calcolo e lo rende più aderente alla realtà!”. Peccato che se in una struttura spingente, tipo una capriata in acciaio, non permetto ai nodi di spostarsi riesco a falsare completamente il comportamento strutturale e sottostimo in modo a volte tragico le sollecitazioni.

Questi sono solo alcuni banali esempi di come l’aumentare della potenza di modellazione da un lato e la contemporanea perdita di competenza e soprattutto di controllo o di ragionamento critico dall’altro possano portare ad errori anche gravi.

Il professionista (pur se competente) per mille motivi tende ad essere sempre più colui che si occupa delle relazioni con i clienti o al massimo dei sopralluoghi in cantiere, mentre il calcolo viene demandato a personale a volte privo di professionalità, con l’idea che “tanto il software fa tutto lui”. La conseguenza è che i codici di calcolo, per rendere la vita facile a chi li usa, tendono a rappresentare la realtà, invece che a stimolare la definizione di un modello matematico, con l’illusoria teoria che più simulo la realtà, più i risultati migliorano.

Si vedono così strutture in legno in cui vengono modellati anche i solai con travetti ed orditura secondaria, strutture in acciaio complete di scale con scialoni, gradini e corrimano e di cui poi viene eseguita l’analisi di stabilità globale, di gronde o balconi modellati con elementi bidimensionali (ma la trave portante, come viene armata?) , di muri di scantinato con la spinta della terra ma meshati con dimensioni enormi, di serbatoi in cui i vincoli al piede impediscono il nascere delle inevitabili trazioni sul fondo, e mille e mille altri esempi in cui graficamente il modello è esattamente identico alla realtà, ma numericamente è completamente sbagliato.

Questo è il grande rischio di oggi nell’uso dei programmi di calcolo, la perdita del controllo sulla simulazione matematica e strutturale di una realtà che se riprodotta in modo pedissequo può modificare completamente i risultati di un software di calcolo per altro perfetto.

Un detto sempre valido dell’informatica è “GIGO” (Garbage In, Garbage Out): se introduci spazzatura in un software, ottieni risultati che sono spazzatura. Purtroppo, se prima la spazzatura poteva essere solo un numero sbagliato, oggi la spazzatura si nasconde spesso sotto una apparenza ingannevole: “A video la struttura è esattamente com’è nella realtà, ho modellato tutto... perché il pushover non gira?