Newsgroup: it.discussioni.ingegneria.civile
Titolo: Lettera aperta

Il mio newsreader si è perso il messaggio della Softing relativo alla
lettera aperta al presidente del consiglio, sulla nuova normativa a
cui volevo fare un Reply.
Questa mia, ovviamente, solo per dire che condivido pienamente e al
massimo posso pentirmi di non averla fatta per primo :-)
Cordiali saluti al nws,
Ing. B.Daddi
Tecnisoft s.a.s
www.Tecnisoft.it


nel caso volessi ripescarla su google
Comunque puoi anche andare in google gruppi ed entrare nel gruppo
it.discussioni.ingegneria.civile e impostare da li' la ricerca.
Come autore basta mettere Roberto Spagnuolo
-- 
Ciao da Francesco B.

 
Egregio Ing. Daddi,
non è tanto importante, in questo caso, "essere i primi". E'
importante esserci e, preferibilmente, tutti insieme. Infatti si
tratta di difendere la propria professionalità e, questa volta, mi
pare, anche la logica e l'ingegneria italiana. Quindi Lei è sempre in
tempo per intervenire ufficialmente. Colgo anzi l'occasione per
ribadire che tutti gli ingegneri dovrebbero far sentire la propria
voce. Qui si sta giocando sul loro e nostro futuro. Da parte mia ho
sempre desiderato una tavola rotonda tra le software house in quanto
esistono problemi comuni che avrebbero migliore soluzione in un
confronto e che, anche nel caso attuale, darebbe maggior forza ai
nostri punti di vista.
I miei migliori saluti
Roberto Spagnuolo

e' datata 03/02/2005
Non mi ero spiegato.. era solo per spiegare come mai aprivo un nuovo
thread invece di fare Reply a quello originale..


nostri punti di vista.
Non posso non darle ragione, e se ricordera' avemmo tempo fa occasione
(non ricordo piu in quale fiera ervamo), con altri nostri colleghi di
affrontare la necessità di presentarsi uniti anche per altre
questioni. Purtroppo sa bene che non tutti ci sentono da questo
orecchio e spesso ognuno cerca solo di coltivare il proprio orticello
e vive la giusta concorrenza di mercato come una specie di guerra. 
Tornando al punto della sua lettera, sembra che i nostri legislatori
pensino che gli ingegneri progettino ancora con il regolo calcolatore
e tirano fuori delle prescrizioni che risentono ancora dei calcoli "a
telai" e che sono assurde e diffcilmente implentabili nei nostri
sowtware.
Purtroppo credo che il software di ingegneria sia ancora considerato
come una specie di "calcolatrice evoluta" e non quello che è diventato
di fatto in molti casi: un meta-ingegnere che con le sue scelte di
fondo condiziona ed indirizza il lavoro degli utenti. 
Credo che io, lei ed i nostri (pochi) colleghi, abbiamo "idealmente"
firmato milioni di metri cubi di costruzioni in tutta   Italia, ma le
bozze di normativa vengono poste all'esame solo degli uffici
regionali, e si vengono a conoscere solo per vie traverse, quando
dovrebbero venire fatte circolare e poste al vaglio della comunita'
per mesi e mesi.!
Speriamo che le cose migliorino in futuro
Cordialmente


 
www.Tecnisoft.it
Egregio Ing. Daddi,
confesso che ho molte remore ad aprirmi a un dialogo perché nel nostro
mondo c'è, come lei giustamente dice, molta "guerra" che talvolta
sfocia, aggiungo, in veri comportamenti asociali.
Però sono molto tentato da questo nostro fortuito incontro "pubblico".
Infatti anch'io ho spesso sperimentato dialoghi a due dove si sostiene
sempre che sono "gli altri" a non voler partecipare. Visto appunto che
questo è un dialogo davanti a un pubblico, forse sarebbe interessante
sapere chi è che "non ci sente". Sottolineando bene una cosa per chi
ci legge. E cioé che un discorso serio e partecipato sul software per
ingegneria è soprattutto nell'interesse dell'ingegneria e che chi "non
ci sente" fa un pessimo servizio proprio ai propri stessi clienti.
Non so i mezzi per condurre un simile dialogo specifico sui problemi
deontologici e di categoria, più che tecnici, del software per
l'ingegneria, che sono tanti e importanti. Forse un forum o un
newsgroup dedicato? Sarebbe interessante. Infatti da una parte credo
che certe posizioni troppo "personalistiche" di alcuni produttori
emergerebbero nella giusta luce e dall'altra parte finalmente si
avrebbe un chiaro punto di vista anche dell'utilizzatore che oltre a
lamentare, più o meno giustamente, carenze nel lavoro di noi tutti,
non ha mai occasione di esprimersi, e di ascoltare opinioni, sulle
linee generali.
Un saluto cordiale
Roberto Spagnuolo
Softing srl

Però sono molto tentato da questo nostro fortuito incontro "pubblico".
Vi propongo di iniziare dalla realizzazione di  alcuni "benchmark"
molto semplici che possano essere risolti e controllati a mano (nel
vero senso della parola).
In tal modo secondo me si inizierebbero a vedere da subito alcune
caratteristiche di base dei software, tra cui:
1) se tengono conto dell'effettivo scarico a trave continua dei solai
o se funzionano a zone di carico;
2) se l'aderenza e' ben calcolata e se si tiene conto di zone buone e
cattive;
3) se si esegue il calcolo del ferro in estremita' che assorbe tutta
la reazione a taglio (e che sia ben ancorato per poterla ben
assorbire, qindi con lunghezze adeguate);
4) se i nodi di un semplice telaio piano (due pilastri e una trave)
hanno i ferri prolungati adeguatamente nelle travi e nei pilastri in
modo da effettivamente assorbire il momento di incastro o se
l'armatura e' interrotta troppo presto;
5) se ed in che modo si esegue l'alternanza degli accidentali
(scacchiera);
5) mi verra' in mente qualcosa altro..., ma voi sicuramente sapete
meglio di me molte altre cose... :-)
Tali benchmark potrebbero essere proposti da voi o da professionisti,
anche tra i vostri clienti, o da istituti universitari, ma dubito che
molte software house li adotterebbero, dato che sembra che l'ambiente
rifiuti di ammettere che ogni software per quanto fatto bene e
completo, ha sempre dei limiti (e cio' non e' male, basta che siano
ben noti), e ogni software ha limiti diversi dagli altri.
  Ciao
Filippo B.
--------------------------------------
Per rispondere anche via e-mail eliminare   '_RIMUOVIMI_'   e   '.invalid'
dall'indirizzo.
To reply also by e-mail, cancel   '_RIMUOVIMI_'   and   '.invalid'
from the address.
--------------------------------------

...

Rispondo a Francesco B che mi consente di spiegare meglio il mio punto
di vista.
L'informatica ha modificato molte abitudini. E' un fatto "culturale"
e, se vogliamo, "politico". Entro questa grande cornice si possono
affrontare anche temi tecnici.
Il problema del rapporto tra informatica e ingegneria è a mio avviso
tuttora irrisolto e non nei termini tecnici cui Francesco B fa
riferimento, ma negli aspetti dei ruoli, degli spazi, delle
competenze, delle responsabilità.
Questo è il tema importante che spesso viene "offuscato" dall'amore
per certi tecnicismi che sono abbastanza marginali se si risolvesse il
quadro d'insieme. Per questo sarebbe a mio avviso opportuno, come
accennavo nella risposta all'Ing. Daddi, dare un maggiore spazio a
questi temi generali.
Venendo alla sua proposta. Lei sa bene che benchmark esistono, che
molti programmi sono dotati di un manuale di validazione e che quindi
non è questo il problema.
Il problema, restando nel suo esempio dei benchmark, è che dovrebbe
essere il "committente" a proporli (cioè le organizzazioni di
categoria dei progettisti) non le software house.
Forse i progettisti, a differenza di altre categorie, non ritengono
che le "specifiche" siano necessarie perché le ritengono codificate
nelle norme e nella scienza delle costruzioni. Ma così non è. La
opinabilità della norma, i suoi errori, la necessità di
un'interpretazione l'abbiamo sotto gli occhi da quando è stata
proposta la famosa "Ordinanza". Che le specifiche siano implicite
nella scienza delle costruzioni non è altrettanto vero perché i modi
di impiegare i metodi della scienza per le esigenze di una categoria
professionale devono essere accuratamente valutati e non sono frutto
di deduzioni ovvie.
Purtroppo anche gli  interlocutori istituzionali, che in altri Paesi e
in altri settori si comportano con un utile spirito di collaborazione,
 in questo caso sono "contro" chi fa software, basti leggere  la
lettera del presidente dell'Ordine degli Ingegneri di Firenze
(
http://www.rete.toscana.it/sett/pta/sismica/class_materiale/nota_ordingfi_240105.pdf
)
che ha la delicatezza di affermare che "i programmi in commercio non
forniscono alcuna garanzia sulla reale affidabilità dei loro
algoritmi".  Tutti, naturalmente, senza neanche  un aggettivo per
mitigare o suggerire una possibilità di sfumature. Non offrono
garanzie. Con affermazioni di tale non conoscenza e considerazione per
il lavoro altrui non si va lontano.
Finché non ci sarà la figura di un serio "committente" come
controparte delle software house il discorso sarà necessariamente un
monologo.
Roberto Spagnuolo
Softing srl
PS. Al Presidene dell'Ordine di Firenze ha molto opportunamente
risposto l'Ing. Luciano Migliorni di AMV. Sarei lieto rendesse
pubblica tale lettera. Con l'occasione mi ha anche informato che AMV
condivide la mia posizione espressa in questo newsgroup. Quindi anche
AMV "ci sente" e ne sono lietissimo perché sinceramente stimo questi
colleghi.

                    Il 24 Feb 2005, 09:25, Filippo B. <bon8@_RIMUOVIMI_libero.it.invalid> ha
scritto:

Ho l'impressione che si stiano pericolosamente confondendo i ruoli: le
specifiche su cosa dovrebbero fare i software le devono compilare gli
utenti, come comunità, NOI ! Dopo che ci siamo chiariti *bene* su quello che
vogliamo, possiamo presentare le specifiche alle software house.
L'idea che sia una università a presentare le specifiche mi fa semplicemente
raggelare.
Tutte le software house hanno una serie di consulenti o un gruppo di utenti
più o meno esperti a cui fanno riferimento. Si potrebbe forse dire che il
loro campione non ci rappresenta. Ma del resto io avrei messo in cima
all'elenco aspetti molto differenti da quelli (pur sacrosanti) da te citati.
Eppure il tuo "benchmark" può essere molto utile: condiviso, discusso,
esteso potrebbe diventare un vademecum su come valutare un software di
calcolo. Penso che ne gioveremmo tutti e potrebbe fornire una valida
indicazione per le softwarehouse.
Saluti,
TLW
--------------------------------
Inviato via 
http://arianna.libero.it/usenet/

colleghi.
Mi associo sia alla richiesta di rendere pubblica la lettera sia nella
stima verso i cordiali e corretti colleghi della AMV.


 paura a mettere nelle loro mani i ns. software.
Vero. Attenzione però: non vi sarà garanzia, ma in caso di danni e/o 
disastri il prof. deve risponderne di fronte al giudice !!!
E pagare e/o andare in gattabuia!
E comunque, se previdente, per il civile si è magari assicurato pagando un 
fior di premio annuale (che la swhouse NON paga perchè si chiama 
immediatamente fuori nel contratto di licenza, dichiarandosi NON 
responsabile di qualsiasi guaio), ma per il penale non c'è assicuratore che 
vada in galera per lui !
Se il danno è causato in conseguenza dell'impiego di sw bacato, chi ha 
compilato e venduto detto sw al massimo porterà le arance al prof. al 
fresco, ma non ne a vrà alcun nocumento.
E' qui la grave differenza: a parità di inaffidabilità il venditore va in 
ferie con i soldi che il professionista gli dato per stare (il 
professionista) in galera.
Non è una differenza da poco mi sembra ...
ciao
e.

...

Egregio Ing. Daddi,
torno allo scopo iniziale di questo scambio di messaggi. La Softing ha
concordato con AMV un documento comune che intende puntualizzare il
ruolo delle software house soprattutto nei confronti di questa nuova
normativa e del modo in cui viene redatta. Preannuncio in questa sede
questa iniziativa, non come comunicazione privata, ma perché credo sia
di generale interesse. Il comunicato sarà proposto a breve a tutte le
software house del settore che, se lo riterranno opportuno, potranno
sottoscriverlo e pubblicarlo nel loro siti.
Il testo le verrà inviato dall' Ing. Migliorini al suo indirizzo
privato "in anteprima", vista la sua partecipazione a questi problemi.
Un cordiale saluto
Roberto Spagnuolo

privato "in anteprima", vista la sua partecipazione a questi problemi.
Gia' arrivato, gia' risposto.. concordo pienamente.. a risentirci


fresco, ma non ne a vrà alcun nocumento.
Io credo che i ns. software (credo di poter parlare anche a nome dei
miei colleghi) non abbiano sicuramente dei "bachi " cosi macroscopici
da provocare crolli o danneggiamenti, e se li avessero un
professionista competente li individuerebbe al volo. Immaginate che vi
venga un armatura di 2 fi 12 in una trave in spessore di 6 metri
potrante due solai....
Ovviamente i sf sono non esenti, ma PIENI di bachi, ma in genere sono
del tipo "se la trave è cosi' o cosa' con un pilastro messo storto in
questo modo, la quota dell staffa...." oppure "si inchioda se faccio
un calcolo dinamico e sono contemporanemante presenti delle bielle che
si attaccano a travi su suolo elastico..."  (sto inventando
ovviamente). 
Quando un software si inchioda il problema salta subito all'occhio e
si risolve. Quando commette delle imprecisioni non crolla nulla. 
Quando pero' mi arriva un modello in cui una trave su piu' campate è
collegata solo al primo ed all'ultimo nodo ed è "passante" sui nodi
dei pilastri intermedi allora mi preoccupo, specialemente sentendo
dire "Ma graficamente si vedeva che passava di li..". Dove sta una
MINIMA conoscenza dei metodi FEM in chi ti da' una risposta cosi?
Il concetto di nodo ed elemento? 
Non per difendere la categoria, ma anche perchè (come dice giustamente
anche l'Ing. Spagnuolo)  non venga sottovalutata.


 
www.Tecnisoft.it
ciao :)
e. 

e. 
Beh.. ognuno difende la propria categoria.. mi fa cmq piacere la
faccina... :-)


 ha scritto nel 
messaggio news:42282ee2...@news.mclink.it...

ma io non sto difendendo la mia, sto attaccando la tua!   :DDD
ciao e buon lavoro!
e. 

mi intrometto nel discorso dando ragione e torto ad entrambi (almeno
dal mio punto di vista).
Ritengo che ad oggi i programmi di calcolo strutturale non sono
soggetti ai problemi citati in precedenza per il fatto che tutti o
quasi tutti si appoggiano a solutori esterni con decenni di storia
alle spalle (e sono secoli in termini informatici, xfinest microsap
solo per citarne un paio).
Anche se cosě non fosse, la parte di codice relativa'analisi č forse
la parte piů facile da scrivere se non altro perchč esistono tecniche
di convergenza dell'algoritmo che permettono di raggiungere la
soluzione e SOLO la soluzione esatta (+ o - č cosě anche se
bisognerebbe dire un mucchio di altre cosi) e poi per il fatto che
questa parte di codice non č soggetta a nessuna normativa ma solo alla
sana scienza delle costruzioni.
I problemi ci hanno quindi nei pre e post processori e sono dei
problemi subdoli per il fatto che molti sono difficilmente visibili.
E poi c'č il problema della normativa come dicevo che lascia ai
progettisti e in questo caso alle software house delle scelte
importanti.
In tutto questo perň il comportamento delle software house che fanno
pagare gli aggiornamenti per correggere gli errori di progettazione č
una cosa che definirei scandalosa
In ultimo un ringraziamento particolare va all'Ing. Daddi e all'Arch.
Spagnuolo che si dimostrano presenti e attenti ai problemi dei
progettisti, oltre che naturalmente ai loro interessi.
(forse sarebbe meglio aprire un nuovo NG perchč siamo usciti un po'
fuori tema)

importanti.
[...]
Era quello che intendevo io quando proponevo dei benchmark (ovvero dei
test studio risolvibili mano, per controllo).
Infattti e' vero che esistono tantissimi test di validazione e che
alcuni programmi li includono nei manuali, ma tali test riguardano la
bonta' della soluzione numerica FEM, che pure e' importante.
Nulla si verifica mai sulla corretta implementazione, soprattutto nei
post-processori, di TUTTE le prescrizioni normative di dettaglio e di
verifica.
Tante prescrizioni, infatti, (tipo il passo minimo delle staffe
vincolato a una frazione dell'altezza utile, gli ancoraggi etc.)
talvolta sono disattese. Come pure trascurate sono magari le verifiche
agli SLE per tutti i casi (frequente, semi-permanente etc.), che
possono sembrare pedanteria.
Puo' sembrare eccessiva pignoleria, ma non vedo perche', dato che la
procedura di verifica e' AUTOMATICA, si debba prescindere da alcune
prescrizioni.
Sara' poi il progettista che decide di cambiare un po' gli esecutivi,
ma quest'ultimi dovrebbero soddisfare appieno a TUTTE le prescrizioni.
Si paga per quello, o no?
Altrimenti serve una lista CHIARA che dica: il post-processore
verifica: tensioni sui materiali in determinate sezioni, gli
ancoraggi, si', il passo minimo delle staffe, comprese le zone di
forze concentrate si' (o no, dipende), il passo minimo dei bulloni
si', la distanza minima dei bulloni dai bordi no etc etc.
Come dicevo, pero', la categoria delle software house, alcune molto
serie, deve comunque vivere e spesso fa comodo non dire alcune cose,
dato che alla maggior parte dei professionisti il programma serve a
dare "sicurezza" e pertanto non puo' che essere venduto come
"completo" (o almeno sembrarlo).
  Ciao a tutti


...

Una piccola osservazione perché sono molto colpito dal rapido viraggio
di questo filone di discusione aperto da me con il semplice l'annuncio
della mia lettera al Presidente del Consiglio sul caos normativo.
Infatti in pochi scambi si è "ricaduti" nella trita ideologica
contrapposizione progettista-software house. Contrapposizione che a
mio avviso non esiste ed è frutto solo della mancanza di un dialogo
aperto o, meglio, di rappresentanti di categoria che vogliano
affrontare un dialogo aperto.
In merito al discorso quindi non entro perché sono convinto che se non
si fa prima chiarezza di ruoli questo resta un discorso tra persone
che, forse dicono la stessa cosa, ma parlano lingue diverse.
Ma quello che mi colpisce è il sistematico rifugire dal voler prendere
atto di problemi generali più ampi, non ultimo quello di una normativa
scritta sulla pelle di tutti noi senza consultarci, problemi che, a
mio vedere, sono molto più gravi e con ripercussioni molto più ampie
sul lavoro di noi tutti di quanto non siano aspetti tecnici che, tra
tecnici, troverebbero sempre una soluzione soddisfacente per tutti se,
ripeto, si affrontassero PRIMA i problemi generali del contesto e dei
ruoli. Ne traggo quasi l'impressione che la citata "contrapposizione"
sia un rifugio psicologico per non affrontare questioni a monte molto
più serie. Mi piacerebbe conoscere delle opinioni sui motivi di questo
diffuso "disinteresse" per quello che, in ultima analisi, si potrebbe
dire l'aspetto "politico" (in senso lato) del proprio ruolo e della
propria professione.
Roberto Spagnuolo
Softing srl


si', la distanza minima dei bulloni dai bordi no etc etc.
sottoscrivo
e. 

affrontare un dialogo aperto.
Non penso vi debba essere contrapposizione, anzi. Dopotutto si lavora
sullo stesso argomento.
Il dialogo deve essere necessariamente aperto, ma per la mia breve
esperienza non ci sono ancora riuscito. Cambiero' prodotto (non dico
quale), prima o poi.
Devo comunque lamentare, insisto, la mancanza di casi pratici generali
su cui testare un post-processore, in modo da conoscere a colpo
d'occhio il modo di operare con cui e' impostato. Dopotutto un post
processore riflette le scelte progettuali di chi lo programma e tali
scelte devono risultare chiare a colpo d'occhio.
Sul caos normativo sono d'accordo. Non so se sia sito della Softing
che abbia scaricato il bel discorso di Pozzati alla sua ultima
lezione. Il concetto della tecnocrazia, della pretesa di normare
tutto, e della sensazione di "scudo" che si cerca dietro la pedissequa
ricerca delle prescrizioni e' sicuramente vero.
Purtroppo penso anche che non ci sia stato il necessario travaso di
esperienza tra le generazioni, che i giovani (e io sono tra questi)
debbano ancora imparare molto e che politicamente si sia cercato di
sopperire con un insieme di regole molto particolari e specifiche per
avere la presunta (e ripeto presunta) garanzia dell'esecuzione a
regola d'arte.
Il risultato e' un insieme di leggi cogenti, norme (UNI o altro) e
altre varie prescrizioni che talvolta e' impossible conoscere
completamente e si rischia, nel rincorrerle, di perdere il concetto di
buon costruire.
Il non rincorrerle e' ancora piu' pericoloso, dato che in caso di
contenziosi, chi piu' ne ha piu' ne metta....
Vedremo se la categoria dei tecnici riuscira' sul serio a far sentire
la propria voce, ma questo pero' e' un altro discorso, che non mi
sembra fosse l'argomento inizale del messaggio.
Forse sono caduto nella trappola di deviare il discorso rispetto al
problema di cui si discuteva: i buchi dei software, la mancanza di
garanzia prestata e l'impossibilita' di controllare la completa
aderenza dei risultati con la normativa in vigore.
Facciamo un esempio sul fatto che le software-house declinano ogni
responsabilita' sui risultati.
1) il programma e' venduto con la pretesa di eseguire le verifiche
secondo (ad es.) il DM 96;
2) il programma non offre garanzie in quanto il corretto uso e'
responsabilita' dell'operatore (cosa in parte logica);
3) dimostro che ne ho fatto un corretto uso: modellazione accurata,
carichi secondo le ipotesi etc. (cio' per un modello piccolo e
controllabile);
4) scopro alcune lacune nelle verifiche che non vengono segnalate (in
quanto alla fine spetta all'operatore la decisione finale) 
    --> tornando al punto 1 mi hanno venduto un qualcosa che non
rispetta le aspettative e le promesse.....
  Ciao
Filippo B.



La discussione finisce qui?



è solo un po' spinosa...   :D
ciao
e.