-
.L'errore che ho segnalato era relativo al fatto che non avevo prelevato il numero della combinazione utente dal foglio prima dell'utilizzo.
per lo scarico del file aggiornato il link è postato più avanti
Edited by texitaliano64 - 13/3/2014, 21:22
. -
p.luciani .
User deleted
Ho aggiornato il codice proposto da texitaliano e ritengo che possa funzionare dal punto di N... ma il problema rimane a livello di momenti resistenti.
Come possono essere uguali Mrxd e Mryd in una sezione a T in pressoflessione deviata con momenti agenti in x e y uguali ??
In merito al problema sollevato da reversi direi di ripartire dalla versione TESTATA e apportare modifiche con molta moderazione condividere il file SOLO dopo una approfondita validazione.... -
.
Un test che potresti fare, e che io ho già fatto anche usando un software commerciale è di comparare i risultati col VCASLU del prof. Gelfi, noterai che questo comportamento è corretto. . -
p.luciani .
User deleted
Ragazzi ho fatto la prova con RC-SEC del grande TRITTO e devo dire che non solo Mrxd e Mryd sono uguali ma anche i valori sono praticamente identici con l'excel... scusate . -
.
Luciani, già la volta scorsa mi ero incuriosito circa il tuo quesito...ma poi avevo dimenticato di indagare meglio sulla questione.
O meglio, volevo 'a botta' risponderti che avendo un momento risultante a 45° era assai normale ottenere dei momenti di rottura anch'essi a 45°. Poi mi ero impappinato pensando a domini circolari, che in effetti erano a 'patata', ecc. incasinandomi.
Ma oggi ritorno al mio primo pensiero. Anzi, generalizzo. Non è possibile non ottenere un momento di rottura che non abbia la stessa direzione del momento sollecitante.
Ovviamente questa mia affermazione è vera se precisiamo per benino cosa intendiamo per: momento di rottura associato ad un momento sollecitante.
Di fatto a noi conoscere i momenti di rottura 'associati', ecc. non importerebbe un bel nulla. L'importante è che il mio punto 'sollecitante' stia dentro il dominio di rottura, ed amen.
Guarda questa figura, c'è la tua bella sezione a T ed il dominio associato (ovviamente a forma di patata):
Al fine di 'definire' un fattore di sicurezza della sezione (quanto il mio punto 'sollecitante' stia dentro il dominio di rottura), dall'origine del sistema di riferimento viene tracciato un raggio vettore che passa per il punto 'sollecitante' di coordinate Mdx, Mdy. Ovviamente tale raggio vettore è inclinato di 45° (perchè Mdx=Mdy).
Si prolunga tale raggio vettore fino ad intercettare il diagramma a rottura della sezione.
Il rapporto tra le lunghezze (da 0 a Mr e da 0 a Md) indica il fattore di sicurezza della sezione con la sollecitazione data.
E' chiaro però che ogni punto che giace sul tale raggio vettore non potrà non avere identiche coordinate x ed y (altrimenti il raggio vettore non sarebbe a 45°), è quindi evidente che Mrx=Mry.
Per convincertene ti faccio vedere cosa accade modificando la geometria della sezione:
Anche in questo caso 'magicamente' (ma ovviamente ormai sappiamo che così non è....) i momenti di rottura x ed y sono identici.
Se vuoi conferma ulteriore di questo 'strano' fenomeno fai pure un'altra prova. Prova ad avere momento sollecitanti la cui risultante è inclinata a 30°......scommessa che anche i momenti di rottura avranno inclinazione a 30°?
Aggiungo per amore di completezza che questo modo di conteggiare il 'fattore di sicurezza' ed i relativi momenti di rottura è del tutto convenzionale.
Avremmo potuto intervenire in maniera differente, magari tracciando un segmento orizzontale dal punto 'sollecitante' verso la frontiera del dominio, oppure verticale. Oppure come detto sopra, proprio un bel niente, se non un "verificato", "non verificato".. -
.
per dare seguito al mio precedente messaggio, ho scaricato il file emendato da luciani nella versione riproposta da tex e, augurandomi che nessuno nel frattempo abbia fatto altre modifiche, ho fatto alcune correzioni che qui documento, proponendo infine a mia volta (e vi prometto che non lo farò più, per lasciare a luciani il compito di coordinare le modifiche su questo file) una possibile versione da usare come base di partenza per ulteriori estensioni.
alla prima pubblicazione di un aggiornamento da parte di luciani provvederò io stesso a rimuovere la presente mia versione del file da questo messaggio.
coerentemente con l'altra sub che genera le armature, ho eliminato l'uso dei gradi anche nella sub che segue:CODICESub SezioniDefault(Tipo As Integer, p() As Double, R As Integer, C As Integer)
.
.
.
Case 7: 'Circolare
'centro raggio
Raggio = p(1) / 2
discreticcazione = p(2)
PiGreco = 3.14159265358979
t = 2 * PiGreco / p(2) 'direttamente in radianti
For ii = 0 To discreticcazione
yy = Raggio * Cos(t * ii)
xx = Raggio * Sin(t * ii)
Call AddP(xx, yy, R, C, i)
Next ii
End Select
End Sub
ho provveduto poi a formattare il testo nei fogli accorpando, ove necessario, alcune celle in modo da centrare il titolo delle varie tabelle. ho corretto poi anche alcuni errori di digitazione sia nel testo dei fogli che nei messaggi all'interno del codice (preciso che non ho toccato i nomi delle variabili).
non sono invece riuscito a chiamare csi ed eta gli assi principali nel grafico della sezione, sul foglio "geometria", perché non sapevo dove andare a trovarli.
qui il file da me rinominato VerSectZaxCAP_PL_rev4.xls
avrei intenzione di fare lo stesso anche con il file di tex, se nel frattempo tex rimane fermo per un po'...File Allegato
. -
p.luciani .
User deleted
Ringrazio tutti per l'interesse... Prima di andare avanti con l'implementazione di nuove funzioni direi di ripensare un attimo l'organizzazione dei dati di input e output che personalmente la trovo un po' disordinata...Vorrei predisporre l'output in modo da avere la possibilità di effettuare verifcihe multiple (ovvero output per righe e riportare il dominio per la combinazione che determina il coefficiente minimo... Inoltre la limitazione a 25 combinazioni mi sembra troppo riduttivo. In questi giorni vedo di proporre un aggiornamento dal layout... . -
.
Allo Zaxcode ho apportato alcune modifiche in merito ai parametri di integrazione, consentendo all'utente di modificarli a piacimento.
Originariamente il numero delle fibre era prioritario ed era fissato a 100, con uno spessore minimo fibra di 0.1mm.
Io ho scelto che lo spessore minimo delle fibre "SpMinFibre" è prioritario e viene eventualmente ingrossato se il numero massimo delle fibre supera la soglia "NMaxFibre".
Questi sono comunque solo dettagli tecnici, dato che i PC odierni hanno si una buona potenza di calcolo ma tuttavia non è illimitata.
Ecco alcuni stralci di codice che parlano chiaro:CODICE'variabili globali
Public SpMinFibre As Double 'spessore minimo delle fibre per l'integrazione in [mm]
Public NMaxFibre As Integer 'numero massimo di fibre per l'integrazione
Private Function risult_compr(ByRef polic() As poligono_sezione, armco As armo_sezione, armcp As armp_sezione, _
deform As deform_sezione, ymax As Double, yamin As Double, yn As Double) As risultante_n
'...........
'...........
'...........
Dim NSTRISCE As Integer
'integriamo con strisce spesse circa SpMinFibre mm
NSTRISCE = Abs(ymaxpe - yn) / SpMinFibre + 1
'limitiamo il numero massimo di strisce per ridurre il tempo di elaborazione
If NSTRISCE > NMaxFibre Then NSTRISCE = NMaxFibre
dx = (ymaxpe - yn) / NSTRISCE
' Inizialmente divide in 100 striscie la parte compressa della sezione
'dx = (ymaxpe - yn) / 100
' Controlla poi che le striscie non siano troppo sottili (eccessivo peso in elaborazione)
'If dx < 0.1 Then dx = 0.1
'...........
'...........
'...........
End Function
Private Function risult_traz(ByRef polic() As poligono_sezione, armco As armo_sezione, armcp As armp_sezione, deform As deform_sezione, _
ymax As Double, yamin As Double, yn As Double) As risultante_n
'...........
'...........
'...........
Dim NSTRISCE As Integer
If (yn < ytmax) Then 'se l'asse neutro è più basso della massima ordinata dei poligoni resistenti a trazione
'integriamo con strisce spesse circa SpMinFibre mm
NSTRISCE = Abs(ytmax - yn) / SpMinFibre + 1
'limitiamo il numero massimo di strisce per ridurre il tempo di elaborazione
If NSTRISCE > NMaxFibre Then NSTRISCE = NMaxFibre
dx = (yn - ytmin) / NSTRISCE
'dx = (yn - ytmin) / 100
' Controlla poi che le striscie non siano troppo sottili (eccessivo peso in elaborazione)
'If dx < 0.1 Then dx = 0.1
Inizio = yn - dx / 2#
Else
'integriamo con strisce spesse circa SpMinFibre mm
NSTRISCE = Abs(ytmax - ytmin) / SpMinFibre + 1
'limitiamo il numero massimo di strisce per ridurre il tempo di elaborazione
If NSTRISCE > NMaxFibre Then NSTRISCE = NMaxFibre
dx = (ytmax - ytmin) / NSTRISCE
'dx = (ytmax - ytmin) / 100
' Controlla poi che le striscie non siano troppo sottili (eccessivo peso in elaborazione)
'If dx < 0.1 Then dx = 0.1
Inizio = ytmax - dx / 2#
End If
'...........
'...........
'...........
End Function. -
.
lo stralcio di codice cui tex si riferisce nel suo precedente messaggio c'era già nel file (perlomeno, io me lo ritrovo) ma è utile che venga documentato.
quando però vado a testare una sezione di controllo che ho scelto arbitrariamente, proprio quel pezzo di codice mi dà un errore di runtime.
la sezione è quella che ho già proposto qui: #entry552165916
riporto di seguito anche l'immagine del post, da cui si evincono le caratteristiche geometriche e di armatura:
le sollecitazioni sono invece le seguenti:
verificando la combinazione 2, in cui lo sforzo normale è molto elevato rispetto alle capacità della sezione, portando il punto rappresentativo dello stato di sollecitazione ben al di fuori del dominio, con versectzax trovo:
in cui il dominio risulta intrecciato (cosa che però non dovrebbe succedere) ma viene comunque calcolato e rappresentato, mentre nel file di tex ottengo un errore di runtime proprio nel pezzo di codice da lui introdotto:
al di là di capire perché nel file originario il dominio venga intrecciato, chiedo a tex se a suo parere si possa individuare qualcosa che rende errata la prova che sto conducendo oppure c'è un bug nel codice.
edit:
controllando la stessa sezione con un altro programmino (ho lavorato in daN e cm), la risposta è stata: "Spiacente, ma non posso disegnare il dominio di rottura. Non essendo rispettata la disuguaglianza -62941 < Nd < 190918 il dominio non esiste.
il che mi dice che in excel questo controllo non c'è.
Edited by reversi - 12/3/2014, 18:38. -
.
Se non si controlla che Nd sia compreso tra Nlim di trazione ed Nlim di compressione per la sezione......succede il patatrac.
Io ricordo che questo controllo, nel mio codice era presente.
Qui una schermata del mio programma quando Nd è 'sballato':
. -
.
@reversi
Ho simulato il problema in base ai dati forniti nello screen shot, ed ho visto che si verifica un errore di Overflow.
Il problema segnalato deriva dal fatto che avevo sottovalutato la dimensione della variabile locale NSTRISCE.
Ho revisionato il file come segue sia nella routine risult_compr che nella routine risult_traz.
prima:CODICEDim NSTRISCE As Integer
dopo:CODICEDim NSTRISCE As Long
Adesso funziona in maniera conforme alle attese, eccetto il controllo dei limiti di Nd che ha giustamente segnalato Zax.
Edited by texitaliano64 - 12/3/2014, 21:41. -
.Il problema segnalato deriva dal fatto che avevo sottovalutato la dimensione della variabile locale NSTRISCE.
...
Adesso funziona in maniera conforme alle attese, eccetto il controllo dei limiti di Nd che ha giustamente segnalato Zax.
in realtà, e lo sai benissimo anche tu, per l'elevato valore di Nd usato nel test si ritrovano scambiati di posto la causa e l'effetto. sembra perciò che la causa dell'errore stia in quel frammento codice e che questo vada modificato.
la vera causa è invece l'assenza del controllo preventivo su Nd poiché a valle di questo definire NSTRISCE come integer sarebbe molto più che sufficiente per ogni sezione.
usando il long, il tutto ridiventa normale. eccone qui l'esempio con il file in rev.4 postato da tex:
. -
.
Ragazzi....ma fatemi capire...
Con la modifica di Tex, personalizzando quindi la larghezza della striscia, io correrei il rischio di avere un numero di fibre superiore a 37.000 e passa striscie???????
(Comincio a capire pertanto la 'smania' ottimizzatrice di Reversi.......)
Ma siamo sicuri che ci interessano momenti di rottura con valori di 'precisione' del centesimo di Nmm?. -
.
io purtroppo ho perso il filo del tutto.
Non so piu' quale è la versione ultima e se in questa ultima sono state apportate tutte le modifichette descritte.
Reversi mi ha passato una versione con alcune sue modifiche intese a questa ottimizzazione. IN queste settimane ho poco tempo da dedicare alla coltivazione della mia anima e passione per codici ed algoritmi e quindi non ho controllato ne verificato nulla. Tuttavia mi è stato sufficiente far girare una sola volta il file passatomi per ottenere immediatamente un errore. VBA non riconosceva una variabile della quale sembra non era stata data la relativa istruzione DIM. Forse un errore di digitazione, forse qualcosa altro? Bho.
Ho chiuso, conservato il file in un angolo di non ricordo quale pc e ..... -
.
@Zax
No non c'è il rischio di andare a calcolare con la precisione del micronewton dato che non ha senso, infatti c'è l'impostazione utente NMAXFIBRE che limita ad un numero congruo di strisce (100 di default).CODICEDim NSTRISCE As Long
'integriamo con strisce spesse circa SpMinFibre mm
NSTRISCE = Abs(ymaxpe - yn) / SpMinFibre + 1
'limitiamo il numero massimo di strisce per ridurre il tempo di elaborazione
If NSTRISCE > NMaxFibre Then NSTRISCE = NMaxFibre
dx = (ymaxpe - yn) / NSTRISCE
@afazio
Per ora la versione del foglio che ho messo in scarico recepisce solo parte delle modifiche consigliate da reversi e da pluciani, comunque seguo la discussione controllando possibilmente ciò che viene proposto ed i problemi rilevati..
Ci A Pi |
