Home GeoForum Forums Geologia & Professione RSL - Laboratorio di Risposta Sismica Locale Rexel

Questo è poco ma sicuro. Nella pianura dove hai solo argille e sabbie se non utilizzi anche i picchi <2 non vai da nessuna parte. Importante ovviamente è sempre l'"aggancio" a una stratigrafia attendibile: se hai solo un picco a 1-2 Hz (come succede ad esempio nella zona del terremoto emiliano-mantovano) hai poco da interpretare

Mc condivido le tue perplessità!
Il problema credo che sia trasferibile a tutte le zone a medio-bassa pericolosità sismica perché Rexel (forse per eccesso di accelerogrammi nei database) sembra talora non lasciare scelta spingendoci, per riuscire ad estrarre “qualcosa” spesso poco significativa, ad aumentare M e talora anche R (per garantire la spettro-compatibilità). Inoltre nello specifico, la zona romana è un po’ particolare, appare infatti accerchiata da due settori sismogenetici uno vicino, quello albano, ed uno lontano, quello appenninico, e risente quindi di terremoti con M ed R medio-basse (Colli Albani) e terremoti con M e R elevate (Appennino), questo assetto probabilmente determina grossi problemi procedurali nell'utilizzo di Rexel e impone di fare scelte molto drastiche su M-R per poter ricavare la fantomatica settupla (forse in queste circostanze sarebbe il caso di implementare due insiemi di accelerogrammi distinti per M-R, sempre che per M-R bassi riusciamo ad estrarre qualcosa!)

A norma di legge implementare le settuple nella RSL è inutile (ad eccezione del solito caso particolare mai utilizzato nella pratica comune o delle idee dell’eventuale controllore) e il loro utilizzo è legato ad una interpretazione errata della norma. Almeno per progetti normali sarebbe molto meglio non avere la possibilità di scegliere ed avere per una data area e per ciascun tempo di ritorno 2-3 accelerogrammi da implementare negli studi di RSL (almeno uno dei tanti problemi della RSL sarebbe risolto in modo univoco e ci libereremmo della settupla e di Rexel).

La zona specifica di cui parlo è Monterotondo Scalo, a NE di roma.
Secondo il modello di disaggregazione INGV esaminato M va da 4 a 5.5 e R da 0 a 20 al massimo. L'intervallo è quindi limitato.
Il rischio causato dai grandi terremoti dell'appennino abruzzese e umbro marchigiano è nulllo o trascurabile, meno dell'1% quindi questo contributo va escluso.
Non se ne parla di trovare settuple di quel tipo, specialmente con Tr=712 (CU III).
Per usare time histories bisogna cercarle a mano nell'archivio Itaca o nel database di rexel, usare la funzione filtro di excel, estrarre dati degli spettri, portarli su grafico excel e paragonarne la spettrocompatibilità ad occhio.
Con il meccanismo di sorgente di STRATA la spettro compatibilità è assicurata solo se M=6, piccole distanze e sismi superficiali, il che suggerirebbe che qualcosa non va forse nel modello INGV, dato che in quella zona come dici M=6 non è previsto.
In questi casi se il committente lo pretende bisogna cercare le time histories a mano, altrimenti dato che in questo caso la RSL non sarebbe neanche obbligatoria secondo il DGR Reg. Lazio, RVT o sorgente e specialmente quest'ultimo non credo causino problemi, una volta argomentato che esiste spettrocompatibilità nell'input.
L'unico argomento a favore della settupla attualmente, escludendo le analisi con integrazione sull'accelerogramma, è che garantisce una certa variabilità nell'input. Ma come stiamo osservando il risultato è '0 compatible sets found'.

Un altra procedura possibile sempre con STRATA, se si vuole eseguire tutto nell'ambito dello stesso programma, è quella di creare un moto con meccanismo di sorgente con M e R modali da disaggregazione e altri dati di letteratura (profondità superficiale, stress drop contenuto), estrarre la time history al tetto del bedrock, normalizzarla alla PGA di normativa e utilizzarla come moto di input sempre che segua i criteri di spettro compatibilità previsti dalla normativa.

Ma a questo punto allora è forse meglio utilizzare Belfagor di Mucciarelli che con M e R rispetta i parametri essenziali di sorgente come da disaggregazione e, come dimostrato dalla letteratura, fornisce ancora risultati ottimi se paragonato alle time histories spettro compatibili.

Per Belfagor torniamo al punto di partenza. Se crea accelerogrammi sintetici ok. Se crea invece a. arificiali le ntc2008 ne vietano l'utilizzo per problemi di RSL

Belfagor non genera accelerogrammi artificiali perché questi non utilizzano come input altre informazioni che quelle definite da uno spettro, che convoglia implicitamente soltanto i meccanismi di sorgente che generano il moto sismico in questione.

Belfagor al contrario utilizza i parametri M e R, parametri relativi alle singole sorgenti, per generare il moto di input. Per cui il risultato è sicuramente più vicino ad un accelerogramma sintetico che ad un accelerogramma artificiale.
Inoltre, poiché la disaggregazione, che è la procedura alla base della scelta degli accelerogrammi naturali, si basa esclusivamente sui parametri di sorgente M e R, la logica porterebbe di nuovo a comprendere Belfagor tra i generatori di sismogrammi sintetici.

Il generatore di Strata è sicuramente più completo per quanto attiene al meccanismo di sorgente ma non sempre sono a disposizione le informazioni richieste su profondità, stress drop, leggi di attenuazione ecc.

Ho provato a reperire manualmente tramite database ITACA gli accelerogrammi potenzialmente compatibili.
Prima di tutto la libreira scaricata assieme a rexel è in formato Matlab, quindi non utilizzbile.
La funzione di ricerca del database ITACA online invece va bene, però utto il lavoro nel mio caso è stato inutile, dato che gli accelerogrammi selezionati erano tutti chiaramente spettro INcompatabili anche dopo moltiplicazione con uno scalare, anche se M, R, tipo di meccanismo e PGA erano gli stessi dello spettro di normativa. Questo tipo di ricerca può quindi andare avanti per giorni e giorni.

L'unica maniera con cui risolvere sicuramente il caso in tempi decenti è utilizzare gli algoritmi di spectral matching commerciali, tipo Seismomatch, che modificano il sengale in ampiezza e in frequenza.

NB, il programma non sta inserendo immagini, per adesso bisogna cliccare i links per vederle.

Ecco l'esempio, nella prima figura gli spettri non compatibili con medesima PGA del target e pertanto irrimediabilmente non-compatibilizzabili con un semplice prodotto scalare.

[img]http://imageshack.com/a/img823/6517/r1sg.jpg [/img]

Nella seconda figura gli spettri ( e i relativi segnali temporali) sono stati resi compatibili con algoritmi di spectral matching piuttosto sofisticati. Pur essendo al procedura formalmente ineccepibile, questi algoritmi però trasformano la forma dell'onda sismica per cui sostanzialmente le caratteristiche variano.

[img]http://imageshack.com/a/img541/2875/ztlr.jpg [/img]

Infine, la media spettrale molto fedele al target

[img]http://imageshack.com/a/img854/1756/6nfb.jpg [/img]

Nel sito in questione, anche volendo provare ad estendere i parametri di disaggregazione oltre il ragionevole, non si reperiscono accelerogrammi spettrocompatibii, per cui i metodi sopra illustrati mi sembrano gli unici.
Molto laborioso il reperimento di serie temporali compatibili con la disaggregazione e sottoposte poi a spectral matching in ampiezza e frequenza.
Molto spedito il metodo con spettri artificiali, spedito lo spettro sintetico.

Non so se avete altre proposte.

Volevo sciogliere un paio di dubbi relativalente agli accelerogrammi scalati e non scalati ricavati con Rexel.
Al di là della traformazione (m/s2) => (g), nel caso di acc. non scalati io conduco la successiva elaborazione con Strata assumendo il fattore di scala pari a 1, senza cioè ricondurre il valore di PGA al valore di base fornito dalle NTC. Vedo però che qualcuno applica al contrario un fattore di scala in modo da ottenere il valore di PGA di base.
Per gli accelerogrammi scalati invece io applico semplicemente i valori dei fattori di scala forniti da Rexel (variabili da accelerogramma a accelerogramma), senza poi ricondurre il valore di PGA al valore base fornito dalle NTC.

Datemi per cortesia un vs. parere. Grazie