Inquadramento generale

Come illustrato nei capitoli precedenti l’obiettivo del software AutoBiD è la gestione dell’intero processo di analisi e progettazione strutturale di un impalcato da ponte in struttura mista acciaio calcestruzzo. Gli elementi oggetto di analisi e verifica sono:

 Soletta collaborante in calcestruzzo armato;

 Orditura principale composta da travi a sezione variabile per conci ma non per sottoconci con forma aperta ad ―I‖;

 Piolatura di connessione tra la struttura in acciaio e quella in CLS;

 Irrigidimenti d’anima verticali e longitudinali;

 Diaframmature e controventature vengono considerate in fase di modellazione come ipotesi progettuale, data la tipologia semplificata della discretizzazione del modello.

Il codice AutoBiD beta1R scritto in linguaggio C#.Net 2.0 è in grado di eseguire le seguenti procedure:

Definizione della geometria del ponte a partire dall’asse stradale supportato; Definizione di un modello spaziale in ambiente F.E. dello stesso ponte; Determinazione delle azioni sulla base di codici nazionali ed internazionali; Verifica degli elementi maggiormente sollecitati appartenenti ad ogni proprietà; Definizione delle principali caratteristiche della struttura da ponte, quali:

Peso complessivo della carpenteria;

Volume del CLS impiegato per la realizzazione della soletta e delle opere di appoggio;

Costo di produzione al metro lineare;

procedura di ricerca dell’ottimo mediante l’impiego di algoritmi evolutivi o genetici dell’intera struttura o di singole parti.

Lo sviluppo di un software complesso come quello oggetto del presente capitolo è stato elaborato in collaborazione con l’ingegner Roberto Zamparo, dottorando presso il D.I.C.A. dell’Università degli studi di Trieste il quale si è dedicato allo sviluppo dei moduli di creazione delle linee d’influenza, analisi dei carichi e definizione delle loro combinazioni, gestione del modello in ambiente Straus7 mediante API e procedure di verifica e determinazione dei coefficienti di utilizzazione. Tali moduli saranno oggetto della propria tesi di dottorato in fase di svolgimento e pertanto all’interno della presente tesi saranno trattati marginalmente per la miglior comprensione del progetto da parte del lettore.

Lo schema procedurale del programma di seguito illustrato (FIG. 37) riassume le principali funzionalità del programma nonché il principale flusso logico esecutivo delle azioni da esso svolte.

Pagina | 58

FIG. 37 Work Flow di AutoBiD beta1R.

In Fig. 38 viene illustrato il macrosistema d’interoperabilità dei moduli dell’applicativo. La logica ricercata è di tipo gerarchico-piramidale (22), ossia il core, centro direzionale del sistema, dialoga con le unità principali alle quali è delegato il compito di ripartire le richieste alle sotto unità responsabili od obiettivo della commessa e viceversa a salire, così facendo si crea un codice schematizzabile come una moltitudine di ambienti ognuno dei quali richiede una chiave d’ingresso (dei parametri) ed esegue una serie di funzioni atte a produrre un risultato recepito dal sistema attraverso l’ambiente sovrastante avvero contenente.

START Way Line definition Deck Line Definition  way line No No Fixed deck line Anchor point definition Yes Yes Girders Line Definition Size Assignment Model definition Load definition Analysis process Design operation Constraints output Objective calculus ^END Segment

Pagina | 59

Fig. 38: Grafico d’insieme del progetto AutoBiD

Il motore di tutti i processi, come precedentemente definito, è definito nel core. Tale unità ha il compito di gestire il flusso di dati tra le principali sotto unità esecutive, le quali rispecchiano tre delle procedure attese da AutoBiD (punti 0, 0, e 0 pag. 2):

 geometrical definition, unità delegata alla creazione del modello geometrico del ponte a partire dalla conoscenza prima della wayline, poi della deck e girders line. Tale unità dipende direttamente dalla definizione di alcune classi di parametri:

o Parametri di progetto definenti la via di corsa supportata:

 Allargamento temporaneo della sede stradale (piazzole di sosta, allargamento del ciglio, ...);

 Variazioni di pendenza trasversale non uniformi riprese della soletta;

o Parametri definenti la geometria globale dell’impalcato:  Numero di conci;

 Lunghezza massima del singolo concio;  Diaframmatura (tipologia e posizionamento);

 Δ_O, ossia lo scostamento orizzontale massimo tra la way line e la deck line;

 Δ_V, ossia lo scostamento verticale massimo tra la way line e la deck line;

o Parametri definenti la forma dell’impalcato:  Tipologia e definizione della sezione;

 Caratteristiche dell’orditura principale all’interno del singolo concio con eventuale definizione di sottoconci;

o Parametri definenti la ripartizione dei carichi:

 Controventatura orizzontale (tipologia e posizionamento);

CORE

Load

definition ^Influence _Lines

Data Library Unit I/O GUI CLI Data Store Geometrical definition WayLine GirdersLine Model definition Node and elements Design Constraint functions Objective functions DeckLine

Pagina | 60

 Diaframmatura (tipologia e posizionamento);

 Caratteristiche di vincolo agli appoggi (concio-concio, impalcato-pila/spalla).

Mentre in uscita la geometrical definition unity (GDU) fornirà una rappresentazione plano-altimetrica di tutti gli elementi richiesti per condurre a termine la progettazione.

 model definition, unità delegata alla traduzione del modello geometrico in modello tipo F.E., ossia in funzione del tipo di discretizzazione scelto tale modulo procede con la caratterizzazione degli elementi necessari a condurre l’analisi scelta. Ad es. il modulo potrà definire il ponte con un’unifilare se la scelta progettuale è di predimensionamento dell’opera o di progettazione di massima della stessa; oppure potrà creare un modello 3D completo nel caso opposto di analisi completa e definitiva; oppure creare dei modelli intermedi a seconda della richiesta da parte del progettista ovvero del core, nella fase attuale di sviluppo il model definition gestisce unicamente l’uni filare.

 design definition, unità delegata alla verifica secondo la normativa di riferimento scelta (disponibile) delle componenti del ponte sulle quali è richiesta tale fase. DDU (Design Definition Unit) necessita durante l’inizializzazione degli oggetti alcuni parametri quali:

o l’etichetta dell’elemento oppure la famiglia di elementi sui quali eseguire tutte le verifiche del caso;

o la richiesta di scrittura completa dei vincoli oppure la scrittura condensata.

Mentre in uscita si avranno i coefficienti di utilizzazione delle verifiche come da richiesta all’interno di un macro oggetto denominato

VerifyObject

Nonché regolare il flusso di dati alla sotto unità di stoccaggio:

 I/O: Input/Output unità delegata al controllo del flusso dei dati in ingresso ed uscita dal programma e allo scambio d’informazioni con le sotto unità su elencate.

Il software è organizzato sotto un’unica soluzione il cui nome è AutoBiD.sln, in tale soluzione sono contenuti diversi progetti ognuno dei quali contenente a sua volta del codice preposto allo scopo dichiarato nel canovaccio del progetto stesso di cui si riporta una breve descrizione in ordine alfabetico:

ABiDDeckLine: Plug-in di AutoBiD impiegato per la costruzione della polilinea individuante l’asse di progetto a partire dall’asse teorico individuato dalla wayline e da una lista di punti notevoli (stazioni);

ABiDFEM: Insieme di classi in cui avviene la gestione del tipo di codice ad elementi finiti attraverso il quale verrà definito il modello, in questa fase del progetto sono impiegati:

31 I nomi degli oggetti o delle classi verranno scritti impiegando un tipo di carattere differente dal resto del testo per una maggior comprensibilità.

Pagina | 61 Straus7 con il quale AutoBiD comunica per mezzo delle API ed il cui

processo di gestione è testato e sarà oggetto dell’ultima parte del presente lavoro;

FEAP_PV con il quale AutoBiD comunica mediante file di I/O testuale ed il cui processo attualmente è in fase di testing;

ABiDForceCalculator: Definizione dei metodi di calcolo delle sollecitazioni sulle travi di riva dell’impalcato in AutoBiD, ossia applicazione del metodo alla Courbon di ripartizione delle sollecitazioni;

ABiDInfluenceLines: Determinazione delle linee d’influenza su un generico asse di calcolo definito come lista di elementi geometrici segmento; ABiDOptim: Gestione dell’ottimizzatore interno direttamente interfacciato con la

libreria ABiDEvoCOM trattata nella prossima parte del presente lavoro;

ABiDSt7API: Definizione delle macro per la creazione e gestione del modello in ambiente Straus7 mediante API;

ABiDTableProcessing: Definizione delle tabelle per la gestione degli elementi finiti;

ABiDVerification: Insieme dei metodi di verifica di tutti gli elementi costituenti l’impalcato;

ABiDWayLib: Plug-in di AutoBiD impiegato per la lettura del file d’ingresso della geometria della strada e definizione della polilinea costituente l’asse teorico del tracciato e della lista dei punti notevoli indicati nel progetto dell’infrastruttura viaria;

AutoBiD: Core del software, ossia centro gestionale dei flussi di dati operanti all’interno di AutoBiD;

AutoBiD.ABiDLib: Raccolta degli strumenti di gestione e definizione dell’oggetto ponte, ossia la libreria principale del progetto la cui struttura sarà trattata nei prossimi paragrafi;

All’interno di ogni progetto sono poi contenute una o più classi (per un totale di 98 file distinti) strutturate in modo da poter essere impiegate in AutoBiD come oggetti o componenti di oggetti, perseguendo così l’obiettivo di creare un software orientato all’oggetto.

Per una maggior comprensibilità dell’intera architettura del software si procede ora alla descrizione degli oggetti più semplici di maggior interesse32, i quali costituiscono i mattoni dell’intera struttura, per poi passare ad analizzare alcune delle componenti strutturate per giungere infine alla descrizione del core nel quale è inizializzata la struttura attraverso il super oggetto

Bridge

32 Verranno tralasciati molti moduli e classi di minor interesse data la mole raggiunta dal progetto, il quale si basa su più di 30000 righe, 21000 delle quali di solo codice.

Pagina | 62