Lo sviluppo del software di calcolo: da dove veniamo e dove andiamo?

Quando si vuole intraprendere un discorso appropriato sullo sviluppo dei software di calcolo strutturale bisogna conoscere in profondità il passato e, soltanto in una fase successiva, cercare di capire le future strade percorribili. Il passato è rinchiuso in una “ricetta” di successo che è stata capace di creare un mix inconfondibile tra analisi numerica (facente parte della matematica applicata), metodo agli elementi finiti (che niente altro è se non una tecnica numerica) e abilità di grandi personalità dell’ingegneria-matematica (o della matematica applicata all’ingegneria!) quali Bathe, Wilson, Zienkiewicz, Iron, Taylor e tanti altri. In una prima fase il metodo fem (acronimo ormai di larga diffusione in ambiente tecnico) è stato capace di riportare la realtà fisica, che fosse un edificio civile o un pezzo meccanico, ad una schematizzazione discreta: prima con elementi monodimensionali (i ben noti beam) a cui si sono presto affiancati i solidi (brick) e poi con elementi sempre più complessi di piastra e guscio capaci di raggiungere limiti di spessore sempre più piccoli e campi di spostamento sempre maggiori. Proprio questa evoluzione inevitabile del metodo ad elementi finiti dal campo delle linearità a quello delle non linearità, sia nella geometria che nel materiale, ha portato ad affinare sempre più i metodi di analisi numerica per la soluzione di sistemi differenziali. Alla fine degli anni ‘70 e nei successivi anni ‘80 la numerica sopperiva anche ad una carenza legata strettamente all’hardware dei calcolatori che ancora non potevano disporre di memorie e processori tali da garantire prestazioni elevate. Parla una persona che ha scritto una tesi di dottorato da centinaia di pagine salvandola sul caro vecchio floppy disk da tre pollici e mezzo e che ha avuto la fortuna di poter lavorare con un computer dotato di alcuni giga di memoria! Parla però anche una persona che ha avuto una ulteriore fortuna: avere un relatore di dottorato che lo ha guidato, per anni, alla programmazione in fortran 77 potendo lavorare direttamente sul kernel dei codici sorgenti dei maggiori software non lineari dell’epoca. Fino alla fine degli anni ‘90 la maggior parte dei codici di ricerca, ma anche adibiti all’uso professionale, consentivano l’inserimento dei dati con procedura manuale tramite “linea di comando”. Metodo a cui sono ancora affezionati i “vecchioni” come me, metodo di cui, giustamente, oramai le giovani leve non sanno neanche più il significato. Perché mi permetto di dire “giustamente”? Perché sono convinto che nella “ricetta” riportata all’inizio dell’articolo manca un ingrediente essenziale ed oramai ineludibile, l’interfaccia utente (la meglio nota UI=User Interface). Sono anche convinto, avendo fatto esperienza diretta, continua e approfondita di implementazione all’interno di codici ad elementi finiti, che non sia più il caso di andare alla ricerca di nuovi “elementi finiti” o di nuovi “algoritmi” raffinatissimi che riducono l’errore, rispetto alla soluzione analitica, di centesimi percentuali, ma il futuro è da ricercare proprio nelle interfacce utente e nelle nuove tecnologie di relazione con l’utilizzatore finale, cioè il professionista che pensa, crea il modello, lo analizza e infine progetta la struttura. Per essere ancora più precisi, è necessario indirizzare lo sviluppo del software, almeno nell’ambito proprio dell’ingegneria civile, verso quegli strumenti che consentono l’interazione tra il programma di calcolo e l’utente, come per esempio avviene attraverso la tecnologia BIM. BIM è un acronimo che sta per “Building information modeling” e significa creare un manufatto virtuale che contenga tutte le informazioni necessarie al progetto e che possa essere scambiabile tra più soggetti coinvolti. A maggiore supporto di questa tesi il fatto che gli hardware progrediscono in maniera sempre più rapida e qualunque limite di memoria o di processore è un “incubo” oramai superato da tempo. Al contrario i tempi stretti a cui i professionisti sono chiamati richiedono la creazione di modelli ed il loro controllo, dall’architettonico alla logistica di cantiere, in tempi sempre più stretti. Questo obiettivo può essere raggiunto esclusivamente con interfacce utente sempre più a misura di progettista. In conclusione, pur non potendo fornire la soluzione, ma semplicemente indicando la direzione, è necessario passare dal disegno di una linea alla creazione di un “modello d’informazione”, di una “grammatica”, capace tramite un linguaggio condiviso di rappresentare l’intero processo ingegneristico dalla creazione astratta alla realizzazione in cantiere. Quando si vuole intraprendere un discorso appropriato sullo sviluppo dei software di calcolo strutturale bisogna conoscere in profondità il passato e, soltanto in una fase successiva, cercare di capire le future strade percorribili. Il passato è rinchiuso in una “ricetta” di successo che è stata capace di creare un mix inconfondibile tra analisi numerica (facente parte della matematica applicata), metodo agli elementi finiti (che niente altro è se non una tecnica numerica) e abilità di grandi personalità dell’ingegneria-matematica (o della matematica applicata all’ingegneria!) quali Bathe, Wilson, Zienkiewicz, Iron, Taylor e tanti altri. In una prima fase il metodo fem (acronimo ormai di larga diffusione in ambiente tecnico) è stato capace di riportare la realtà fisica, che fosse un edificio civile o un pezzo meccanico, ad una schematizzazione discreta: prima con elementi monodimensionali (i ben noti beam) a cui si sono presto affiancati i solidi (brick) e poi con elementi sempre più complessi di piastra e guscio capaci di raggiungere limiti di spessore sempre più piccoli e campi di spostamento sempre maggiori. Proprio questa evoluzione inevitabile del metodo ad elementi finiti dal campo delle linearità a quello delle non linearità, sia nella geometria che nel materiale, ha portato ad affinare sempre più i metodi di analisi numerica per la soluzione di sistemi differenziali. Alla fine degli anni ‘70 e nei successivi anni ‘80 la numerica sopperiva anche ad una carenza legata strettamente all’hardware dei calcolatori che ancora non potevano disporre di memorie e processori tali da garantire prestazioni elevate. Parla una persona che ha scritto una tesi di dottorato da centinaia di pagine salvandola sul caro vecchio floppy disk da tre pollici e mezzo e che ha avuto la fortuna di poter lavorare con un computer dotato di alcuni giga di memoria! Parla però anche una persona che ha avuto una ulteriore fortuna: avere un relatore di dottorato che lo ha guidato, per anni, alla programmazione in fortran 77 potendo lavorare direttamente sul kernel dei codici sorgenti dei maggiori software non lineari dell’epoca. Fino alla fine degli anni ‘90 la maggior parte dei codici di ricerca, ma anche adibiti all’uso professionale, consentivano l’inserimento dei dati con procedura manuale tramite “linea di comando”. Metodo a cui sono ancora affezionati i “vecchioni” come me, metodo di cui, giustamente, oramai le giovani leve non sanno neanche più il significato. Perché mi permetto di dire “giustamente”? Perché sono convinto che nella “ricetta” riportata all’inizio dell’articolo manca un ingrediente essenziale ed oramai ineludibile, l’interfaccia utente (la meglio nota UI=User Interface). Sono anche convinto, avendo fatto esperienza diretta, continua e approfondita di implementazione all’interno di codici ad elementi finiti, che non sia più il caso di andare alla ricerca di nuovi “elementi finiti” o di nuovi “algoritmi” raffinatissimi che riducono l’errore, rispetto alla soluzione analitica, di centesimi percentuali, ma il futuro è da ricercare proprio nelle interfacce utente e nelle nuove tecnologie di relazione con l’utilizzatore finale, cioè il professionista che pensa, crea il modello, lo analizza e infine progetta la struttura. Per essere ancora più precisi, è necessario indirizzare lo sviluppo del software, almeno nell’ambito proprio dell’ingegneria civile, verso quegli strumenti che consentono l’interazione tra il programma di calcolo e l’utente, come per esempio avviene attraverso la tecnologia BIM. BIM è un acronimo che sta per “Building information modeling” e significa creare un manufatto virtuale che contenga tutte le informazioni necessarie al progetto e che possa essere scambiabile tra più soggetti coinvolti. A maggiore supporto di questa tesi il fatto che gli hardware progrediscono in maniera sempre più rapida e qualunque limite di memoria o di processore è un “incubo” oramai superato da tempo. Al contrario i tempi stretti a cui i professionisti sono chiamati richiedono la creazione di modelli ed il loro controllo, dall’architettonico alla logistica di cantiere, in tempi sempre più stretti. Questo obiettivo può essere raggiunto esclusivamente con interfacce utente sempre più a misura di progettista. In conclusione, pur non potendo fornire la soluzione, ma semplicemente indicando la direzione, è necessario passare dal disegno di una linea alla creazione di un “modello d’informazione”, di una “grammatica”, capace tramite un linguaggio condiviso di rappresentare l’intero processo ingegneristico dalla creazione astratta alla realizzazione in cantiere. Quando si vuole intraprendere un discorso appropriato sullo sviluppo dei software di calcolo strutturale bisogna conoscere in profondità il passato e, soltanto in una fase successiva, cercare di capire le future strade percorribili. Il passato è rinchiuso in una “ricetta” di successo che è stata capace di creare un mix inconfondibile tra analisi numerica (facente parte della matematica applicata), metodo agli elementi finiti (che niente altro è se non una tecnica numerica) e abilità di grandi personalità dell’ingegneria-matematica (o della matematica applicata all’ingegneria!) quali Bathe, Wilson, Zienkiewicz, Iron, Taylor e tanti altri. In una prima fase il metodo fem (acronimo ormai di larga diffusione in ambiente tecnico) è stato capace di riportare la realtà fisica, che fosse un edificio civile o un pezzo meccanico, ad una schematizzazione discreta: prima con elementi monodimensionali (i ben noti beam) a cui si sono presto affiancati i solidi (brick) e poi con elementi sempre più complessi di piastra e guscio capaci di raggiungere limiti di spessore sempre più piccoli e campi di spostamento sempre maggiori. Proprio questa evoluzione inevitabile del metodo ad elementi finiti dal campo delle linearità a quello delle non linearità, sia nella geometria che nel materiale, ha portato ad affinare sempre più i metodi di analisi numerica per la soluzione di sistemi differenziali. Alla fine degli anni ‘70 e nei successivi anni ‘80 la numerica sopperiva anche ad una carenza legata strettamente all’hardware dei calcolatori che ancora non potevano disporre di memorie e processori tali da garantire prestazioni elevate. Parla una persona che ha scritto una tesi di dottorato da centinaia di pagine salvandola sul caro vecchio floppy disk da tre pollici e mezzo e che ha avuto la fortuna di poter lavorare con un computer dotato di alcuni giga di memoria! Parla però anche una persona che ha avuto una ulteriore fortuna: avere un relatore di dottorato che lo ha guidato, per anni, alla programmazione in fortran 77 potendo lavorare direttamente sul kernel dei codici sorgenti dei maggiori software non lineari dell’epoca. Fino alla fine degli anni ‘90 la maggior parte dei codici di ricerca, ma anche adibiti all’uso professionale, consentivano l’inserimento dei dati con procedura manuale tramite “linea di comando”. Metodo a cui sono ancora affezionati i “vecchioni” come me, metodo di cui, giustamente, oramai le giovani leve non sanno neanche più il significato. Perché mi permetto di dire “giustamente”? Perché sono convinto che nella “ricetta” riportata all’inizio dell’articolo manca un ingrediente essenziale ed oramai ineludibile, l’interfaccia utente (la meglio nota UI=User Interface). Sono anche convinto, avendo fatto esperienza diretta, continua e approfondita di implementazione all’interno di codici ad elementi finiti, che non sia più il caso di andare alla ricerca di nuovi “elementi finiti” o di nuovi “algoritmi” raffinatissimi che riducono l’errore, rispetto alla soluzione analitica, di centesimi percentuali, ma il futuro è da ricercare proprio nelle interfacce utente e nelle nuove tecnologie di relazione con l’utilizzatore finale, cioè il professionista che pensa, crea il modello, lo analizza e infine progetta la struttura. Per essere ancora più precisi, è necessario indirizzare lo sviluppo del software, almeno nell’ambito proprio dell’ingegneria civile, verso quegli strumenti che consentono l’interazione tra il programma di calcolo e l’utente, come per esempio avviene attraverso la tecnologia BIM. BIM è un acronimo che sta per “Building information modeling” e significa creare un manufatto virtuale che contenga tutte le informazioni necessarie al progetto e che possa essere scambiabile tra più soggetti coinvolti. A maggiore supporto di questa tesi il fatto che gli hardware progrediscono in maniera sempre più rapida e qualunque limite di memoria o di processore è un “incubo” oramai superato da tempo. Al contrario i tempi stretti a cui i professionisti sono chiamati richiedono la creazione di modelli ed il loro controllo, dall’architettonico alla logistica di cantiere, in tempi sempre più stretti. Questo obiettivo può essere raggiunto esclusivamente con interfacce utente sempre più a misura di progettista. In conclusione, pur non potendo fornire la soluzione, ma semplicemente indicando la direzione, è necessario passare dal disegno di una linea alla creazione di un “modello d’informazione”, di una “grammatica”, capace tramite un linguaggio condiviso di rappresentare l’intero processo ingegneristico dalla creazione astratta alla realizzazione in cantiere.