Ingegneria Forum

Un pò di risposte.

@SpinoWeb

La metodologia della "matrice della sezione" è in realtà nota (per esempio puoi dare un'occhiata qui: http://dx.doi.org/10.1061/(ASCE)0733-9445(1985)111:12(2659) ).

Che non sia io lo "scopritore dell'acqua calda" ne avevo piena consapevolezza, e non mi voglio affatto arrogare meriti che non ho. Ribadisco invece, come detto nella premessa di questo topic, di non aver mai visto nei libri da me consultati una procedura "numerica" come quella da me proposta, oppure implementata da Ferrari nel suo DORO. Magari perchè i libri da me consultati sono datati, e le procedure grafiche un tempo venivano privilegiate rispetto a procedure più "pesanti" da un punto di vista computazionale.

Rispondo volentieri a Betoniera, su due cose del suo intervento.

Come non quotarti circa la "fatica" per giungere a dei risultati accettabili in ambito programmazione. Ho accennato ad inizio topic che pur provando a programmare, fino a 10 anni fa, alla fine ho smesso, per varie ragioni. Non ultima la fatica, appunto.
Io lo so che sto giocando sporco con gli utenti di questo forum. Io sto dando qui parti di codice, alla fine poche righe come si vedrà, che risolvono un problema. Ok, so che si tratta di una risoluzione generale, senza se e senza ma, del "vecchio" problema della verifica a presso-flessione deviata di una sezione generica in c.a.
Però immagino ci possa essere qualcuno che prenda il motore per costruirci attorno la macchina.
Gioco sporco, perchè so che in un programma la parte "algoritmica" è la "meno spesa" come si dice dalla mie parti. Il controllo dell'input, la gestione dell'interfaccia, la necessità di far capire cosa deve fare una terza persona, ecc. sono quelle le parti dove le nottate non bastano.

Circa invece il suggerimento per il prossimo sviluppo di questo topic, ovvero la verifica SLU delle sezioni, esso è assai ben accetto proprio perchè, come te, sono anch'io convinto di procedere con una presso flessione retta (o meglio con asse neutro orizzontale) e poi, piuttosto che far ruotare l'asse neutro, procede con "inganno" facendo ruotare la sezione.
A differenza tua, però (ma potrei anche non aver capito bene il tuo metodo), io voglio ricavare la fetta di salame. Ovvero dominio Mx-My per dato N. Pertanto le sollecitazioni flettenti esterne (che tu utilizzi già per il posizionamento dell'asse neutro) alla fine serviranno solamente a verificare di stare dentro o fuori il dominio.
In ogni caso avremo modo di confrontarci. Voglio sempre arrivare alle cose per "mattoni" successivi. Specificando bene come ogni "mattone" deve lavorare da solo ed insieme agli altri.

Nel senso che lo spirito del topic non è solamente didattico puro. Vorrei che si capisse (proprio perchè sulla mia pelle per prima ho vissuto il fenomeno) che le cose che sembrano semplici o semplicissime, nel momento in cui si cerca di implementarle comportano sempre dei ragionamenti, delle difficoltà, delle risorse, di cui inizialmente si ritiene non avere necessità o bisogno.

@SpinoWeb
Che non sia io lo "scopritore dell'acqua calda" ne avevo piena consapevolezza, e non mi voglio affatto arrogare meriti che non ho. Ribadisco invece, come detto nella premessa di questo topic, di non aver mai visto nei libri da me consultati una procedura "numerica" come quella da me proposta, oppure implementata da Ferrari nel suo DORO. Magari perchè i libri da me consultati sono datati, e le procedure grafiche un tempo venivano privilegiate rispetto a procedure più "pesanti" da un punto di vista computazionale.

Il mio intervento non era per sottolineare che il metodo fosse noto, ma solo per rispondere alla tua domanda se qualcuno ne avesse mai sentito parlare.
Inoltre, come tu stesso riporti, è assai difficile che qualcuno diffonda le procedure numeriche che usa. Tutti scrivono le equazioni base dei metodi che propongono, ma poi questi vanno implementati e nessuno spiega come si risolvono importanti problemi numerici. Tu lo stai facendo ed infatti di questo ti ringrazio ancora perchè rende questo topic ancor più interessante.

Io personalmente ho usato un metodo delle strisce ruotando la sezione (come ha fatto anche Betoniera) ed è abbastanza veloce anche nel ricavare la "fetta di salame". Le difficoltà invece sorgono quando modifico il legame costitutivo e provo a mettere una legge di tipo softening: lì i risultati non sono ancora buoni.

Nel lontano 1980 il compianto prof. Michele Capurso scrisse nel basic del Commodore 64 (appena 64kb di memoria utente) una serie di magici piccoli programmi (da 8Kb max cadauno !!!) tra i quali quello relativo alla pressoflessione deviata alle T.A.
Il codice sorgente era liberamente consultabile ed il metodo seguito era proprio quello della matrice di rigidezza della sezione (indicato da Zax) con risoluzione del sistema di terzo grado ad ogni iterazione. Resta il metodo più conveniente da utilizzare per le verifiche SLE in esercizio

Recupare i programmini di Capurso sarebbe una gran cosa. E' uno che ci ha studiato tanto su questi argomenti

se può servire, c'è quest'articolo del prof. Rosati (UniNA) ed altri, ( che ha causato anche qualche polemica per il fraintendimento del titolo "Così si verificano le sezioni in c.a. pressoinflesse") a pag. 18
www.ordineingegnerinapoli.it/notiziario/notiz202.pdf

I signori hanno scomodato l'analisi tensoriale pur di non far capire "una mazza" del procedimento numerico seguito.
Quando bastava invece un po' di geometria analitica...

Stessa cosa che ho pensato io. Della serie "come rendere complicato qualcosa che altrimenti sarebbe chiaro e comprensibile".

Parte 7

Il codice SLE
In pratica per quanto riguarda la verifica SLE abbiamo già finito. Il problema è stato sviscerato nella sua parte teorica, rimane solamente da presentare un listato.
Ho provato a scrivere una funzione quanto più indipendente dal resto del codice che ci sta attorno. A parte le strutture dati che definiscono la geometria della sezione, le uniche variabili globali sono xg e yg, ovvero le coordinate x,y del baricentro della sezione omogenea.
E poiché le combinazioni cui una sezione viene sottoposta sono ormai numerose, la funzione accetta in ingresso una tripletta di sollecitazioni e restituisce la corrispondente tripletta deformativa. Sarà poi la funzione chiamante (che magari avrà un ciclo di chiamata per ognuna delle combinazioni) a decidere cosa fare di questo output (calcolare le tensioni, stampare una porzione di tabulato, disegnare la parte compressa, determinare il massimo valore di compressione calcestruzzo o acciaio tra più combinazioni, ecc.)

Nel solito header file bisognerà definire altre 2 strutture dati (lo so, ci sono affezionato e forse esagero)

struct deform
{
 float u[3];
};

struct sollecitazioni_esterne
{
 float n;    /* Sforzo normale (positivo di compressione) */
 float mx;   /* Momento flettente asse x (positivo se comprime fibre +y) */
 float my;   /* Momento flettente asse y (positivo se comprime fibre +x) */
 int tipo;   /* 0=SleQp / 1=SleFr / 2=SleRa / 3=Slu */
};
Ed il prototipo della funzione:

struct deform verifica_SLE(struct sollecitazioni_esterne);
Infine, ecco la funzione. Intanto leggetela, alla fine il commento.

struct deform verifica_SLE(struct sollecitazioni_esterne soll)
{
 int register k,np;
 float norma0,norma1=1.0;
 float s1,s2;
 struct deform def;
 struct poligono_sezione polic[4];
 struct geometria_sezione geo;

  /* Se tutte le sollecitazioni sono nulle ritorna la struttura def fatta da 0.0 */
 if (soll.n==0.0 && soll.mx==0.0 && soll.my==0.0) { def.u[0]=0.0; def.u[1]=0.0; def.u[2]=0.0; return(def); }

 def.u[0]=1.0; def.u[1]=0.0; def.u[2]=0.0;
 do
   {
    float parz;

    norma0=norma1;

    /* Determina la geometria della sezione “reagente” */
    for (np=0;np<=4;np++)
        {
         /* Se il poligono reagisce anche a compressione esso rimane sempre interamente reagente */
         /* quindi "poli" viene copiato così come è in "polic" e la procedura passa al poligono successivo */
         if (poli[np].traz==1) { polic[np]=poli[np]; continue; }

         /* Prima determina i veri punti che definiscono il contorno "reagente" */
         /* Calcola la tensione nel punto precedente quello di interesse */
         s1=def.u[0]+(poli[np].y[poli[np].numv-1]-yg)*def.u[1]+(poli[np].x[poli[np].numv-1]-xg)*def.u[2];

         polic[np].numv=0; polic[np].omog=poli[np].omog;
         for (k=0;k<=poli[np].numv-1;k++)
             {
              int km1=k-1;

              if (k==0) km1=poli[np].numv-1;

              /* Calcola la tensione nel punto voluto per prendere decisioni */
              s2=def.u[0]+(poli[np].y[k]-yg)*def.u[1]+(poli[np].x[k]-xg)*def.u[2];

              if (s1*s2<=0.0)
                 {
                  polic[np].x[polic[np].numv]=poli[np].x[k]-s2*(poli[np].x[k]-poli[np].x[km1])/(s2-s1);
                  polic[np].y[polic[np].numv]=poli[np].y[k]-s2*(poli[np].y[k]-poli[np].y[km1])/(s2-s1);
                  polic[np].numv++;
                 }

              if (s2>0.0)
                 {
                  polic[np].x[polic[np].numv]=poli[np].x[k];
                  polic[np].y[polic[np].numv]=poli[np].y[k];
                  polic[np].numv++;
                 }

              /* Fa diventare s2 la tensione del punto precedente per il ciclo successivo */
              s1=s2;
             }
        }

    /* Con i nuovi contorni chiama la funzione che determina le caratteristiche geometriche della sezione reagente */
    geo=calcola_caratt_geometriche (polic);

    /* Risolve l'equazione a 3 incognite */
    parz=geo.ix*geo.area-pow(geo.scx,2);
    def.u[2]=((soll.my*geo.area-soll.n*geo.scy)*parz-(soll.mx*geo.area-soll.n*geo.scx)*(geo.ixy*geo.area-geo.scy*geo.scx))/((geo.iy*geo.area-geo.scy*geo.scy)*parz-pow(geo.ixy*geo.area-geo.scy*geo.scx,2));
    def.u[1]=((soll.mx*geo.area-soll.n*geo.scx)-(geo.ixy*geo.area-geo.scx*geo.scy)*def.u[2])/parz;
    def.u[0]=soll.n/geo.area-def.u[1]*geo.scx/geo.area-def.u[2]*geo.scy/geo.area;

    norma1=sqrt(pow(def.u[0],2)+pow(def.u[1],2)+pow(def.u[2],2));
   }
 while (fabs(norma1-norma0)>1e-3);

 return (def);
}
Rispetto a quanto visto nella parte precedente, come si può vedere, mi sono limitato a riportare la formula che individua il punto a tensione 0.0 all'interno di un lato del poligono per definire il nuovo poligono “reagente”, ed inoltre ho aggiunto il caso in cui uno o più dei poligoni invece che parzializzarsi possa reagire anche a trazione (è il valore di traz, tra i vari dati della struttura dati che definisce ogni singolo poligono). E' una cosa comoda quando si vuol calcolare una sezione metallica composta, o altro.

Il tutto è concentrato tra l'istruzione do e l'istruzione while.
In sintesi:
1) Con le deformazioni dell'iterazione precedente si definisce la reale geometria della sezione reagente (quando si entra per la prima volta nel ciclo le deformazioni valgono 1,0,0 come da riga precedente che le inizializza in tal senso).
2) Si chiama la funzione calcola_caratt_geometriche che determina i valori da inserire nella matrice di rigidezza della sezione
3) Si risolve il sistema lineare 3x3 (senza scomodare alcun metodo, Gauss-Siedel, Kholesky, ecc. Ho riportato materialmente le espressioni definitive avendo risolto prima “a mano” il sistema in maniera simbolica, dunque tre sole formuline)
4) Si calcola la norma della nuova soluzione e la si confronta con la norma della precedente soluzione (nell'istruzione while)
5) Se l'esito della condizione è positivo la funzione termina restituendo la struttura deform alla funzione chiamante, altrimenti il ciclo viene ripetuto fino a convergenza.

Faccio notare che nel determinare le “tensioni” per definire la porzione reagente di poligono, non ho affatto adoperato il fattore omog. Non è necessario infatti che le tensioni siano quelle vere; importante è che il rapporto s2/(s2-s1) sia quello corretto (e lo è visto che parliamo dello stesso poligono ed il fattore omog sarebbe comune), insomma una moltiplicazione in meno.

Altra cosa che faccio notare è che potrebbe capitare, in sezioni costituite da più poligoni, che nella parzializzazione della sezione un intero poligono potrebbe essere tutto in trazione e quindi scomparire. Che succede in quel caso?
Nulla. Perchè, se è vero che nessun vertice viene definito nelle sue coordinate x e y, il numero dei vertici del poligono reagente polic[np].numv impostato inizialmente a 0 dalla funzione rimane tale. E la funzione calcola_caratt_geometriche non si offende affatto di un simile evento, infatti con la riga:

      for (k=0;k<=polic[np].numv-1;k++)
semplicemente l'intero ciclo non viene svolto in quanto la condizione k<=polic[np].numv-1 è subito vera. Ovvero come se il poligono non esistesse.

Terza cosa che faccio notare è che una volta usciti dalla funzione inesorabilmente si perdono anche le caratteristiche statiche della sezione reagente “faticosamente” trovate dall'algoritmo (in quanto variabili locali valide solamente all'interno della funzione). Se queste fossero di interesse poco male. Si estenderebbe la struttura dati struct deform andando a definire all'interno di essa, oltre alla tripletta deformativa, anche scx, scy, ix, iy, ixy. Con una semplice assegnazione di queste variabili poco prima del return (def), ovvero def.scx=geo.scx; ecc. ci si potrà “portare indietro” anche queste informazioni.

Infine una osservazione: Se considerate che questa funzione, comprese le righe di commento, ha circa 70 righe, e che l'altra funzione realmente necessaria, quella di calcolo delle caratteristiche geometriche, ne ha poco meno di 50, possiamo considerare che è realmente “poca cosa” la sola parte risolutiva di un programma che verifica le sezioni in c.a. agli SLE.

Un'ultima porzione di codice, tanto per gradire. La funzione chiamante sarebbe più o meno così:

for (nc=0;nc<=numcomb-1;nc++)
{
 if (soll[nc].tipo<=2) def[nc]=verifica_SLE(soll[nc]);
 
 /* Calcola le tensioni vertice per vertice della sezione */
 for (np=0;np<=4;np++)
     {
      omog=fabs(poli[np].omog);
     
      for (k=0;k<=poli[np].numv-1;k++)
          {
           tens=omog*(def[nc].u[0]+def[nc].u[1]*(poli[np].y[k]-yg)+def[nc].u[2]*(poli[np].x[k]-xg));
           if (tens<0.0 && poli[np].traz==0) scarta il risultato
           else gestisce questo valore per farne ciò che si vuole
          }
     }
 /* Calcola le tensioni armatura per armatura */
 for (k=0;k<=arm.numarm-1;k++)
     {
      tens=arm.omogarm*(def[nc].u[0]+def[nc].u[1]*(arm.y[k]-yg)+def[nc].u[2]*(arm.x[k]-xg));
     ed anche in questo caso si può farne ciò che si vuole
     }
}
Dove numcomb sarebbe il numero di combinazioni cui è sottoposta la sezione. Le scritte dopo il calcolo della tensione (es. scarta il risultato) non fanno parte ovviamente della funzione ma sono state messe lì da me per indicare la possibilità che si vuole.

Ho dimenticato di dire finora, che il codice fin qui presentato dovrebbe essere puro ANSI C e pertanto compilabile da qualsiasi compilatore C, C++.
Vista la presenza di funzioni tipo fabs (valore assoluto di numeri float) e sqrt (radice quadrata) sarà necessario, nel solito header file, inserire il comando:

#include "math.h"

Ovvero includere la libreria matematica standard del C.

E con questo penso di poter chiudere questa prima parte, passando tosto, con le altre prossime parti, alle verifiche SLU.

In questa parte di funzione, quella già pubblicata, il valore di hy è definito correttamente.

for (np=0;np<=4;np++)
     {
      for (k=0;k<=polic[np].numv-1;k++)
          {
           if (k==polic[np].numv-1) kp1=0; else kp1=k+1;

           a=polic[np].x[kp1]-polic[np].x[k];
           d=polic[np].y[kp1]-polic[np].y[k];
           hy=polic[np].y[k]-yg;
           hx=polic[np].x[k]-xg;

           geo.area+=polic[np].omog*a*(hy+d/2);
           geo.scx+=polic[np].omog*a/2*(hy*hy+d*d/3+d*hy);
           geo.scy-=polic[np].omog*d/2*(hx*hx+a*a/3+a*hx);
           geo.ix+=polic[np].omog*a/3*(pow(hy,3)+hy*d*d+3*hy*hy*d/2+pow(d,3)/4);
           geo.iy-=polic[np].omog*d/3*(pow(hx,3)+hx*a*a+3*hx*hx*a/2+pow(a,3)/4);
           geo.ixy+=polic[np].omog*a*(hx/2*(hy*hy+d*d/3+d*hy)+a/2*(hy*hy/2+d*d/4+2*d*hy/3));
          }
     }
In pratica nella formula simbolica non c'è differenza tra y[i ] e hy (mio errore, chiedo scusa), ovvero hy è a tutti gli effetti y[i ].
Valutando però ixy rispetto agli assi baricentrici esso (hy) vale y[i ]-yg

Doppia risposta.
Il momento centrifugo non serve mai. I momenti principali d'inerzia per l'algoritmo proposto sono sostanzialmente inutili. Per un approccio alla "Ferrari" viceversa penso servano.
E' così la sezione reagente omogeneizzata alla fine avrà un baricentro differente dal baricentro della sezione omogeneizzata interamente reagente, e ad ogni ciclo esso si modifica come posizione poichè si modifica la forma della sezione stessa.
Mi fermerei qui, ma mi pare che la domanda ne nasconda un'altra.
Non so se è pertinente, ma ti faccio notare che sia la tripletta deformativa che la tripletta di sollecitazioni è sempre riferita ad un unico punto, il baricentro della sezione omogenea "intera". Inseguire il baricentro della reagente nei suoi spostamenti significherebbe modificare i valori di Mx ed My ad ogni nuova sezione indagata.

Doppia risposta.
Il momento centrifugo non serve mai. I momenti principali d'inerzia per l'algoritmo proposto sono sostanzialmente inutili. Per un approccio alla "Ferrari" viceversa penso servano.

Si servono, come pure il Jxy che determina l'orientamento della terna principale della sezione reagente omogeneizzata.

...
Non so se è pertinente, ma ti faccio notare che sia la tripletta deformativa che la tripletta di sollecitazioni è sempre riferita ad un unico punto, il baricentro della sezione omogenea "intera". Inseguire il baricentro della reagente nei suoi spostamenti significherebbe modificare i valori di Mx ed My ad ogni nuova sezione indagata.

Ecco questa è una cosa interessante: in effetti nel mio algoritmo ad ogni iterata riporto i carichi N, Mx ed My nella terna principale della sezione reagente omogeneizzata. Bravo Zax, mi era sfuggita questa differenza.

Ciao.