Il Prossimo Giovedì 20 Gennaio 2011 alle ore 18:00
alle  presso la sede dell'ISTITUTO QUASAR
via Nizza, 152 - Roma

si terrà la lecture Cloud Design, in cui saranno presentati
progetti e lavori compiuti anche durante le attività di Tecniche Parametriche
di progettazione 2008-2011. Siete tutti invitati a partecipare, e intervenire!

cloud design
la lecture indaga l'evoluzione dei metodi di progettazione e produzione, che a partire da presupposti e provocazioni tecnologiche conduce alla evoluzione dei profili professionali e umani. Non si tratta, quindi, solo di riconoscere nuove forme di autorialità nel cloud computing per produrre spimes e strutturare gruppi allargati e flessibili di produzione, ma progettare per le nuove forme organizzative, usando flessibilità e negoziazione come forme espressive e il networking sui server di progettazione come strumento operativo.
Per passare dal solipsistico parametric modeling al "parametric being".

Cari ragazzi,
tra i temi che molti di voi stanno esplorando, discussi più volte al corso,
c'è la variazione dei componenti costruttivi. Di seguito vi segnalo diverse
tecniche:

1. Revit 2010 - "Power Copy" script

Lo script, usato tra gli altri progetti, per la Lampada Nagashima,
è stato sviluppato durante lo scorso anno per permettere di effettuare
copie "intelligenti" di un componente, che ad ogni passo, permettesse anche
di variare dei parametri. L'ultimo esempio che pubblichiamo qui, sviluppato
da Stefano Guarnieri per il progetto Calatrava/superficie rigata di Valeria Vitale



Il vantaggio di questa tecnica è che permette di schedulare i valori dei parametri
(come si vede dalla immagine qui sopra, dove ogni componente ha dimensioni leggibili)


2. Revit 2011 - Componenti adattativi e Reporting Parameters

L'intento che lo script 2011 si prefiggeva è stato, nel frattempo "raggiunto" dallo sviluppo
software, come accade sempre più spesso nel recente panorama in cui cresce la capacità
di scripting da parte degli "utenti" e dei progettisti impegnati nella implementazione reale
nell'attività progettuale e realizzativa.

In particolare le funzioni, nuove, che permettono un controllo analogo sono
i componenti adattativi e i Reporting Parameters (Parametri di rapporto).

Del componente adattivo si è detto a lezione, paragonandolo a tutti gli altri sistemi
di controllo e produzione della variazione, primo tra tutti Generative Components,
software nato col nome di Custom Objects e precursore del settore, a cui si aggiungono
le "User Feature" di molti software di progettazione meccanica e, in ultimo, le diverse
opzioni concesse dal plug-in di Rhino Grasshopper.


Biennale di Venezia, 2010

I progetti che si occupano nel corso di questo tema sono, al momento, quello di
Lorenzo Catena, che mima il progetto di SHoP per la copertura del centro Post-Katryna
nei pressi New Orleans:



E quello, parallelo in corso di sviluppo, di Ivo Petri

A questa nuova modalità concessa da Revit, per lavorare questi temi su base eminentemente grafica,
si somma la necessità di controllare matematicamente le geometrie di progetto. Su questo tema,
si sono svolti incontri con il contributo del prof. Corrado Falcolini, del Dipartimento di Matematica, che ha
anche dato un contributo al Seminario "Forma e disegno nell'architettura del sei e settecento".

Sul tema del controllo matematico delle geometrie in Revit con metodi grafici, si è interessato
Giuseppe Di Fabio, citando anche il lavoro di "The Revit Kid":



Giuseppe è ora impegnato nella produzione di variazioni architettoniche del tema
di una copertura/portico a generatrici pseudo-sinusoidali.

Al tema della variazione architettonica di un componente
lucernario/copertura, infine si sta interessanto Elena Valik,
che a partire da un progetto per una piccola pensilina, e alla
parametrizzazione di un lucernario come pattern basato su tre punti,
sta ora passando alla produzione di vari componenti di chiusura orizzontale
per un sistema di copertura e lucernari a modulo triangolare variabile




Aspettiamo ora da Elena gli aggiornamenti del lavoro di parametrizzazione
e le sue applicazioni architettoniche.


Sostanzialmente i lavori di questa sezione richiamano i due possibili
contesti per un lavoro architettonico sulla variazione:

1 .  serie
la produzione di pezzi autonomi (o di design) con geometria variata nella serie.
Il paradigma della mass customization che abbiamo no inquadrato negli anni
in quello Beyond IKEA

2. pezzi unici
la produzione di oggetti architettonici fatti da componenti dalla geometria
variabile, a cui fanno riferimento moltissimi progetti della contemporaneità
e quelli prodotti nel Laboratorio di Tecniche Parametriche 2011.


Ha senso, però, in fondo, parlare in questi termini di distinzione?
Non si tratta anche di cambiare un pò il modo di progettare e renderlo più "diffuso"?
Figlio di questa "nuova standardizzazione fatta di pezzi diversi"? A questo tema è ispirata
la pubblicazione, e il concetto collegato, di versioning ipotizzato da SHoP Architects.

A voi, ora fare le vostre riflessioni parallele ai progetti che elaborerete.

Buon lavoro!





 

Store_Selections - It builds some virtual boxes, where recovering the past selections to compare each other

Random_Selection_Panels - It picks, accidentally, a number of panels between the selected, equal to the chosen percentage

Set_Color_In_View - It changes the color of the edges of each type, in the active view

Bridge_Of_The_ Peace - It places points in the space, following the shape of the roof of a bridge - Conceptual mass

Physical_ID - Before it loads a family in the .rvt, then it creates and rotates some istances of it

S.A.T.: the Truss - Writing and reading of text files to interact with other softwares

Setting_Line_Color - This code allows to set the color of all the lines within the document

Shape_Discovering - This code shows, by listing, the relationship between points and 3D snapped model lines - Conceptual mass

Line_By_Selected_Points - This code creates a line joining two selected points - Conceptual mass

Get_Nodes - This code lists some features of a Structural Frame (columns and beams) - Project Based

Naming_ReferencePoints  - This code allows to assign a "personal id" number to each reference point in the Comment Field - Conceptual mass

New_Caledonia -  This sample creates new family instances along an arc (inspired by Renzo Piano's project)

--
All the examples require Login to download the files

Titolo Aggiornamentoordinamento crescente Creazione Nuovi commenti tags Autore
1_gradino 5 anni 11 mesi fa 13 anni 8 mesi fa Immagine ValentinaDelVescovo
1_gradino 5 anni 11 mesi fa 13 anni 8 mesi fa Immagine ValentinaDelVescovo
2_famiglie gradino 5 anni 11 mesi fa 13 anni 8 mesi fa Immagine ValentinaDelVescovo
3_parametro gradino 5 anni 11 mesi fa 13 anni 8 mesi fa Immagine ValentinaDelVescovo
4_scala1 5 anni 11 mesi fa 13 anni 8 mesi fa Immagine ValentinaDelVescovo
5_scala2 5 anni 11 mesi fa 13 anni 8 mesi fa Immagine ValentinaDelVescovo
6_scala3 5 anni 11 mesi fa 13 anni 8 mesi fa Immagine ValentinaDelVescovo
7_scala1ok 5 anni 11 mesi fa 13 anni 8 mesi fa Immagine ValentinaDelVescovo
8_scala2ok 5 anni 11 mesi fa 13 anni 8 mesi fa Immagine ValentinaDelVescovo
9_scala3ok 5 anni 11 mesi fa 13 anni 8 mesi fa Immagine ValentinaDelVescovo

Pagine

 

Thanks to prof. Todesco for his vital help.

FileInfo t = new FileInfo(@"C:\Documents and Settings\Gguarnieri\Documenti\Desktop\TrussData.txt");
            StreamWriter Tex = t.CreateText();
            Tex.WriteLine("BARS LIST");
            Tex.Write(Tex.NewLine);
            Tex.Write("{0}_________", "ID");
            Tex.Write("{0}_________", "lenght");
            Tex.Write("{0}_________", "from node");
            Tex.Write("{0}_________", "to node");
            Tex.Write(Tex.NewLine);
            Tex.Write("-----------------------------------------------------------------------------------------");
            Tex.Write(Tex.NewLine);
 
            SetVertici vertici = new SetVertici();
            double ConvMeter = 0.3048;
            int approx = 2;
            int numBars = 0;
            Level level=null;
            ElementIterator levelIter = Application.ActiveDocument.get_Elements(typeof(Level));
            levelIter.Reset();
            while (levelIter.MoveNext())
            {
                Level level1 = levelIter.Current as Level;
                if (level1.Elevation > 0)
                {
                    level = level1;
                }
            }
            ElementIterator elemIter = Application.ActiveDocument.get_Elements(typeof(FamilyInstance));
            elemIter.Reset();
            
            while (elemIter.MoveNext())
            {
               
                FamilyInstance FamInst = elemIter.Current as FamilyInstance;
                StructuralType StructType = FamInst.StructuralType;
                Location Loc = FamInst.Location;
                ElementId ElemId = FamInst.Id; 
                
                string familyName = FamInst.Name;
                string NameFam = ElemId.Value.ToString();
                int giunto = 0;
                Vertice v = null;
 
                if (familyName == "cone")
                    {
                        giunto = 1;
                        LocationPoint point = Loc as LocationPoint;
                        v = vertici.getVertice(point.Point,giunto);
                        
                        
                    }
                    else if (familyName == "cylinder")
                    {
                        giunto = 2;
                        LocationPoint point = Loc as LocationPoint;                        
                        v = vertici.getVertice(point.Point,giunto);
                        
                     
                    }
 
                else if (StructType == StructuralType.Beam || StructType == StructuralType.Brace)
                {
                    
                    numBars = ++numBars;
                    LocationCurve CurveLoc = Loc as LocationCurve;
                    Curve curve = CurveLoc.Curve;
 
                    XYZ StartPoint = curve.get_EndPoint(0);
                    XYZ EndPoint = curve.get_EndPoint(1);
 
 
                    Vertice v0 = vertici.getVertice(StartPoint, giunto);
                    string id0 = v0.id.ToString();
 
                    Vertice v1 = vertici.getVertice(EndPoint, giunto);
                    string id1 = v1.id.ToString();
 
                    
                    
                    string lenght = (Math.Round((curve.Length) * ConvMeter, approx)).ToString();
 
 
                    string data = String.Format(" {0}      {1,16}     {2,15}     {3,20}", NameFam, lenght, id0,id1);
                    Tex.WriteLine(data);
                   
                    Tex.WriteLine("-----------------------------------------------------------------------------------------");
                    
                   
                }
                else if(StructType== StructuralType.Column)
                {
                    
                    numBars = ++numBars;                    
                    LocationPoint point = Loc as LocationPoint;
                    Vertice v0 = vertici.getVertice(point.Point, giunto);
                    string id0 = v0.id.ToString();
                    Vertice v1 = vertici.getVertice(v0.x,v0.y,level.Elevation,giunto);
                    string id1 = v1.id.ToString();
 
                    string lenght = (Math.Round((v0.distance(v1)) * ConvMeter, approx)).ToString();
                    
                    string data = String.Format(" {0}      {1,16}     {2,15}     {3,20}", NameFam, lenght, id0, id1);
                    Tex.WriteLine(data);
 
                    Tex.WriteLine("-----------------------------------------------------------------------------------------");
                }
                
            }
 
 
 
            Tex.Write(Tex.NewLine);
            Tex.WriteLine("NODES LIST");
            Tex.Write(Tex.NewLine);
            Tex.Write("{0}_________", "NUMBER");
            Tex.Write("{0,5}_________", "X");
            Tex.Write("{0,5}_________", "Y");
            Tex.Write("{0,5}_________", "Z");
            Tex.Write("{0,5}_________", "JOINT");
            Tex.Write(Tex.NewLine);
            Tex.Write("-----------------------------------------------------------------------------------------");
            Tex.Write(Tex.NewLine);
            for (int i = 0; i < vertici.Count(); i++)
            {
                
                Vertice v = vertici.at(i);
                string giunto = "";
                if (v.joint == 0)
                {
                    giunto = "unknown";
                }
                else if (v.joint == 1)
                {
                    giunto = "cone";
                }
                else if (v.joint == 2)
                {
                    giunto = "cylinder";
                }
 
 
                Tex.Write("{0,3}", v.id.ToString());
                Tex.Write("{0,20}", (Math.Round((v.x) * ConvMet, approx)).ToString());
                Tex.Write("{0,20}", (Math.Round((v.y) * ConvMet, approx)).ToString());
                Tex.Write("{0,20}", (Math.Round((v.z) * ConvMet, approx)).ToString());
                Tex.Write("{0,20}", giunto);
                Tex.Write(Tex.NewLine);
                Tex.Write("-----------------------------------------------------------------------------------------");
                Tex.Write(Tex.NewLine);
            }
 
            Tex.Write(Tex.NewLine);
            Tex.Write("{0,10}_________", "BARS number");
            Tex.Write("{0,10}_________", numBars.ToString());
            Tex.Write("{0,10}_________", "NODES number");
            Tex.Write("{0,10}_________", vertici.Count().ToString());
 
            Tex.Close();     
          }           
 
 
public class SetVertici
    {
 
        List<Vertice> vertici = new List<Vertice>();
 
        public Vertice getVertice(double x, double y, double z, int joint)
        {
            Vertice posizione = new Vertice(x, y, z, joint);
      
            Vertice piuVicino = null;
            double distanza2Minima = 0;
            
            for (int i = 0; i < vertici.Count(); i++)
            {
           
                double distanza2 = vertici[i].distance2(posizione);
                int giuntoVero = vertici[i].joint;
                if (giuntoVero != 0 && distanza2<5)
                {
                    posizione.joint = giuntoVero;
                }
 
                if (piuVicino == null || distanza2 < distanza2Minima)
                {
                    piuVicino = vertici[i];
                    distanza2Minima = distanza2;
                }
            }
           
            if (piuVicino != null && distanza2Minima < 1)
            {
                piuVicino.joint = posizione.joint;
                return piuVicino;
            }
           
 
            posizione.id = vertici.Count();
            vertici.Add(posizione);
 
 
            return posizione;
        }
 
        public Vertice getVertice(Autodesk.Revit.Geometry.XYZ coords,int tipoGiunto)
        {
            return getVertice(coords.X, coords.Y, coords.Z,tipoGiunto);
        }
        public int Count()
        {
            return vertici.Count();
        }
 
        public Vertice at(int index)
        {
            return vertici[index];
        }
 
    }
 
 
public class Vertice
    {
   
        double _x;
        double _y;
        double _z;
        int _id;
        int _joint;
        
        
 
        public Vertice(double x, double y, double z, int TipoGiunto)
        {
            _x = x;
            _y = y;
            _z = z;
            _id = -1;
            _joint = TipoGiunto;
        }
 
      
        public double x
        {
            get { return _x; }
 
        }
 
        public double y
        {
            get { return _y; }
 
        }
 
 
        public double z
        {
            get { return _z; }
 
        }
        
        public double distance2(Vertice v)
        {
            return Math.Pow(v.x - _x, 2) + Math.Pow(v.y - _y, 2) + Math.Pow(v.z - _z, 2);
        }
 
      
        public double distance(Vertice v)
        {
            return Math.Sqrt(distance2(v));
        }
 
        public int id
        {
            get { return _id; }
            set { _id = value; }
        }
 
        public int joint
        {
            get { return _joint; }
            set { _joint = value; }
        }
    }

[ 2011 ]  l'evoluzione dei metodi di progettazione e produzione,  a partire da presupposti e provocazioni tecnologiche conduce alla evoluzione dei profili professionali e umani. Non si tratta, quindi, solo di riconoscere nuove forme di autorialità nel cloud computing per produrre spimes e strutturare gruppi allargati e flessibili di produzione, ma progettare per le nuove forme organizzative, usando flessibilità e negoziazione come forme espressive e il networking sui server di progettazione come strumento operativo.

Per passare dal solipsistico parametric modeling al "parametric being".

Relazione finale corso A.A. 2010/2011

Tecniche parametriche di progettazione

 Relazione finale del corso A.A. 2010/11

1)     Approccio metodologico

2)     Tool  utilizzati

3)     Esperienze sul campo

4)     Pros e cons

5)     Conclusioni

Nota: le immagini sono tratte dal blog del Corso : http://design.rootiers.it

1.     Approccio metodologico

Definire gli obiettivi di un progetto, scegliere i tool adeguati, definire la metrica utile per “misurare” i risultati, stimare lo scheduling appropriato.  Queste sono le milestones che ogni persona incontra (e con cui si scontra) durante il proprio percorso professionale. Questa relazione descrive come “costruire” le 4 milestones  nell’ambito di una attività progettuale volta a definire  un mobile, un plot urbanistico ed un manufatto architettonico. Tronchiamo l’elenco per non appesantire la relazione ed esaurire la pazienza dei lettori..

Nella mia attività di ricercatore (fisico), statistico (controllo processo), team leader (diversi ambiti) ho esperito la prima milestone come la più dura, sfuggente, pericolosa.  I consulenti aziendali, conoscendo bene tale difficoltà, la aggirano ed enunciano a volte la sua “scontatezza”, a volte la sua “futilità”. L’insegnamento universitario in Italia si è incagliato su questa milestone e nessuna riforma politica calata dall’alto potrà risolvere tale impasse.

Descriviamo l’approccio usato nel passato. Un committente si rivolge ad un “esperto” formulando una richiesta orale/scritta. L’esperto redige una proposta con la stima dei costi, inizia una trattativa con il committente e, se questa giunge a buon fine, seguiranno azioni/processi adeguati a soddisfare il committente.

Tale flusso di processo diviene marginale quando si sviluppano mercati “globali”; ad esempio la produzione e commercializzazione di automobili (non per l’élite) è avvenuta utilizzando un altro flusso di processo ben noto (dal fordismo al just in time per essere concisi). Per abbassare i costi di produzione, l’artigiano produceva piccoli lotti dello stesso manufatto, il notaio redigeva gli atti con lo stesso layout formale, il commerciante acquistava all’ingrosso la merce. L’obiettivo era vendere un mobile, concludere un atto di acquisto, vendere l’intero lotto di merce; i tool utilizzati erano gli strumenti del falegname, la preparazione giuridica, la gestione di un negozio per la vendita al dettaglio; i risultati erano misurati dal fatturato (anche mediato su 5 anni), lo scheduling era facilmente definito.

L’approccio contemporaneo non può replicare l’approccio usato nel passato.  Nell’ambito della progettazione urbanistica e/o architettonica l’approccio usato nel passato ha perso  validità. Utilizzare un computer per preparare le tavole di progetto equivale a trasportare una balla di fieno con una Ferrari, è  uno spreco di risorse e una dimostrazione di stupidità. I tool informatici disponibili, affidabili ed economici, ci suggeriscono che la prima milestone (gli obiettivi) per l’attività del progettista che lavora ad esempio nella disciplina urbanistica ed architettonica è radicalmente mutata.

Sinteticamente il primo obiettivo del progettista è la “stima della latitudine del progetto”.  Ma cosa si intende per “latitudine del progetto” ? L’oscuro termine proviene dal mondo della manifattura, un esempio reale esporrà il concetto.

La società Ferrari (assembla automobili di lusso) all’inizio degli anni 70’ subiva la concorrenza di altre aziende che proponevano automobili dotate di carrozzerie a prova di “ruggine” anche in ambienti aggressivi (atmosfera marina).

Le componenti meccaniche, il design, il comfort di guida erano allineate tra i prodotti offerti nel segmento di lusso, ma i prezzi di vendita  per le auto assemblate dalla società  Ferrari  erano piú alti. La protezione antiruggine della Ferrari non era all’altezza delle performance  meccaniche e la società decise di cambiare radicalmente il suo processo di fabbricazione.

Il Centro Sviluppo Materiali (centro di ricerca - CSM) fu coinvolto come depositario di expertise per risolvere i problemi di corrosione.  Un chimico studiò a fondo tali problemi e progettò un  sistema di trattamento antiruggine, innovativo a livello mondiale,  caratterizzato da costi contenuti.  Il chimico preparò la sua relazione ed incontrò i tecnici che all’epoca erano responsabili della conduzione dei trattamenti antiruggine per la Ferrari; espose l’analisi dei problemi incontrati e propose il suo processo innovativo, processo che in laboratorio aveva prodotto campioni di carrozzeria caratterizzati da incredibili livelli di protezione antiruggine. I tecnici si congratularono con il chimico ed iniziarono a fare delle semplici domande:  se l’operaio che controlla i bagni dei pezzi di carrozzeria si distrae anche soltanto per un minuto e la concentrazione di un certo componente  chimico presente nel bagno varia del 2 % (l’operaio può cambiare la concentrazione agendo su alcune “manopole”) cosa succede ai pezzi di carrozzeria trattati ? La risposta del chimico fu che i film di passivazione e vernice  depositati sulla carrozzeria avrebbero perso il 50% delle loro caratteristiche antiruggine.  I tecnici della Ferrari rigettarono la proposta e chiesero al chimico di progettare un nuovo trattamento antiruggine robusto motivando la loro richiesta: “Caro collega non abbiamo bisogno di una carrozzeria che resista ad attacchi di corrosione per i prossimi 100 anni, abbiamo bisogno di un processo di trattamento anticorrosione che rimanga valido anche se la percentuale dei componenti chimici nel bagno di trattamento varia del 10% poiché il 10% è la percentuale di variazione che i nostri operai non sono umanamente in grado di controllare”. Il chimico raccolse la sfida e progettò un trattamento antiruggine che fu accettato dalla Ferrari, andò in produzione e si dimostrò il miglior trattamento antiruggine a livello mondiale negli anni 1975-1990: il chimico progettò un processo caratterizzato da “latitudine di processo”.

Come replicare la storia di successo nell’ambito della progettazione urbanistica/architettonica ?  L’unica metodologia attualmente disponibile consiste nell’uso di package utilizzati per la progettazione di prototipi, ovvero package dedicati alla progettazione parametrica.  L’obiettivo dell’attività non sarà la presentazione di “un progetto” ma la presentazione di “una famiglia di progetti”.  Un plot urbanistico , essendo il disegno un tool rigido, è corredato da regole, indicazioni, divieti che descrivono i gradi di libertà del plot, corredo indispensabile che permette la realizzazione del plot stesso.  La lingua parlate e scritta è uno strumento flessibile ed ambiguo, pertanto un developer può servirsi di frasi ambigue per far approvare progetti di bassa qualità urbanistica/architettonica ma lucrosi per lui.  Questa  attività di “scardinamento” di un PRG ricorre in Italia con elevata frequenza e vanifica tutte le barriere che una  PA costruisce per garantire una decente qualità urbanistica/architettonica degli insediamenti futuri.

Un plot urbanistico caratterizzato da ” latitudine di progetto” contiene gli intervalli di variabilità ammessi per ogni parametro caratteristico del progetto (altezza, sul , distribuzione degli spazi comuni, ecc.), tale plot ricorda l’attività di un maestro di scacchi che prepara una famiglia di alternative in grado di contrastare le strategie dell’avversario.  I disegni statici normalmente usati nel lavoro di progettazione costituiscono un tool  inadeguato, le regole scritte sono facilmente aggirabili. La progettazione parametrica costituisce l’unico metodo di lavoro, serio e corretto, fino a quando altri strumenti di realtà virtuale, di aiuto alla progettazione, verranno immessi sul mercato dopo aver raggiunto requisiti minimi di costo, affidabilità e manutenibilità.

2.  Tool  utilizzati 

Il docente ha descritto i packages REVIT e VASARI quali software tool utili alla progettazione parametrica. Nella comunità dei progettisti tali package sono pensati ed usati unicamente come tool adatti alla definizione di prototipi sperimentali, ma nell’ultima versione disponibile tali strumenti sono stati esaminati dal docente e ne sono state esplorate le diverse “dimensioni”: parametrica, edile, computistica (schedule), energetica ed anche  quella delle fasi di assemblaggio.

 E’ stata per me una gradita sorpresa osservare come la metodologia della programmazione per oggetti sia stata sposata dagli sviluppatori di REVIET e VASARI.  Da vecchio softwarista (ho iniziato la mia attivitá con i computer nel  1978)  ho utilizzato i primi compilatori LISP nel campo della AI (Artificial Intelligence);  i compilatori  LISP costituivano i primi software  che utilizzavano  la programmazione per oggetti.

La dimensione parametrica dei package è facilmente gestibile con link tra i vari parametri, la possibilità di scrivere macro per il loro calcolo e la loro gestione, la scelta tra parametro di occorrenza e locale; tale gestione e l’aggiornamento delle viste in tempo reale  permettono  la verifica degli intervalli ammissibili dei parametri del progetto.

La dimensione edile è costituita dalla presenza di componenti edili provenienti dal mondo reale (finestre, porte, pannelli, travi standard, ecc.), componenti caratterizzati dalla variabilità delle loro quote.

La dimensione computistica (schedule) permette il monitoraggio in tempo reale delle liste dei materiali necessari per l’assemblaggio ottenendo quindi  il controllo dei costi. Questa dimensione è trascurata dagli architetti che non stimano correttamente i costi di realizzazione delle loro proposte e fanno affidamento unicamente sulle dimensioni estetiche dei loro progetti per ricevere l’approvazione dei committenti.

Usando in modo intelligente le tecniche parametriche qualunque committente potrà far verificare da un tecnico di fiducia la variabilità dei costi della famiglia dei progetti presentati; tale variabilità è una stima del rischio che il committente si assume accettando le proposte del progettista: maggiore è l’ampiezza dell’intervallo delle stime dei costi, maggiore sarà il rischio che il committente si assume.  Usando tecniche tradizionali di progettazione il committente otterrà, in modo laborioso, solo una o due stime dei costi di realizzazione e tali dati, non conoscendo l’errore di tali stime, non forniranno informazioni sufficienti per la stima del rischio.

La dimensione energetica permette di stimare l’insolazione, il gioco delle ombre durante l’intero arco dell’anno e la gestione dei vuoti.

La dimensione temporale o delle fasi di assemblaggio è essenziale per individuare le componenti critiche della famiglia di progetti. Tali componenti, nel caso della progettazione di mobili, causano aumenti notevoli dei costi di produzione e decretano molte volte il rigetto del progetto da parte del committente. L’uso delle fasi di assemblaggio simula la successione dei processi che avranno luogo e mostra le criticità della sequenza stessa.  Un evento che si verifica frequentemente nei cantieri edili è l’insorgere di problemi non prevedibili; REVIT permette di esaminare facilmente modifiche al progetto originale, stimare i costi delle opzioni realizzabili, orientare la scelta del committente verso un compromesso tra aumento dei costi e qualità urbanistica/architettonica.

Un discorso a parte merita l’uso dei tool didattici per la condivisione della conoscenza impostati dal docente. Nel WEB sono disponibili siti interattivi sofisticati e di facile uso; il sito progettato dal docente ed utilizzato durante il corso è funzionale ma richiede un approccio diverso da parte degli studenti rispetto al classico ciclo: lezione in aula, esercitazione, revisione, lezione.   Per mia esperienza qualsiasi attività didattica deve utilizzare un mix pedagogico comprendente: comunicazione a due vie, comunicazione ad una via, uso della lavagna, uso di filmati, disegni, studio dettagliato di un corpus teorico relativo agli argomenti trattati, lezioni magistrali condotte da esperti del settore. Questo mix , difficile da progettare, permette al discente di evitare la trappola classica dell’uso “scimmiesco" (mi scuso con le scimmie …) dei package.  Eseguire una catena di azioni senza comprendere il significato metodologico, fisico, progettuale delle azioni stesse fa sí che dopo poche settimane dall’esame il discente non ricorderà gli argomenti trattati e non potrà costruire i collegamenti teorici necessari a formare il suo modello mentale della professione che andrà ad esercitare.

3. Esperienze sul campo

Per  mancanza di tempo,  ho utilizzato saltuariamente i package  REVIT e VASARI.;  ho seguito il corso nelle giornate del  sabato ed ho assistito allo sviluppo dei progetti iniziati dagli altri discenti;  ho constatato che gli strumenti di tutoring online ed offline disponibili sono validi.  Analogamente ad altri package, l’apprendimento è analogo a quello di una lingua straniera ossia la struttura a cipolla dei package permette di apprendere la gestione di un componente alla volta. I campi di applicazione sono molteplici: componenti architettonici, simulazioni dell’irraggiamento solare, dettagli delle strutture di facciata. La durata del corso è insufficiente (vedi  capitolo 4).

 

4) Pros e cons

I pros superano di gran lunga i cons.

Informare i discenti che nello sviluppo di un progetto si può evitare di stampare e far circolare chili  di disegni li rende edotti di un fatto banale ma spesso dimenticato dai docenti italiani delle facoltà di Architettura.  Leon Battista Alberti per comunicare le sue idee ai committenti doveva far costruire un plastico ed i committenti si fidavano del suo “modello mentale” poiché lo condividevano.  Alberti preparava disegni “di massima” per il capocantiere con il quale condivideva una conoscenza tacita che non doveva essere elencata nei disegni stessi (come si prepara lo spiccato delle fondazioni, come si ammorsano due muri ortogonali, come si dimensionano i conci di un arco, ecc).

 Il capocantiere risolveva tutti i problemi esecutivi ed i tempi necessari alla realizzazione del manufatto architettonico andavano da due anni per un piccolo manufatto ai 150 anni per grandi manufatti.  Nella nostra epoca è impossibile calarci nel modo di pensare di questi attori del passato in quanto i corsi universitari, nel mostrare i manufatti realizzati,  forniscono la falsa impressione che i disegni e le foto permettono di comprendere i manufatti architettonici stessi ed il loro ciclo costruttivo;  i docenti  pur sapendolo non informano i discenti che l’organizzazione del cantiere edile di Palazzo Farnese era diversa da quella del cantiere della reggia di Versailles, che a sua volta era diversa  dal cantiere attuale per la costruzione del nuovo Palazzo delle Esposizioni dell’EUR in Roma. Gli strumenti software per la progettazione parametrica incorporano i “knowledge bricks” usati dai diversi attori che lavorano nella catena esecutiva del manufatto architettonico.  E’ iniziata la nuova fase didattica dei corsi di architettura che rompe l’incantesimo dell’insegnamento dell’architettura stessa: la conoscenza tacita,implicita.

Una disciplina è caratterizzata sia dalla mole della conoscenza necessaria al suo funzionamento (misurabile in chili, ovvero il peso dei libri che ogni discente deve studiare) sia dalla sua percentuale di esplicitazione. Se una disciplina continua a conservare al suo interno un’alta percentuale di conoscenza implicita (per l’insegnamento dell’Architettura in Italia andiamo dal 70 all’80%) tale disciplina è condannata a scomparire in quanto non trasmissibile nell’arco di pochi anni, periodo attualmente assegnato dall’economia all’insegnamento universitario.

Obiettivo dei docenti avveduti delle facoltà di Architettura è diminuire il tasso della conoscenza implicita dall’80 al 30% , ove 30 è la stima della componente implicita massima di una disciplina accettata attualmente dall’economia (ad esempio medicina, economia, manifattura a ciclo continuo). Il corso relativo alle tecniche parametriche di progettazione è una componente essenziale di questa pacifica rivoluzione ed a mio avviso costituisce un prototipo che gli altri docenti dovrebbero utilizzare.

Esaminiamo ora i contra: durata del corso insufficiente, deboli legami con gli altri corsi, attrezzature didattiche insufficienti.  La durata del corso, attualmente da Ottobre e Gennaio, dovrebbe essere estesa da Ottobre a Giugno, prevedendo tre gruppi di lezioni: a) abbandono del disegno cartaceo ed uso del concept; b)  fondamenti di tecniche parametriche di progettazione; c) esempi applicativi nel settore forniture, urbanistica, architettura.  Durante il corso devono essere alternate “lezioni magistrali” con visite sul campo relative a cantieri edili, atelier, manifatture. Il docente dovrà essere affiancato da almeno tre tutor per seguire assiduamente i discenti.

I legami con gli altri corsi sono molto deboli e rivelano una scarsa sensibilità degli altri docenti nei confronti del corso di Tecniche Parametriche di Progettazione. Il Consiglio di Facoltà dovrebbe orientare il layout teorico dei corsi della Facoltà verso un approccio strutturale contemporaneo (non mancano esempi efficaci in altre Universitá  nel mondo). Per sopperire alla cronica carenza di attrezzature didattiche della facoltà di Architettura di Roma3 bisogna ricorrere a sponsor privati esterni; un positivo effetto collaterale di tale approccio è la rottura dell’isolamento fisico e culturale che attualmente affligge molte Università italiane.

5.  Conclusioni

Esaminerò lo scenario sociale-politico attuale in cui si colloca il lavoro degli urbanisti e degli architetti. Una disamina spassionata dello sviluppo urbanistico in Italia mi porta a rilevare come siano state ritirate le deleghe del monopolio urbanistico assegnate nel passato agli uffici tecnici dei Comuni, delle Regioni e dello Stato. La rottura del monopolio è avvenuta grazie al riconoscimento di potere decisionale dei developer e degli abitanti di un dato territorio. Ripeto che la decisione è stata una decisione democratica, ovvero sancita dalla maggioranza degli aventi diritto di voto.  Dato che ogni intervento urbanistico richiede una capace struttura organizzativa ed ingenti capitali finanziari carenti negli organismi istituzionali (Stato, Regioni, Comuni) questi ultimi hanno perso il monopolio degli interventi urbanistici. In altri ambiti la società riconosce ancora il monopolio statale: il monopolio statale del controllo della violenza (Polizia ed Esercito) e, anche se in misura meno incisiva, il monopolio della giustizia (la gestione inefficiente dei Tribunali ha prodotto una “giustizia fai da te”). Gli urbanisti che non accettano questo mutato scenario si comportano come gli aristotelici del tempo di Galileo i quali, invitati da Galileo a compiere esperimenti per verificare le teorie fisiche, si rifiutavano di partecipare agli esperimenti giudicando sufficiente leggere la teoria della Fisica sviluppata da Aristotele e riportata nei suoi testi. Strumenti urbanistici come i PRG sono inutilizzabili in quanto richiedono anni per la loro stesura e pretendono di normare per molti anni il territorio, con la presunzione che gli urbanisti posseggono la classica sfera di cristallo sufficiente a prevedere cosa avverrà nei prossimi 10/20 anni. La visione olistica di un PRG non è applicabile alla complessa e stratificata realtà contemporanea ed i suoi paradigmi (ad esempio la rete ecologica) sono inefficaci. Abbandonando lo strumento del PRG gli urbanisti saranno costretti a riprendere il contatto con le realtà del territorio di cui si devono occupare. 

Cosa fare ? I gruppi sociali ed i developer, anno dopo anno, in modo recursivo, sviluppano richieste (i primi) e trasformazioni del territorio atte a soddisfare le richieste (i secondi).  Il processo di attuazione, per motivi di efficienza economica, deve avere una durata limitata e marginalizza gli attori istituzionali deputati alle trasformazioni del territorio: gli urbanisti che lavorano nelle PA.  Le PA possono semplicemente inseguire quelle trasformazioni contrattando, da una posizione di debolezza, un compromesso con i developer. L’altra faccia della medaglia è costituita ovviamente dal fatto che i developer  investendo capitali e lavoro si attendono un ritorno con gli interessi dei loro capitali.  Tale scenario è stato accettato dai gruppi sociali in quanto non sono praticabili alternative, ovvero i poteri pubblici non sono stati e non sono in grado di soddisfare le richieste dei gruppi sociali (i tempi biblici per gli interventi da essi pianificati li hanno marginalizzati).

Che legame esiste tra le tecniche parametriche di progettazione e lo scenario appena descritto ? Gli urbanisti dovrebbero mandare in soffitta il 95% dei loro strumenti di lavoro e copiare la metodica dei medici. La medicina ha conosciuto uno sviluppo sbalorditivo delle proprie attività adottando un approccio opportunistico, tipo “frullatore”  ed abbandonando le discussioni teoriche sugli “umori che circolano nel corpo umano”  tipiche del ‘700. I medici sono stati responsabili delle trasformazioni urbanistiche che dal 1870 in poi hanno cambiato la città occidentale e non gli architetti che discettavano di decori ed ordini (facendo perdere tempo agli studenti nei corsi universitari delle Accademie di Belle Arti). Medici e ingegneri hanno riscritto le regole edilizie facendo rispettare i nuovi vincoli igienici, energetici, abitativi.  La medicina negli ultimi 150 anni ha utilizzato tutte le scoperte stimolate dallo sviluppo della chimica (nuovi farmaci), della fisica (diagnostica tramite TAC e NMR), biologia molecolare (trapianti), il tutto integrato in un quadro caratterizzato da efficienza ed efficacia. La medicina è una storia di successo in quanto le epidemie sono diminuite e la speranza di vita è aumentata considerevolmente.

L’urbanistica e l’architettura NON sono storie di successo, ne deriva l’imperativo di abbandonare i classici strumenti di lavoro (disegni, standard urbanistici, zone di rispetto, ecc.) e guardarsi intorno sfruttando le applicazioni delle altre discipline di successo (informatica, medicina, ecc.). Le tecniche parametriche applicate al progetto urbanistico sono facilmente applicabili, la latitudine del progetto discussa in precedenza deve costituire il risultato di un plot urbanistico che definisca cosa si può fare e cosa NON si può fare; gli standard  urbanistici sono inefficaci e costituiscono una gabbia interpretativa analoga a quella degli “umori nel corpo umano” che fu abbandonata senza alcun rimpianto dai medici nel XIX secolo.

 La cultura della condivisione della conoscenza ha fondato il WEB ed i blog,strumenti che obbligano gli urbanisti e gli architetti ad elicitare la loro conoscenza e renderla esplicita, condivisibile, criticabile, ovvero essi non devono “disegnare” le loro proposte ma devono definire i parametri che determinano le loro proposte.

Converso ha ossessivamente sottolineato l’importanza del blog quale strumento didattico di condivisione della conoscenza.  Concludo questa relazione con un semplice paragone che dimostra l’arretratezza dell’urbanistica e dell’architettura, arretratezza che spiega la non incisività degli urbanisti/architetti sulle trasformazioni del territorio.

Cosa fa un urbanista quando sviluppa un plot urbanistico per un concorso? Chiuso nel suo studio esegue schizzi e disegni, raccoglie spunti dai disegni di altri colleghi, nel migliore dei casi chiede consigli ad altri colleghi di cui riconosce le competenze. Alla fine del progetto presenta un gruppo di disegni allegando una relazione computistica (se richiesta).

Quando un chirurgo, specialista di un settore, esegue un intervento di successo, appena uscito dalla sala operatoria si mette al PC e descrive il suo intervento postando un messaggio ad un blog dedicato al settore medico di cui l’intervento fa parte: descrizione della malattia, sintomi del paziente, tipo di strumentazione usata, difficoltà incontrate risolte e non risolte, risultati ottenuti. Ovviamente il blog è frequentato da specialisti che condividono il suo linguaggio e la sua conoscenza, specialisti che leggono quasi in tempo reale il suo messaggio e quindi possono decidere di eseguire un intervento analogo cambiando in tempo reale la loro metodica chirurgica, inglobando i risultati e gli avvertimenti del loro collega e magari evitando di ripetere i suoi errori! Questa metodica di condivisione della conoscenza produce un formidabile sviluppo della medicina, uno sviluppo che rivoluziona ogni 5 anni interi settori della chirurgia.

Vogliamo iniziare a copiare la metodica del chirurgo usando la progettazione parametrica al posto del bisturi ?

Grazie.

 

 


Elena Valik - Aggiornamento copertura del 28.1.2011

Pagine

Theme by Danetsoft and Danang Probo Sayekti inspired by Maksimer