... Per fare un esempio concreto, la prima parte di Belfagor genera un accelerogramma in funzione di magnitudo e distanza (e dovrebbe essere lecito) mentre la seconda obbliga la serie a convergere ad uno spettro dato. Se questo spetto è uno spettro derivante da uno studio di risposta locale (EERA, SHAKE) non dovrebbero esserci problemi, mentre i problemi sorgono se i "target" sono spettri di normativa...
mi perdoni, ma lo spettro per studi di RSL, dai programmi tipo EERA/SHAKE, non lo si ricava da una storia temporale in input ? come farebbe la serie a convergere su uno spettro generato da essa stessa? (ho capito male o mi sono perso qualcosa?)
...Riguardo alla scelta degli accelerogrammi reali, credo che non dovrebbe essere difficile per un professionista interrogare per coppie M/D (e magari anche per meccanismo focale e condzioni di sito) le banche dati disponibili on line per l'Italia
adattare un accelerogramma reale ad una situazione stratigrafica diversa da quella originaria dell'evento, non falsificherebbe un po' gli studi di RSL? Non credo siano molti (ma è probabile che sbagli) i casi in cui si dispone di un evento sismico reale, registrato su roccia e/o comunque su materiale a comportamento litoide, da poter utilizzare applicandolo alla base di un pacco sedimentario per poterne studiare la RSL, in condizioni di campo libero o al piano fondale, attraverso programmi 1D (tipo EERA/NERA, Shake/Shake91/Proshake/ ecc.) o 2D (Quad/quadm ecc.) ed ancora meno, forse,sono le storie temporali che abbiano mantenuto inalterato il contenuto in frequenza originario attraversando una serie di sedimenti dall'area ipocentrale fino al luogo di registrazione in superficie. Se dunque io utilizzo un evento reale, anche scalandolo ai valori di accelerazione previsti per la mia (ex) zona, non commetto comunque un errore perchè uso un evento che è già stato filtrato e variato ampiamente magari proprio nelle componenti che potrebbero interessarmi? (o no?!?)
cordiali saluti
