Newsgroup: it.discussioni.ingegneria.civile
Titolo: Vendo Sismicad 10.9

Qualcuno è interessato ?
R.F.

 ha scritto nel messaggio 
news:cn1tun$d36$1...@lacerta.tiscalinet.it...


 
Puo' darsi che si sia pentito di averlo comprato.
-- 
Ciao
Franco


si, ma la licenza non è normalmente trasferibile. Chiedi alla Concrete.
e perchè lo vendi? non perchè hai visto l'acca, spero ....
e. 

 ha scritto nel messaggio 
news:MPG.1bfea9a84...@news.virgilio.it...



Quanto vuoi? e che moduli hai?
Ciao

 pochissimo.
 
e quale sarebbe l'altro software?
 
--------------------------------
Inviato via 
http://arianna.libero.it/usenet/

Modest
"archichiara" <archic...@SPAMlibero.it> ha scritto nel messaggio
news:80Z183Z89Z31Y1...@usenet.libero.it...


 Modest
hai fatto felice l'ing. Daddi! :D
e. 

 ha scritto nel messaggio
news:i5j9p0lcq6t0lq4c3...@4ax.com...



ing.ce...@tiscali.it
pensavo si capisse, che bastava togliere "meno".....

 software house non sia daccordo (praticamente mai),
Anche in altri post ho sentito affermare che non è possibile rivendere una
licenza. Ora essendo io titolare di una licenza "usata", per la quale la
casa madre non ha fatto nessuna difficoltà, mi permetterei una piccola
smentita...
In realtà una software house che sappia farsi i suoi conti, non dovrebbe
avere troppi problemi in questo senso. Per il resto, è evidente, prima di
comperare una licenza da un privato, è bene informarsi presso la casa madre.

 ha scritto nel messaggio 
news:p3rld.31934$Es2.6...@twister2.libero.it...

non è "normalmente" possibile, basta comunque vedere il contratto.
Però se la swhouse acconsente in deroga e *per iscritto*, allora si può 
fare.
Io così ho acquistato una licenza Autodesk (che è tutto dire ...)
e. 

 R.F.
attento che sismicad č stato completamente riscritto; ora č veramente
un modellatore ad oggetti
renč del cartů

 ha scritto nel messaggio 
news:6797a1d2.0411...@posting.google.com...

renč del cartů .... mmmh
e. 

 ha scritto nel messaggio
news:6797a1d2.0411...@posting.google.com...



macchè oggetti.
Renè del Cartù si lascia incantare dal Nulli.
In realtà è la solita minestra in Autocad. Solo che l'imput sarà come 
BeamPiante, sicuramente più amichevole e spedito.
Dicono di averlo riscritto: cioè un mare di patch in arrivo ...
e. 


 


hai fatto felice l'ing. Daddi! :D
Non posso negarlo...  :-)
Ing. B.Daddi
Tecnisoft s.a.s
www.Tecnisoft.it

 tornato agli anni 90. In cosa si "materializza" ?
tipo acca edilus ...
e. 

 tipo acca edilus ...
Sembrerebbe dispregiativo, diciamo così è un modo per facilitare l'input
ed è utilizzato da vari programmi etabs compreso.
-- 
questo articolo e` stato inviato via web dal servizio gratuito 
http://www.newsland.it/news
 segnala gli abusi ad 
ab...@newsland.it

tornato agli anni 90. In cosa si "materializza" ?
L'interfaccia ad oggetti, informaticamente parlando, *non significa
assolutamente nulla*; invece ha senso parlare della programmazione ad
oggetti che per l'utente  finale non significa nulla e non si
materializza in nessun modo. La programmazione ad oggetti (che si
tratti di scrivere interfacce o altro) è un modo di pensare e scrivere
il software che interessa *solo il programmatore* e *mai l'utente
finale*. Per l' utente finale, un programma scritto in Assembly,
Fortran, BASIC, C, C++, Ada, Pascal, Java, Lisp, SmallTalk, Erlang...
non ha nessuna rilevanza. Quello che conta è che il programma debba
funzionare bene e rispondere alle sue esigenze. Ho visto ottimi
programmi scritti nei classici linguaggi procedurali e pessimi
programmi scritti nei linguaggi Object Oriented e viceversa.
Concludendo, un programma scritto seconda il paradigma ad oggetti *non
è affatto* sinonimo di un buon programma.
Quindi le conclusioni le fai da solo ;-)
jk
Jilani Khaldi
http://www.archsf.org

 ha scritto nel messaggio ...
ottima precisazione :)
e. 

Grazie per le risposte,
il paradigma di programmazione a oggetti mi è familiare e lo uso per i miei
programmi in Python.
Quello che vorrei capire è cosa ci si aspetta quando si parla di interfaccia
"a oggetti" in un software di calcolo.
Dalle schermate del programma menzionato si riesce a capire che selezionando
un elemento in una vista questo viene evidenziato in tutte le altre. E
magari modificandolo si aggiornano automaticamente tutte le viste. Abbiamo
poi una vista ad albero e bella matriciona di proprietà sui lati del
monitor. Viene da dire: embè ?
Sia in Edilus che in Etabs: c'è dell'altro? In che modo ti cambiano la vita
? ;)
 



? ;)
Credo soprattutto per loro. Noi, nella maggior parte dei casi, abbiamo
già provveduto.
jk
Jilani Khaldi
http://jkhaldi.oltrelinux.com/

 Dicono di averlo riscritto: cioè un mare di patch in arrivo ...
Sono il primo a criticare quelli della Concrete, però non mi piacciono i
preconcetti. Sinceramente è meglio un'ottimizzazione continua che una
assenza totale di patch o come m'è capitato con quelli della sts, patch a
richiesta solo quando ti rendi conto dell'errore.


 vita
Io la vedo così: il software strutturale fin'ora visto come prodotto di
nicchia riservato a pochi adepti, si sta trasformardo in un prodotto per
tutti di facile comprensione e input. 
Quindi frasi come quella in oggetto se da una parte confondono le idee
all'utente esperto, dall'altra avvicinano il neofita perché gli si dice
che non deve stare a scervellarsi nell'input perché utilizzerà elementi
così come lui li conosce.


 ha scritto nel messaggio 
news:cnfc9k$gp5$1...@news.newsland.it...

uso i programmi concrete da più, credo, di 10 anni e non penso di avere 
preconcetti al riguardo, ma solo certezze, conoscendo, come si usa dire, i 
miei polli ...
Son d'accordo con te che, a parità di quantità di bugs, è meglio una serie 
di patch alla Concrete piuttosto che una serie di ... non patch alla 2SI, 
per esempio, dove non arrivano nemmeno se segnali il baco o, se arrivano, 
arrivano dopo qualche mese.
Intanto chi non ne è al corrente ...
E che mi sembra tutte le volte di esser libero di scegliere l'albero a cui 
vogliono impiccarmi ...
Eppoi, generalizzando, è mai possibile che per una qualche calcolatrice da 
due soldi nei supermercati ti danno 2 anni di garanzia, mentre per un 
*sofisticatissimo* programma d'ingegneria ti garantiscono al massimo il CD 
su cui son registrati?
E per avere il programma decentemente funzionante devi anche pagargli la 
pensioncina per la manutenzione annuale ?!
Su andiamo !
ciao 

 materializza in nessun modo.
Non sono daccordo (per la prima volta), quado tu hai oggetti in un programma 
e non elementi ottieni le seguenti cose:
- se sposti un ascesore che fora il solaio, il foro non resta nella 
posizione precedente ma si sposta con l'ascesore
- se hai un controvento a croce con un nodo al cento se sposti 2 nodi il 
controvento resta con aste rettilinee e non spezzate
- se riduci la luce tra due travi parallele al solaio gli arcarecci ti si 
riposizionaro dividendo in parti uguali la luce o si riducono od aumentano 
di numero in base all'interasse min max prefissato.
Si lavora con oggetti di tipo parametrico.
Ciao Fabrizio



.... mi ripeto, grande "E"-ugenio!
up!..up!!
P.S. ... non interessa piů a nessuno lo "strutturale", quindi!
Infine una piccola constatazione; mi sembra di vedere sempre + spesso qui
sul NG (e non solo) che per ogni argomento nascono repliche e
contro-repliche; a volte anche con toni "intensi".
Sara' un segno forse...
Tobruk :-)


Si lavora con oggetti di tipo parametrico.
Puoi ottenere gli identici effetti con la programmazione procedurale,
logica o funzionale e non solo con quella ad oggetti.
Dire che un programma è stato scritto ad oggetti è una *buona* mossa
di marketing. Tanto la gente non capisce e difende cose delle quali ha
solo conoscenze sommarie e spesso sbagliate.


 solo conoscenze sommarie e spesso sbagliate.
[snip]
Credo che si stia andando fuori strada. Ad essere pubblicizzata non e' la
programmazione ad oggetti, di cui in effetti all'utente finale non puo'
importare di meno, ma il fatto che l'input del programma sia *per oggetti*,
il che e' gia' parzialmente vero per la versione attuale.
Mi spiego: un programma FEM non distingue una colonna da una trave, per lui
sono due elementi beam, mentre per noi progettisti le due cose sono molto
diverse a livello di interpretazione dei risultati, anche e non solo per via
di imposizioni normative. Lo stesso si dica per un setto di controvento ed
un solaio, che possono essere modellati con elementi FEM uguali, ma di
diverso significato per il progettista, che magari preferira' la mesh piu'
fitta per uno e meno per l'altro, oppure per uno vuole solo un comportamento
mebranale, etc.
Oppure ancora il problema a cui accennava l'ing. Daddi qualche messaggio fa:
l'innesto di un pilastro sul bordo di una piastra e l'eccentricita'
accidentale che ne nasce: una situazione del genere, relativamente frequente
e quindi prevedibile e *programmabile* si gestisce meglio IMHO, se il
programma riconosce e gestisce diversamente una colonna da una trave e una
piastra di fondazione da una in elevazione, e cosi' via.
Questo tipo di approccio potrebbe (potrebbe!) essere un'innovazione
interessante, al di la' del tipo di programmazione adottato: vedremo.
-- 
Ciao, Tigers
[cit.] .. perchč la curva d'apprendimento di google č storicamente tra le
piů ripide ... e.
www.tigers.3000.it


Credo che vada fatta un riflessione un pelo piu approfondita. è un
problema che ci siamo posti spesso..
Alcuni esempi credono possano chiarire:
Oggetto TRAVE ed Oggetto PILASTRO:
per il FEM sono ovviamente due BEAM, per il codice di calcolo piu'
evoluto devono essere differenziati per tutte le problematiche cui
Tiger accennava. Questo puo' essere risolto semplicemente con dei
"flag" di identita' che poi guidano il post-processore. Non sono
richiesti particolare scelte da parte dell'utente.. sempre una BEAM
sara' per il solutore.
Oggetto "SCALA":
(non avete idee di quante domande .. "ma le fa le scale?")
qui il discorso si fa ben piu complesso.. come trasferisco la "scala"
al solutore?
- Una serie di "beam in spessore inginocchiate" ?
- Una serie di "elementi bidimensionali "inginocchiati" ? con che
meshatura ?
- Una unica beam inclinata ( e al diavolo l'inginocchiatura)
domande : 
il pianerottolo e la rampa che parte sono due BEAM diverse
(praticamente sovrapposte?) 
e se voglio considerare la scala non incastrata ma appoggiata per
diminurire l'effetto controvento nell'edificio?
A questo livello ed in questo senso abbiamo rinunciato all' approccio
"ad oggetti" gia' secoli fa.. ci tocca rispondere "no, non fa le
scale, ma se vuole e'  possibile modellare qualunque tipo di scala",
pero' in questo modo lasciamo    il CONTROLLO su cosa fare e quindi di
che risultati ottenere all'utente, che in fin dei conti deve fare
l'INGEGNERE.  Il "PALAZZINARO" (come spesso chiamato in questo NG) che
vuole il programma in cui si inserisce l'oggetto "SCALA"  (o l'oggetto
ASCENSORE ecc..) non fa parte del  nostro "target"...
Scusate il lungo post, cordiali saluti


 ASCENSORE ecc..) non fa parte del  nostro "target"...
[snip]
E' proprio qui che sono curioso di vedere gli sviluppi. Se l'oggetto scala
e' implementato "da palazzinaro" allora non mi interessa, se invece
l'oggetto scala e' implementato con la possibilita' di intervenire e
modificare magari i parametri di modellazione dell'oggetto al momento della
meshatura e del passaggio da elemento scala a modello FEM, magari con la
possibilita' di cambiare il tipo di modellazione con un semplice clic,
allora la cosa puo' interessare.
Faccio un altro esempio: si potrebbe pensare ad un *oggetto* muro di
cantinato, con tutto un modulo di calcolo diverso che prevede l'inserimento
di dati diversi relativi al terrapieno, lasciando al software il compito di
calcolare la spinta (secondo le MIE inidcazioni) ed inserire i carichi e
poter, in un secondo momento, cambiarlo e trasformarlo in un muro senza
terreno, magari solo con un clic. Oppure adottare per lui e per lui solo un
modello di calcolo separato e semplificato, prescindendo magari
dall'andamento degli sforzi derivato dal modello FEM, che magari considero
nell'analisi, necessariaemnte piu' sofisticata, di altri problemi, etc.
-- 
Ciao, Tigers
[cit.] .. perchè la curva d'apprendimento di google è storicamente tra le
più ripide ... e.
www.tigers.3000.it

 richiesta solo quando ti rendi conto dell'errore.
sono in cerca di qualcuno che non abbia da ridire su software analoghi
a Sismicad in fatto di patches, ecc. ... suggeritemi quale pacchetto
devo comprare .... non è forse che siamo incontentabili sempre e
comunque ?
rene' del cartu'

 comunque ?
Si è così. Non esiste il software, esiste quello che va bene per le ns
aspettative ed esigenze. Beh che te ci creda o no per fare determinate cose
sismicad è il massimo.

 Su andiamo !
Condivido in pieno, credo che molto dipenda dalla scarsissima affinità che
fino a qualche anno fa c'era fra tecnici e computer (tutti soddisfatti del
minimo del minimo), inoltre essendo una nicchia senza mercato, siamo esposti
alla mercè di piccole software house che alla fine fanno quello che possono
e qualcuna pure improvvisata.

...

concordo; soprattutto l'output è veramente cantierabile salvo
perfezionismi personali.
rene' del cartu'

 sismicad č il massimo.
Tipo? cosa sencondo te fa sismicad che nessun altro SW fa? ( non č 
provocazione č solo per capire ) 

...

concordo; soprattutto l'output è veramente cantierabile salvo
perfezionismi personali .... 
rene' del cartu'

nell'analisi, necessariaemnte piu' sofisticata, di altri problemi, etc.
Una cosa simile è fattibilissima e non presenta particolari difficoltà
trattandosi di un singolo oggetto che può essere espresso da una
singola classe. La presenza della terra e dei carichi possono essere
espressi con poche proprietà.
I casini cominciano quando si tratta di comunicare con altri oggetti.
Esattamente come avviene nella vita reale.


 rene' del cartu'
Diciamo piuttosto che o si fa come dice lui o niente...


Salve, leggo da un po' questo newsgroup e lo trovo piuttosto 
interessante. Peccato che si sia cosi' in pochi a parlare di alcuni 
argomenti, rispetto al numero di interessati "la' fuori".
Trovo questo argomento sugli oggetti interessante e curioso. Curioso 
perche' ho letto di qualcuno che ha collegato erroneamente la 
programmazione ad oggetti e la progettazione ad oggetti. Interessante 
perche', come accennato dall'ing. Daddi, il passo e' breve per arrivare 
a parlare della filosofia alla base della progettazione assistita dal 
calcolatore.
La questione della programmazione ad oggetti spero si sia esaurita: sono 
due discorsi diversi, in uno rientra la visione del progettista software, 
nell'altro la visione dell'utente, e le cose sono totalmente separate. 
Un codice scritto ad oggetti ha alcune proprieta' molto particolari e 
comunemente molto apprezzate dagli ingegneri del software; differenze 
riscontrabili direttamente dall'utente finale: nessuna. Un software di 
CAE ad oggetti, invece, permette, almeno idealmente, di creare nella 
struttura un oggetto che ha una stretta correlazione con un oggetto del 
mondo reale: come si e' detto, una scala, un muro, ecc.; correlazione 
con il tipo di linguaggio utilizzato per la realizzazione: nessuna.
Ed e' qui che entra la questione interessante: e' giusto che il modello 
al calcolatore abbia una cosi' stretta relazione col modello reale? e' 
giusto che il software dica all'ingegnere cosa si puo' fare e cosa non 
si puo' fare? perche', se il software e' basato SOLO sugli oggetti, O e' 
stato realizzato talmente bene da permettere TUTTO quello che chiunque 
potrebbe avere in mente di fare su un software "tradizionale" ad 
elementi finiti, O sara' sempre limitato al suo mondo applicativo, ai 
quattro parametri resi disponibili per ogni "oggetto" (perche' per 
motivi pratici c'e' un limite di occlusione legato all'interfaccia, alla 
comprensibilita' da parte dell'utente), alla necessita' di continui 
aggiornamenti per aggiungere "oggetti" richiesti dagli utenti man mano 
che il software, eventalmente, prende piede. E cosa ne viene fuori? Temo 
sia difficile che ne esca un software POTENTE e NON CONFUSO. Oppure...
Oppure, si potrebbe dare all'utente la possibilita' di assegnare anche 
degli elementi finiti "tradizionali" ed affiancarli agli "oggetti".... 
ma... un attimo, rigiriamo la frittata e ... voila'! Affianchiamo gli 
oggetti agli elementi finiti e abbiamo nient'altro che quello che molti 
software offrono gia', un preprocessore. Un problema comune dei 
preprocessori attuali e' la difficolta' delle modifiche dopo 
l'"immersione" nel modello ad elementi finiti di un oggetto, ma non e' 
un problema condiviso da tutti i software e comunque non un problema 
insormontabile. E allora? ci venderebbero l'acqua calda.
Per concludere, per me l'ingegnere "esperto", o perlomeno "cosciente" di 
quello che fa, deve necessariamente rivolgersi ad un software avanzato 
di progettazione assistita dal calcolatore, perche' il controllo sulle 
operazioni svolte, sui calcoli, sui minimi dettagli (in quei momenti in 
cui godiamo ad essere puntigliosi), e' imprescindibile dalla professione (
idealmente). Ma, per non negarsi la possibilita' di essere veloce come 
un palazzinaro che ha l'ultimo software ad oggetti disponibile sul 
mercato, l'ingegnere di cui sopra dovrebbe forse cercare, puntare su, 
scriversi da solo il codice per, RICHIEDERE ALLE SOFTWARE HOUSE, 
preprocessori potenti, effettivamente adatti alle sue esigenze, che, 
integrati o no nel programma di calcolo, sarebbero il trais d'union tra 
la velocita' della modellazione e un motore di calcolo affidabile e a 
cui affidarsi per tutta la propria carriera.
Scusate il lungo post, dovevo pur presentarmi no? :)
A presto,
Djinn
PS ah a proposito vi prego, si dice INPUT, non IMPUT! :)

Resta chiarito che quello che nel resto del sistema solare viene chiamato, 
in modo molto chiaro, "modellazione parametrica" può anche chiamarsi "input 
a oggetti".
La modellazione parametrica è molto efficace se i modelli che si vanno a 
creare sono simili tra loro e non variano che per pochi parametri. Cioè  la 
situazione tipica delle strutture prefabbricate, tanto per restare 
nell'ingegneria civile.
Per il resto concordo sostanzialmente con Jilani: anche tralasciando 
l'aspetto informatico, per la vastità dei problemi che si devono risolvere 
oggi si può parametrizzare solo la soluzione di una piccola parte dei 
problemi, ovvero restringere il campo delle possibili soluzioni. Ed è 
esattamente quello che sta accadendo a certi prodotti software.

 PS ah a proposito vi prego, si dice INPUT, non IMPUT! :)
Ed anche trait d'union , non trais... :)


 PS ah a proposito vi prego, si dice INPUT, non IMPUT! :)
vero, m'è scappato, pardon :)
e. 

 Su andiamo !
Cmq desidero precisare che non sempre le patch sono correttive, spesso
ampliano funzioni o introducono verifiche che prima non erano prodotte,
ottimizzano le finestre di input ecc.
Diciamo cosě almeno quelli della concrete il contratto di manutenzione se
lo guadagnano!


 Ed anche trait d'union , non trais... :)
ahahah volevo vedere se eravate attenti! :) *procede lentamente 
all'indietro verso la porta, la raggiunge, la apre silenziosamente, 
fugge a gambe levate con una risata isterica in sottofondo*
Ciao,
Djinn

 provocazione è solo per capire )
Non è un discorso di fare cose che nessun altro fa, il concetto è diverso, 
legato strettamente a mere considerazioni economiche, perché va bene la 
passione ma di aria non si campa.  Se ho qualcosa che richiede una 
modellazione semplice posso scegliere la via che più preferisco, fare tutto 
a mano, utilizzare winstrand, il sap2k ecc ecc. Poiché l'aria non sfama 
allora per quel genere di cose, cioè ottenere - velocemente - input, calcolo 
e output formalmente corretti da una modellazione semplice, sismicad è 
perfetto.

 scrisse:

Mi aspettavo piu' una sgommata alla Simspons. :)
