Normativa ed 'effetto farfalla'

L'attrattore di Lorenz non poteva mancare parlando di farfalle...

Come è noto, fu Lorenz a studiare "l'effetto farfalla" e ad usare questa immagine in una sua storica conferenza nell'ambito della teoria del caos. Ho affrontato il tema di complessità e determinismo già altrove e non voglio tornarvi sopra in questa sede. Mi sono però personalmente imbattuto in una forte dipendenza dei risultati dai dati – quindi nell' “effetto farfalla” - in un tema della normativa che detesto in modo particolare: la verifica delle strutture esistenti impiegando lo spettro elastico.

Perché detesto il metodo proposto o meglio imposto dalla normativa? Perché è inutilmente, a mio avviso, complicato e ingiustificatamente complicato. Dove c'è complicazione c'è “puzza” di farfalla, e ciò è qualcosa che chi progetta algoritmi sa molto bene. Ora, quindi, la farfalla c'è in quel metodo di verifica e vi racconto come ne ho trovata una piuttosto grassoccia e beata di esser lì in tanto ben di dio di IF, di cui tali farfalle sono particolarmente ghiotte.

Prendiamo una struttura analizzata con lo spettro elastico, verifichiamo che il metodo sia ammissibile. Ora, se l'armatura trasversale di un elemento è prossima ad un “punto di biforcazione” tanto che, cambiando il passo delle staffe di una anche piccola quantità, cambi di stato da duttile a fragile o viceversa e il metodo resti ammissibile, ecco che i metodi di verifica da adottare cambiano radicalmente. Se è fragile, si confronteranno i tagli, se è duttile, la capacità di rotazione. Ora la grassoccia farfalla del mio caso portava a coefficienti di sicurezza che variavano di circa dieci volte tra i due metodi, e la cosa era prevedibile, perché nel modello proposto dalla normativa non vi è continuità. E' un modello dannatamente discontinuo.

Quindi, i risultati hanno forte dipendenza dai dati. Nel costruire i casi-prova, si devono cercare i criticismi non la “normalità” dei comportamenti. Coloro che propongono ogni tanto casi-prova su edifici, non sono molto informati sulle metodologie di test. Quindi, è possibile costruire un caso-prova con i dati prossimi ad un punto di biforcazione e, con ciò, una anche lieve approssimazione dovuta a quei fatti inessenziali, ma con i quali si devono sempre fare i conti anche se possono inevitabilmente perturbare i dati iniziali, mi fornirà, in questo caso, una soluzione “obiettivo” del tutto inutilizzabile.

Capisco la posizione di alcuni progettisti: noi dobbiamo osservare la legge (normativa) e non criticarla. Vero, ma la mia grassoccia farfalla svolazza per dire che vi sono delle carenze metodologiche gravi nella formulazione della normativa soprattutto quando la si DEVE esaminare con quella lente d'ingrandimento che è la riduzione ad algoritmo.

Porsi queste domande non è ozioso ma rivela la distanza pericolosamente presente tra normativa e sua traduzione in sistema informatizzabile ed un caso evidente come questo è, ritengo, un elemento che può illuminare il problema anche per chi, a questi problemi, è solitamente poco avvezzo o interessato.

Arch. Roberto Spagnuolo, Amministratore Unico, Softing Srl

Il pelo nell'uovo

Oppure, parafrasando una ben nota parabola, potremmo intitolare questa breve nota: “La trave nell'occhio dell'algoritmo del vicino”, dove “trave” allude alla evangelica parabola e non all'elemento costruttivo.

Immaginiamo un pilastro, una sezione del quale è soggetta ad un momento flettente intorno ad un asse, dovuto ai carichi permanenti trasmessigli da una trave e sollecitata in direzione ortogonale al primo asse, in seguito ad un evento sismico. Siamo senza fallo, in un caso di pressoflessione deviata.

Immaginiamo per semplicità e per non confonderci con i numeri, perché è la qualità del ragionamento che ci interessa e non le quantità, di avere una sezione quadrata armata ai vertici e a metà di ogni lato con barre di eguale diametro (saremmo stati molto più cattivi se avessimo usato solo barre d'angolo) . In questo nostro esempio il momento ultimo secondo gli assi principali è solo del 3% inferiore a quello a 45°. Se immaginiamo la nostra forza deviata agente appunto a 45° e pari al momento ultimo in tale direzione, avremo un coefficiente di sfruttamento pari ad uno.

Ora, le componenti secondo gli assi principali, normalizzate alla forza agente, danno luogo, nel nostro esempio, ad un coefficiente di sfruttamento paria 0.686. La normativa (formula 4.10) impone la somma dei coefficienti di sfruttamento secondo, se si vuole, le due componenti affette da un non meglio precisato coefficiente alfa. La somma, con alfa=1 è 1.33 che è maggiore di uno e quindi un momento deviato accettabile è dichiarato inaccettabile di un buon 33%!

Per chi volesse scoprire quale arcano valore di alfa condurrebbe al risultato esatto, basta ricordarsi un po' di logaritmi e si ottiene alfa = 1.66.

 

Non vogliamo con questo fare una critica ai dettami della normativa, ma far notare la difformità dell'impostazione generale. In fatti fondamentali, come il progetto di un pilastro, si accettano approssimazioni molto grossolane, poi si complicano le cose rendendole poco intuitive in adempimenti minori ove si persegue un'accuratezza - del tutto teorica - inferiore a qualche unità percentuale. Ci vorrebbe più uniformità e più chiarezza di metodo ed è strano come molti, di fronte al dettame oscuro ma codificato, non si facciano domande e chinino la testa,  mentre, invece, sull'osservanza scrupolosa di dettami marginali, si strappino i capelli.
 

Per non parlare poi del fatto che, agendo una forza assiale, il dominio addirittura cambia forma rivoltando completamente la... frittata.

Una domanda sorge spontanea... La normativa è forse una nuova religione per cui l'autore di un algoritmo dice all'altro che ha un travicello nell'occhio, mentre colui che lo dice, nell'occhio ha un bel tronco di castagno?

Arch. Roberto Spagnuolo, Amministratore Unico, Softing Srl

Analisi sintetica dei criteri progettuali di Softing - II Parte

Nòlian All In One

La normativa oggi è "procedurale". Cioè, se ad esempio si impone un coefficiente riduttivo dello spettro di risposta, si assume implicitamente che la struttura sia eseguita con criteri tali da possedere la duttilità richiesta. In pratica, la validità della fase di analisi trova la sua conferma nella fase di progetto, un modo di procedere forse paradossale, senz'altro potenzialmente rischioso.
Non tutti si sono accorti del fatto che non si possano più gestire in modo indipendente le fasi di analisi e di progetto delle membrature, essendo (bene o male) frutto di un processo unico.

Questa asserzione metodologica sarebbe, inoltre, più condivisibile, se la nostra normativa non costringesse ad adempimenti quasi "formali" che poco si conciliano, come si è detto nel post precedente, con i metodi informatici tipici dell'analisi computazionale.

Questo legame stretto tra fasi progettuali ci ha costretto ad una operazione che avevamo voluto sempre evitare, perché in una informatica sana il "divide et impera" è un atteggiamento progettuale tipico. L'operazione è stata quella di unificare in un unico programma tutte le fasi del progetto e cioè di fondere l'analisi con il progetto delle membrature.

Oltre a ciò, ci si è posta l'esigenza di automatizzare al massimo il "processo" progettuale inteso come una serie di fasi logicamente tra loro connesse.

Molti altri programmi per l'ingegneria strutturale hanno adottato un approccio procedurale fin dall'inizio della loro storia, ottenendo tuttavia applicativi "rigidi". Una procedura è, infatti, applicabile solo in un contesto molto ben definito. Per cui, di norma, il mercato offre programmi dedicati al progetto delle sole strutture edili e solo se concepite in modo tipico.

Noi sappiamo bene che, invece, uno studio d'ingegneria non si confronta solo con problemi tipici ma con modifiche in corso d'opera, tali da giustificare, contestazioni, contenziosi e anche opere atipiche, tutti casi in cui un programma "procedurale", dedicato ad una specifica tipologia strutturale, è di scarso aiuto.

Per non incorrere in tali limitazioni, il nostro sistema esperto Quilian sovrappone il suo controllo sulle operazioni eseguite dalle varie componenti logiche solo se e quando lo si desidera. Il percorso "obbligato" in Quilian diventa un "pilota automatico", che può essere inserito o disinserito all'occorrenza.
Questo approccio coniuga l'esigenza di analisi sofisticate e di un uso articolato, con le esigenze di produttività, e porta ad uno dei programmi più sofisticati e flessibili finora realizzati. Un sistema per analisi lineari, dinamiche e non lineari che ha tutte le caratteristiche dei migliori programmi esteri ma che convive strettamente con le funzioni di post processo, che in Italia, per i fatti prima detti, risultano fondamentali.

Con orgoglio e convinzione, possiamo quindi affermare che, Nòlian All In One è un programma unico e assolutamente innovativo nella concezione del modo di affrontare il progetto strutturale automatizzato.

Si può condividere o meno la nostra filosofia, ma essa ha il pregio di essere progettualmente congruente e non frutto di compromessi. Riteniamo che in ingegneria questo sia un preciso dovere.

Arch. Roberto Spagnuolo, Amministratore Unico, Softing Srl
Arch. Amedeo Farello, Responsabile Sviluppo Software, Softing Srl

Analisi sintetica dei criteri progettuali di Softing - I Parte

Perché questa nota

Nella scelta di uno strumento software per il progetto di strutture, più che un elenco di specifiche o la risposta alla consueta domanda "ma lo fa questo?", contano i criteri con cui esso viene sviluppato, perché ci consentono di valutarne più  concretamente la rispondenza alle nostre esigenze professionali.

Perciò, in occasione del rilascio di Nòlian All In One, desideriamo condividere qualche  osservazione sui criteri progettuali che applichiamo nel realizzare il nostro software.

La nostra filosofia

L'analisi e la progettazione di strutture civili su elaboratore, impiegano oggi metodi derivati esclusivamente da ricerche di alto profilo condotte nei settori dell'ingegneria meccanica ed aerospaziale. Alludiamo agli algoritmi per la soluzione rapida di sistemi di equazioni, all'estrazione degli autovalori, alla formulazione a fibre per sofisticate analisi non lineari e, ovviamente, allo stesso metodo degli elementi finiti.

Il nostro ruolo, quale produttori di software, è di rendere tali metodi disponibili al pubblico, dotandoli di una interfaccia utente concepita in modo da agevolarne il più possibile l'uso per il professionista, che non è tenuto a conoscerne in dettaglio le specifiche peculiarità ma vuole concentrare, giustamente, la sua attenzione sugli aspetti progettuali.

Il problema è trovare un giusto compromesso tra l'occultamento di certe complessità non essenziali, ed il rispetto dell'impostazione scientifica dei metodi, senza alterarne le potenzialità o ridurre la qualità dei risultati ottenuti. Non è un compromesso facile da trovare.

Softing ha sempre perseguito il mantenimento dell'integrità originale delle formulazioni rigorose dei metodi. Ciò, mentre aumenta la qualità intrinseca dei suoi prodotti, può farne diminuire l'appetibilità commerciale.

Esiste anche un altro problema: molti adempimenti, richiesti soprattutto dalla recente normativa, non sembrano pensati in modo da armonizzarsi con un approccio "informatizzato" all'ingegneria, che pure è oggi di fatto imprescindibile, bensì sembrano formulati in APERTO CONTRASTO con esso, vanificando spesso gli eccezionali risultati raggiunti da questa disciplina e a volte impedendone l'impiego. Si attua una sorta di "snaturamento" della meccanica computazionale per calarla nello stretto contenitore dell'ingegneria "pratica".

Poiché in Italia la norma ha valore di legge, si verifica uno scontro tra metodi di carattere scientifico, con tutte le loro specifiche peculiarità di impiego, e l'esigenza di una "verità inconfutabile" tipica di un sistema normativo. Si tratta di una contraddizione di base che appare insolubile.

In assenza di un'attività di ricerca ufficiale sull'argomento, che fornisca risposte consolidate e validate dall'esperienza comune, il produttore di software si trova costretto a "mediare", esercitando un'attività che non gli è propria, per colmare vistose lacune.

Nel rispetto dei metodi della meccanica computazionale, che sono gli unici a fornire garanzie di scientificità, Softing ha sempre cercato di evitare, finché possibile, di impiegare soluzioni semplificate o troppo particolari, che qualcuno ha definito efficacemente "fare con il calcolatore i calcoli come si fanno a mano".
La pretesa di automatizzare i metodi semplificati usati per i calcoli "a mano" è infatti molto pericolosa, perché tali semplificazioni sono state pensate per essere applicate con "buon senso", caratteristica di cui l'elaboratore è purtroppo del tutto sprovvisto.

Arch. Roberto Spagnuolo, Amministratore Unico, Softing Srl
Arch. Amedeo Farello, Responsabile Sviluppo Software, Softing Srl

Carichi EDGE in esportazione da INMOD

Con le ultime versioni di Nòlian, non è più necessario inserire delle travi in testa sui gusci per trasferire i carichi da solaio sulle pareti. Infatti, tali carichi vengono trasferiti direttamente sulle pareti mediante i carichi EDGE. Vediamo un esempio. La struttura in figura, modellata con INMOD, contiene una parete verticale tipo guscio su cui grava un solaio e delle tamponature che insistono sulla piastra di fondazione.

Quando si esporta in Nòlian la struttura, ottenendo il modello di calcolo, i carichi dei solai vengono trasferiti alla parete e alla platea mediante carichi EDGE, come evidenziato nelle figure che seguono.

Si riducono così in modo drastico gli elementi non necessari, semplificando e riducendo le dimensioni del modello di calcolo.

Ing. Giuseppe Pascucci, Responsabile Supporto Tecnico, Softing Srl