La bomba

Come ebbi occasione di raccontare in un numero di FloatingPoint ormai introvabile, sono giunto all'informatica tramite il più nobile dei sentieri. Non per isolarmi in un mondo virtuale di regole rassicuranti, né per uscire dal vicolo cieco di una professione mal digerita, ma vi fui portato dalla madre nobile di ogni conoscenza: la meccanica (intendo quella sporca di grasso, non quella degli ingegneri). L'uomo infatti è faber e non digitans.

Siamo alla fine degli anni sessanta in piena, non condivisa e tutt'ora incompresa, contestazione. Avevo appena finito di costruire un telescopio riflettore newtoniano equatoriale di 36 cm di diametro, 0.36 metri si direbbe oggi, ottica Marcon, completamente elettro-comandato. Pesava 7000 Newton, si direbbe oggi. Posizionarlo non era difficile in quanto la posizione (ascensione retta e declinazione) erano riportati su due quadranti che indicavano le rotazioni rilevate da due “Selsyn”.

Avevo trovato anche un orologio da sottomarino che aveva un quadrante con 24 ore il quale, un poco modificato per ritardare di 3 minuti e rotti, segnava l'ora siderale. Però il mio desiderio era di poter rilevare l'immagine con un sensore e riportarla al calduccio su uno schermo. Infatti la specola pionieristicamente realizzata in resina e fibra di vetro era gelida. Gli amici sostenevano che avessi fatto tutto quell'ambaradam invece di fare la collezione di farfalle. Ma solo una pinguina sarebbe venuta a vedere quelle gelide farfalle notturne. L'operazione delle immagini al calduccio del caminetto non mi riuscì per i costi elevatissimi. Allora i sensori più sensibili dovevano essere raffreddati ad azoto liquido. Però l'idea di poter pilotare il telescopio per via elettronica mi affascinava e mi avvicinai così al mondo degli elaboratori elettronici come sistema APPLICATIVO e non virtuale ed onanistico. Costruii un addizionatore BCD (binary coded decimal) a transistor. Volendo realizzare un calcolatore “parallelo” (non nel significato di oggi) il mio addizionatore richiedeva un circuito per ogni cifra decimale. Ne realizzai uno solo. Sostanzialmente eseguiva 7 + 5 = 2 e si accendeva una lampadina rigorosamente dell'albero di Natale per indicare il riporto. Non ce l'avrei fatta mai ad avere almeno 8 cifre. Vennero fuori proprio in quegli anni i circuiti integrati che in un solo chip avevano 4 porte 'and' oppure 'or' o 'nor'. Per l'addizionatore servivano 8 integrati che allora costavano circa 1000 lire l'uno. Mi impiegai come correttore di bozze alla Guida Monaci. Lo stipendio andava tutto in chip, pellicole per serigrafare i circuiti stampati e via dicendo. Avevo investito quasi un anno di lavoro e di stipendi che uscì il primo microchip che integrava l'unità logica in un solo componente. Mi avvilii un po'. Costava meno del mio anno di lavoro e funzionava decisamente meglio. Però, nel frattempo, avevo studiato analisi numerica e mi ero appassionato. Non so perché mi affascinasse tanto, ma trasformare il calcolo analitico così pieno di astuzie, limitazioni e trucchetti in un metodo numerico mi affascinava. Mi dava un'idea di potenza, eterna aspirazione maschile. Per questo oggi sostengo a ragione e con quarantennale esperienza che la meccanica computazionale è una branca dell'informatica e non della meccanica. Se ci si scontra con gli errori di troncamento e di arrotondamento di una aritmetica finita a pochi bit, come avveniva soprattutto agli esordi, poi, se si fa un programma che tratti numeri, ci si va con i piedi di piombo e non semplicemente trascrivendo formule buone per il calcolo analitico o manuale.

Lunghissima premessa concessa al mio ego per dire che, invocato l'aiuto di san Cassiano, protettore dei dattilografi ed, ahimè, degli informatici, di san Guglielmo, patrono degli ingegneri, di san Benedetto da Norcia, patrono degli architetti, di sant' Alberto Magno, protettore degli scienziati e quindi dei matematici, ho messo a punto un elemento finito per l'analisi delle murature che, santa Barbara permettendo, mi pare una “bomba”.

L'ho realizzato nei ritagli di tempo per pura passione non ritenendo di poterne ricavare alcun beneficio materiale se non gloria imperitura e soprattutto personale soddisfazione.

Poiché non amo chi si prende troppo sul serio, ve lo racconterò con la passionalità che si può avere per i motori a scoppio (atri direbbero combustione interna) e non con la fiera albagia dei simboli paranoici della teoria dei tensori: ijklmn, che pure ovviamente inzuppo nel cappuccino ogni mattina.

Eccoci...

La muratura non resiste a trazione. Gli elementi no-tension hanno il brutto viziaccio di essere dipendenti dalla fittezza della mesh. Quindi il mio (nostro) elemento impiega un metodo secondo il quale si ha una fessurazione distribuita, avvenuta la quale, gli sforzi si sviluppano nel sistema della fessurazione.

Ed una...

La muratura in compressione ha un comportamento elasto-plastico. Non basta che l'elemento sia no-tension. Prendiamo il criterio plastico di Druker-Prager, modifichiamolo alla bisogna, implementiamo un efficiente algoritmo di ritorno e complichiamoci la via facendolo convivere con il regime fessurato.

E due...

La muratura ha il viziaccio di avere un comportamento non isotropo ma anisotropo. Brutta bestia davvero l'anisotropia. Bene implementiamo il criterio di Druker-Pragher per materiale anisotropo.

E tre...

Basta? Non ci basta. Un simpatico signore, un certo Eshelby, si inventa un tensore (questa volta non posso evitare il termine) per omogeneizzare le caratteristiche di un aggregato di elementi ellissoidali. Lo si può modificare per la muratura. A che serve? Per avere una più rigorosa valutazione delle caratteristiche meccaniche della muratura partendo dalle caratteristiche geometriche e meccaniche dei componenti (mattoni e ricorsi di malta) che sono più facilmente valutabili.

E quattro...

Basta? No. Ho dimenticato di dire che il regime di cui sto parlando è di sforzo piano. Ma se immergiamo una membrana in uno spazio tridimensionale oltre a trascurare la rigidezza fuori piano (cosa che per la muratura è lecita, anzi salutare) avremmo la grande seccatura di dover vincolare i gradi di libertà privi di rigidezza. Quindi accoppiamo un regime flessionale a quello membranale.

E cinque...

Ma non basta. Non è salutare che le pareti in muratura, se si connettono formando uno spigolo, siano connesse con la possibilità di trasmettere sforzi flessionali, cosa che comunemente avverrebbe condividendo gli stessi nodi di spigolo, quindi diamo la possibilità di svincolare i gradi di libertà di bordo.

E sei...

Ma non ci accontentiamo. Il nostro materiale no-tension, elasto-plastico, anisotropo a regime di sforzo piano, lo infiliamo ANCHE in un guscio “degenere” a strati. Con questo abbiamo fatto sette che è un bel numero, anche apocalittico.

Con questa meraviglia che ci facciamo? Alcuni di voi ci analizzerebbero elementi murari complessi, altri ci analizzerebbero una villetta monopiano con la fantasmagorica e panaceutica “pushover”, magari lamentando una certa lentezza, una non convergenza, asserendo che altri sono più bravi. Quindi l'elemento me lo tengo per me.... ma si sappia che ce l'ho... 

Arch. Roberto Spagnuolo, Amministratore Unico, Softing Srl

Analisi d'impatto della regolamentazione: chi l'ha vista?

Credo di essere il primo a chiedersi se è stata fatta un'analisi d'impatto relativamente alle nuove norme sulle costruzioni. Nel 1999, se non erro, si è deciso di fare tale analisi prima di varare una nuova legge. Mi sono chiesto quindi se si sono valutati gli effetti, che oggi si rivelano catastrofici, di varare le nuove norme tecniche in modo così scoordinato, senza linee guida per il genio civile, senza un glossario per non confondersi con la terminologia, senza degli schemi di relazioni, con tanti ripensamenti, etc.

Fattami questa domanda, che credo ogni persona di buon senso si farebbe, ho approfondito l'AIR, cioè la suddetta Analisi di Impatto della Regolamentazione. Non credo questa sia stata fatta, per le norme tecniche. Male, malissimo, soprattutto da parte di tecnici che dovrebbero essere informati sulla applicabilità di una norma. L'articolo migliore su internet sull'AIR l'ho trovato a questo indirizzo:

http://notizie.radicali.it/articolo/2011-02-08/intervento/l-analisi-d-impatto-della-regolazione-e-la-formazione-delle-leggi-ita

Naturalmente gli amanti dei luoghi comuni possono asserire che questa normativa era necessaria per salvare “vite umane” e con quest'ultima espressione ottengono l'impatto emotivo voluto per cui se uno ha dubbi diventa praticamente un assassino.

Ora chiunque sia nel settore sa che i rapporti con il genio civile sono diventati molto più difficili, che gli adempimenti richiesti sono circa quintuplicati, che l'aspetto burocratico prevale su quello dei contenuti, che è tutto da verificare che l'uso di complessi modelli matematici aumenti la sicurezza reale e che l'esasperazione del teorizzare l'ingegneria non distrugga la capacità progettuale. E sa anche un'altra cosa, che il terremoto di San Giuliano ha violato lui la norma perché lì non ci doveva essere e quindi il crollo è stato in gran parte a norma di legge, che il terremoto dell'Aquila ha messo in luce esecuzioni approssimative e concezioni progettuali infelici più che deficienze di “calcolo”. Nulla che un'equazione differenziale possa evitare.

Naturalmente l'onere di questa smagliatura è ricaduta sulle software house che in effetti sono le uniche che possono aiutare il progettista. Ma queste come possono operare? La normativa è piena di carenze gravi sotto il profilo della completezza ed inequivocità per poter essere tradotta in algoritmi. Basti pensare che ragiona quasi sempre per telai piani e mai per telai spaziali con elementi non ortogonali: in questo caso non dà mai indicazioni. Poi prescrive in certi casi dei metodi che una normativa non dovrebbe prescrivere per non limitare le possibilità di soluzioni più avanzate. Sulla muratura, ad esempio, perché non si hanno prescrizioni alternative che consentano modellazioni con elementi piani? Ci sono voluti circa venti anni perché nel progetto edile e civile entrassero le analisi ad elementi finiti ed ora con un colpo solo si torna agli anni '80? Perché una parete portante non la posso più analizzare con elementi finiti piani in quanto il modello di verifica imposto dalla normativa è sempre quello della trave inflessa? E' possibile che nessuno capisca che un modello matematico basato su formulazioni “forti” sia più affidabile di mille prescrizioni parcellizzate, discontinue, di difficile interpretazione?

L'AIST è un'ottima iniziativa che dobbiamo ad Adriano Castagnone ed a lui e agli altri soci dobbiamo la presenza dell'AIST ad alcuni tavoli ministeriali, ma la questione è che se il problema non lo si capisce non si possono certo trovare soluzioni. E vi garantisco che non si capisce il problema dello “anello debole” (come lo chiamo io) costituito dal software che collega requisiti progettuali e concezione strutturale con il cantiere, né si capisce quanto sia grave che sia debole. Se fa orrore che le software house, come fornitrici di servizi, non possano (come ad esempio i produttori di calcestruzzo) avere un “Osservatorio” presso il ministero delle infrastrutture, che chiamassero un manipolo di informatici universitari!

Un nostro utente mi fa osservare, giustamente, che oggi il processo del progetto ingegneristico si è “globalizzato” intendendo con questo che è divenuto un discorso aperto a cui tutti devono partecipare e devono poter partecipare. Ma chi ha visto gli ordini professionali tutelare gli iscritti da richieste confuse? Chi ha visto le università partecipare rendendo magari disponibili dei benchmark o degli algoritmi? Chi ha visto i progettisti prendere posizioni forti verso i maggiori oneri che gli sono stati accollati? Chi ha visto finanziamenti per lo sviluppo del software?

Facile “globalizzare” gli onori, sarebbe opportuno invece globalizzare gli oneri e che ognuno facesse seriamene la sua parte. L'impatto della regolamentazione non può essere totalmente assorbito da chi fa software e, quindi, a conferma di quanto detto in apertura: sotto il profilo dell'impatto economico questa normativa sta causando più perdite che non vantaggi.

L'immagine è stata presa dal sito: www.umsadifesa.it

Arch. Roberto Spagnuolo, Amministratore Unico, Softing Srl

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