-
.
è possibile scaricare da internet un interessante documento riguardante un rischio che probabilmente non s'è tenuto in considerazione.
http://www.softing.it/sites/softing/files/...o_aist_saie.pdf
aggiungo un interessante documento riguardante alcuni aspetti descritti:
www.enerjy.com/blog/?p=198. -
ingwilly.
User deleted
Intervengo da ignorante di programmazione e spero di non dire cavolate.
Il diagramma di flusso citato nell'articolo dell arch. Spagnuolo è un ottimo lavoro fatto da Crisitano Bilello per sintetizzare tutte le possibili evenienze previste dalle NTC per gli edifici esistenti.
Portato come esempio di Loop complesso fa pensare che la norma sia impossibile da implementare, ma, come sappiamo, in quel loop c'è tutto, proprio tutto: Analisi lineari, non lineari, statiche, dinamiche con e senza spettro, progetto simulato, rilevo ed input dell'edificio etc.
Ora se si pensa di voler implementare il tutto come una sorta di grande fratello che decide tutto per noi allora l'impresa è ardua, se, invece, si implementano singoli pezzi coerenti in cui il programma arriva ad un risultato e passa la palla al progettista per decidere gli step successivi allora il lavoro è più semplice e meno soggetto ad errori di macchina.
Non conosco il motivo per cui sia stato scelto quello come esempio (forse solo perchè se si volesse implementare il tutto in automatico il software avrebbe problemi), ma non penso che un software debba fare tutto sostituendosi al progettista.
E' questo il punto fondamentale della programmazione con le NTC: cercare di progettare tutto premendo un bottone non è possibile ed è anche poco gratificante per chi di mestiere fa' ancora l'ingegnere.
Le SWH dovrebbero sforzarsi di capire a quale punto fermarsi per lasciare la possibilità al progettista di decidere come andare avanti e quale strada percorrere, questa ricerca affannosa del tutto in uno non è perseguibile con modelli complessi; meglio tanti pezzi fatti bene e comunicanti che, poi, lascino al progettista la possibilità di decidere.
Willy
. -
.
io invece non penso ci sia nulla di poco gratificante qualora al progettista si lasci la scelta dello schema, la scelta di come far muovere il sw e il controllo di ciò che il programma ha fatto!
faccio un telaio con 4 pilastri od uno con 6?
mi sta bene che le staffe siano a 2 o a 4 bracci ma più rade?
i risultati finali corrispondono a quello che ho fatto con dei schemini semplificati?
////////////////////////////////////////////////////////////////////
riguardo invece il ragionamento delle concatenazioni occorrerebbe fare qualche distinzione:
è evidente che un programma complesso sia maggiormente soggetto ad errori di uno semplice, ma esiste anche un'altra questione: anche lo stesso progettista, oggi, è colpito da una progettazione più complicata e quindi più soggetta ad errori.
Quindi, a meno di non procedere in maniera anarchica.... occorre imbattersi in una bella gara di tiro alla fune tra progettista e programma di calcolo.
In seguito al cambio di norma, se il programma di calcolo non si sposta o si sposta di poco, vorrà dire che è il progettista ad assumersi la responsabilità degli errori.
Alla fine quindi il risultato non cambia.
L'unica cosa che noto è che mentre un programma può essere affinato fino al limite d'eliminare gli errori, agendo sul singolo progetto s'affinerà sè stesso e nulla più..
In pratica se tutti insieme gli utenti producono N progetti, conviene agire sul programma o sugli N smanettamenti dei singoli progetti?.... -
zax2010.
User deleted
io invece non penso ci sia nulla di poco gratificante qualora al progettista si lasci la scelta dello schema, la scelta di come far muovere il sw e il controllo di ciò che il programma ha fatto!
faccio un telaio con 4 pilastri od uno con 6?
mi sta bene che le staffe siano a 2 o a 4 bracci ma più rade?
i risultati finali corrispondono a quello che ho fatto con dei schemini semplificati?
////////////////////////////////////////////////////////////////////
riguardo invece il ragionamento delle concatenazioni occorrerebbe fare qualche distinzione:
è evidente che un programma complesso sia maggiormente soggetto ad errori di uno semplice, ma esiste anche un'altra questione: anche lo stesso progettista, oggi, è colpito da una progettazione più complicata e quindi più soggetta ad errori.
Quindi, a meno di non procedere in maniera anarchica.... occorre imbattersi in una bella gara di tiro alla fune tra progettista e programma di calcolo.
In seguito al cambio di norma, se il programma di calcolo non si sposta o si sposta di poco, vorrà dire che è il progettista ad assumersi la responsabilità degli errori.
Alla fine quindi il risultato non cambia.
L'unica cosa che noto è che mentre un programma può essere affinato fino al limite d'eliminare gli errori, agendo sul singolo progetto s'affinerà sè stesso e nulla più..
In pratica se tutti insieme gli utenti producono N progetti, conviene agire sul programma o sugli N smanettamenti dei singoli progetti?...
Non c'ho capito nulla.
Riguardo al tema.
Facciamo tutti noi una retrospettiva tornando indietro a 3 anni fa, quando per la prima volta abbiamo letto le NTC.
Quanti erano gli interrogativi? Tanti, tantissimi, troppi.
Chi di noi (intendo professionisti normali, di 'periferia') aveva mai letto gli EC?
Non mi dite che in questi tre anni non se ne siano diradati parecchi.
Chi afferma che sia rimasto tutto buio, e così sembrerebbe dalla lettura del documento dell'arch Spagnuolo, afferma solamente che non ha voluto capire meglio, non ha voluto chiarirsi le idee, non ha voluto rimettersi in gioco con le nuove regole.
Se si fosse trattato di un singolo professionista, poco male. Semplicemente non affronterà più la parte di progettazione strutturale.
Un softwarehouse? Anche. Avrebbe potuto fermarsi.
Seppur con una 'lentezza' che contrasta con i banner pubblicitari tante softwarehouse stanno arrivando al risultato. Piena rispondenza ai dettami delle NTC per gli edifici nuovi, e iniziative promettenti per gli edifici esistenti.
Ovvio, bisognerà vedere se quanto sbandierato è vero e se quanto implementato è condiviso. Ma mi pare che lo sforzo ci sia.
Insomma altri ci stanno sbattendo le corna, con questa pretesa complessità, e pare stiano riuscendo.
Certo se si sta fermi a guardare, le cose non si semplificheranno mai.. -
.
provo a tradurmi:
a dispetto di quanto dice ingwilly, io penso che un programma di calcolo dovrebbe lasciar poco margine di manovra all'utente.
l'utente agisce all'inizio definendo quello che vorrebbe (es. dire la sua preferenza tra staffe a due bracci fitte o staffe a 4 bracci rade?....), ma poi è il programma a condurre il progetto da solo (sempre riferendosi all'esempio precedente, se voglio le staffe a 2 bracci, non vorrei che la mancanza di questo settaggio mi costringa ad editare elemento per elemento.).
il motivo per cui vorrei questo è legato al fatto che ritengo che d'un progetto si possano avere MENO errori qualora si possa usare un qualcosa di predefinito che lavori con decisioni prese una tantum (quindi con la dovuta calma).
trasversalmente il problema pare diventare quello della complessità del codice del programma. quello che mi chiedo però è se realmente convenga affidare le novità normative tutte sul singolo utente piuttosto, appunto per quello che dicevo prima, che ad un programma.
provo a spiegarmi anche con uno schemino.
sia questo un iter progettuale interamente gestito da un utente (si fa i conti a mano, si fa gli elaborati)
- : intervento dell'utente.CODICEinizio------------------------------------------------------------>fine
e sia questo un iter progettuale per arrivare allo stesso obiettivo, ma con l'ausilio d'un programma
- : intervento dell'utente.
= : intervento del programma.CODICEinizio--------------------====================-------------------->fine
in cui ogni trattino/doppio trattino simboleggia un ipotetico step dell'iter progettuale,
supponendo che il programma lavori senza fare errori, voi di quale iter vi fidate di più?
non vi fidereste forse "ancor di più" di quest'altro iter?CODICEinizio--------------------========================================>fine
il motivo è semplice: l'attività umana è suscettibile a più errori di quella di un programma.
va notato che
nella nostra professione però l'attività umana è indispensabile per DIFFERENZIARE i progetti l'uno dall'altro
E che in realtà i programmi di calcolo SONO soggetti ad errori.
Ma per quest'ultimo fatto ci vengono in aiuto DUE cose (a cui se ne aggiunge una terza):
1. Lo STAFF di un programma di calcolo ESISTE per lavorare al fine di ridurre gli errori.
2. Secondo la normativa, AL PROGETTISTA SPETTA questo:
Affidabilità dei codici utilizzati
Il progettista dovrà esaminare preliminarmente la documentazione a corredo del software per valutarne l’affidabilità e soprattutto l’idoneità al caso specifico. La documentazione, che sarà fornita dal produttore o dal distributore del software, dovrà contenere una esauriente descrizione delle basi teoriche e degli algoritmi impiegati, l’individuazione dei campi d’impiego, nonché casi prova interamente risolti e commentati, per i quali dovranno essere forniti i file di input necessari a riprodurre l’elaborazione.
Ciò vuol dire che è nella fase preliminare di ogni singolo progetto che il progettista deve valutare se poi il programma è affidabile o no, inoltre egli è comunque sempre tenuto a verificare con proprie valutazioni semplificate la bontà dei risultati.
3. Tra due programmi ritenuti entrambi affidabili, il progettista EVIDENTEMENTE sceglierà quello che gli semplifica più la vita!
E se questa SUA vita semplificata ha come prezzo quello di dover scegliere un programma con una complessità ciclomatica maggiore, egli sceglierà quest'ultimo!
Anche perchè non è scritto da alcuna parte che un programma complesso contenga più errori / errori più pesanti d'un programma semplice: tutta questa discussione infatti parte sempre dal ragionamento che più un programma è complesso e più E' PROBABILE che abbia errori, MA APPUNTO non è poi detto che li abbia!
Edited by Massimo.T - 17/10/2011, 17:38. -
ingwilly.
User deleted
Massimo scusami, ma non ci ho capito niente e se ho capito non sono d'accordo con te.
Semplicemente dicevo che non puoi implementare tutto facendo solo una scelta all'inizio, il caso degli edifici eistenti tra l'altro è proprio il più calzante ed il meno calzante dal punto di vista di chi pensa di essere costretto dalle norme ad implementare un albero complesso.
Che facciamo: inseriamo il rilevo e poi il programma fa la sua valutazione con il metodo più conveniente?
Oppure decidiamo noi un metodo e procediamo? A quel punto se il metodo non è adatto (per norma) il programma si ferma e ti dice che la cosa non va bene, tu in base alla valutazione dei risultati passi ad altro. O ancora il programma arriva alla fine senza segnalare controindicazioni normative, tu guardi i risultati e decidi che il metodo che hai scelto all'inizio non ti va bene (sarebbe proprio il caso delle analisi non lineari).
Perciò quell'albero, lasciando al progettista la facoltà decisionale intermedia, sarà segato in molti rami e non si avrà più la complessità irrrisolvibile.
Naturalmente questo vale anche per edifici nuovi.
Immagina di aver progettato una struttura che, facendo l'analisi modale, si rivela deformabile torsionalmente. Tu invece di andare avanti senza criterio e beccarti un bel "2" decidi di modificare la struttura e di tentare di rientrare in un schema non deformabile torsionalmente, perciò sei sempre tu progettista che valuti la procedura e, ad un certo punto del suo iter, e decidi se e come andare avanti.
Willy. -
.
Non ho fatto riferimenti a nuovo o esistente, perchè secondo me dovrebbe essere un'idea di fondo.
condivido quello che dici se intendi togliere al programma le scelte soggettive. il programma non deve sostituirsi, ma può essere istruito per scegliere.
portando avanti il tue esempio della struttura deformabile torsionalmente: penso che un bell'obiettivo possa essere quello di avere un settaggio che dica "se risulta deformabile torsionalmente proseguo o interrompo?".
Viceversa non vorrei un programma che non mi sbandiera che la struttura in esame è deformabile torsionalmente e io distrattamente ("pensavo d'averlo fatto prima, poi ho ricevuto una telefonata....blablabla") non ne vengo a tener conto!
Se tutti i punti sono implementati, avrò un valido sostegno dal programma. Se il programma non sa quello che deve fare, ma sono io a doverglielo dire tutte le volte, può capitare che qualche volta non glielo dico.. Questo non vorrei che capiti!
Infine, il tema delle strutture esistenti è quello più complesso in quanto oltre a contenere tutte le nozioni sul nuovo, ne contiene anche delle altre (riguardanti l'esistente) che sono sia di carattere prestazionale e sia di carattere prescrittivo (basti pensare ad un ampliamento d'un esistente: occorre trattarlo come "nuovo", ma anche come esistente..).
Le nozioni prescrittive non danno adito a dubbi: qualora servano occorre applicarle per come sono scritte!
es. se mi sono INFOGNATO in una analisi statica lineare con spettro elastico di una struttura in CA (perchè il metodo mi piace/perchè il programma dichiara di averlo implementato/quello che vuoi) il calcolo dei vari rho_i non può che essere coincidente con quello chiesto dalla normativa
Invece quelle prestazionali (come ad es. la scelta del metodo/la scelta del LC e ciò che esso comporta/....) devono essere informazioni che ovviamente devi dare strada facendo (o preferibilmente all'inizio, usate poi all'occorrenza)
Edited by Massimo.T - 17/10/2011, 17:42. -
zax2010.
User deleted
Caro Massimo l'equivoco, e la mia incapacità a capirti, nasce dal fatto che tu e Willy in definitiva dite la stessa cosa. Willy afferma: E' questo il punto fondamentale della programmazione con le NTC: cercare di progettare tutto premendo un bottone non è possibile ed è anche poco gratificante per chi di mestiere fa' ancora l'ingegnere.
E tu rispondi invece:io invece non penso ci sia nulla di poco gratificante qualora al progettista si lasci la scelta dello schema, la scelta di come far muovere il sw e il controllo di ciò che il programma ha fatto!
Insomma sembra che tu voglia contraddire Willy, pur sposando completamente la sua tesi (che è anche la mia, per inciso). Ma quindi di cosa stiamo parlando?
Ma per tornare al discorso dell'arch Spagnuolo, sembra egli affermare, che poichè la normativa è complessa e dunque condurrebbe a procedure informatiche assai complesse, e proprio per questo potenzialmente poco affidabili, allora tanto vale......non programmare affatto.
(Faccio anche presente che la normativa complessa di cui si parla non sono le NTC di stretto ambito di applicazione italiana, ma in effetti gli EC, di respiro ed applicazione molto più ampia, e da cui le NTC derivano).
Detto da una persona qualsiasi, l'accetto. Da un programmatore, scusatemi, non posso.
Perchè la mia risposta può essere una sola (seppur irrispettosa ed ingloriosa): "perchè non chiudi baracca e burattini, allora?". -
.Caro Massimo l'equivoco, e la mia incapacità a capirti, nasce dal fatto che tu e Willy in definitiva dite la stessa cosa. Willy afferma:E' questo il punto fondamentale della programmazione con le NTC: cercare di progettare tutto premendo un bottone non è possibile ed è anche poco gratificante per chi di mestiere fa' ancora l'ingegnere.
E tu rispondi invece:io invece non penso ci sia nulla di poco gratificante qualora al progettista si lasci la scelta dello schema, la scelta di come far muovere il sw e il controllo di ciò che il programma ha fatto!
Insomma sembra che tu voglia contraddire Willy, pur sposando completamente la sua tesi (che è anche la mia, per inciso). Ma quindi di cosa stiamo parlando?
io dico che quel bottone ESISTE!
esiste e rende il mio progetto differente al tuo perchè a monte ci stanno una serie di presettaggi personali.
questi presettaggi portano ad allestire un modello/ottenere un risultato differente partendo dal medesimo architettonico.
ripercorrendo uno spunto citato, può essere che ad es. ingwilly preferisca regolarizzare la struttura, mentre io accetto più facilmente le strutture deformabili torsionalmente.. i risultati sono differenti (ad es la mia struttura costa di più, ma la sua ha i pilastri più grandi... o viceversa, perchè non è scritto da nessuna parte che le cose si comportino sempre al medesimo modo).
ciò che è certo è che le strutture quindi rispettano i dati a monte e per "eseguire" la procedura basta un click.
io penso che un ingegnere sia maggiormente gratificato se il risultato ottenuto lo rispecchia, più che riesca a raggiungerne almeno uno..Ma per tornare al discorso dell'arch Spagnuolo, sembra egli affermare, che poichè la normativa è complessa e dunque condurrebbe a procedure informatiche assai complesse, e proprio per questo potenzialmente poco affidabili, allora tanto vale......non programmare affatto.
(Faccio anche presente che la normativa complessa di cui si parla non sono le NTC di stretto ambito di applicazione italiana, ma in effetti gli EC, di respiro ed applicazione molto più ampia, e da cui le NTC derivano).
Detto da una persona qualsiasi, l'accetto. Da un programmatore, scusatemi, non posso.
Perchè la mia risposta può essere una sola (seppur irrispettosa ed ingloriosa): "perchè non chiudi baracca e burattini, allora?"
faccio anche presente che il ragionamento che faccio è evidentemente molto prossimo all'utopia.
è evidente che l'utente dovrà sempre e comunque fare qualcosa in più d'un semplice click!!
ma, per me, è altrettanto evidente che quella è l'unica direzione valida per un sano e valido sviluppo di un programma (di calcolo/di scrittura/...).
se si perde l'obiettivo di SEMPLIFICARE sempre più la vita all'utente: cosa può spingere l'utente ad aggiornare ulteriormente il programma?
quindi non m'aspetto che si realizzi l'utopia, ma quantomeno m'aspetto che si tenda a inseguirla.. -
.
faccio notare che i "numeri" di all in one contengono questo:
179,703 La complessità cicomatica secondo McCabe
ma per loro non erano già troppi 11?. -
ingwilly.
User deleted
Per chi fosse interessato riporto la pagina dei link a tutti gli interventi del convegno AIST
www.aistonline.it/page.asp?id=Download_Convegno2011
Willy.
[softing] Normativa ed informatica: un matrimonio difficilearch. Roberto Spagnuolo |
