SimCenter Forum

Hello,

As an international researcher, I use target spectra that are not available in EE-UQ. It would be helpful if I could upload a .csv file for the user-defined target spectrum, rather than hand typing the values.

As I tried to work around this, I uploaded a .csv file directly to PEER, than downloaded the results. However, when I uploaded this directory to EE-UQ, it was not able to extract the scale factors, requiring that I enter them by hand. It would also be helpful if the scale factors were detected automatically.

Thanks,
Anne

Hello. I am getting a similar error to what Omar had. I loaded the AutoSDA example in a recently downloaded version of EE-UQ. However, the analysis terminates after it can't find the dakota.in file.

Based on Frank's response, I checked whether the main_program.py file was available. The log refers to 'C:/SimCenter/EE-UQ/EE-UQ/applications/createSAM/AutoSDA/main_program.py', whereas my folders only have one level named EE-UQ. I tested whether adding the extra level would make a difference and I got the same issue.

Thanks, Kuanshi. Loading the examples is a cool feature! - though it's nice that there is also a step by step version to make sure the user knows what the inputs are.

Hello,

It looks like there has been a change to the folder structure since the 4.1 example was written. The elCentro.AT2 file is now located in Examples/.archive/ShearBuilding3... instead of Examples/ShearBuilding3... as indicated in the documentation.

https://nheri-simcenter.github.io/EE-UQ-Documentation/common/user_manual/examples/desktop/eeuq-0001/README.html

Thanks,
Anne

Thanks for the follow up. For context, here is my discussion with Jack Baker regarding the benefit of a variable DELTA_MAG value. At this point in time, I do not foresee pursuing this any further.
With regards to looking up the parameters for other ERFs, I may return to the question of mag-area relationships later. Thank you for the tip.

Anne:
I wanted to follow up on my question from the presentation regarding whether each scenario is sampled multiple times.
 
I’m wondering what would be lost if you don’t use multiple samples. My gut reaction is that if you have one rupture that controls the lower tail of the hazard curve, you would have trouble if you end up taking a single realization that is either really low or really high. Taking many samples would do a better job of P(Y>y|scenario). The counter to that concern would be that if you really have all the scenarios represented, you should have pretty similar scenarios that even out the problem of using only one sample per scenario. (E.g. 7.8 and 7.9Mw on San Andreas)
 
Did Mahalia find that using a single sample was comparable to using multiple samples?


Baker:
Good question, and it seems like you have a pretty good handle on it. In general, I would say that there's not a lot of benefit to generating multiple ground motion samples per rupture. More samples can give better resolution of the tail. But I you want more samples, I would prefer to sample more ruptures as well.

That said, the OpenSHA rupture generator actually discretizes the possible ruptures instead of doing a traditional Monte Carlo sampling. So getting more ruptures entails changing some of the OpenSHA parameters (e.g., sampling magnitudes in intervals of 0.05 instead of 0.1). So Mahalia decided that a convenient way to get more samples was just to keep her basic set of ruptures and sample multiple ground motions per rupture. It was a fine thing to do, but I would call it a pragmatic choice rather than a theoretically necessary choice.

Thanks for recompiling in OpenJDK 1.8 - that reduced the level effort for me to get it working.

This is a huge improvement - both with respect to correctly retrieving symmetric background sources for a low max_sources value and for specifying background vs fault sources. Thank you!

Much appreciated!

Great, thank you! I am really looking forward to trying this out.

My first attempt gave me the following error:
Error: A JNI error has occurred, please check your installation and try again
Exception in thread "main" java.lang.UnsupportedClassVersionError: org/designsafe/ci/simcenter/EQHazardCalc has been compiled by a more recent version of the Java Runtime (class file version 56.0), this version of the Java Runtime only recognizes class file versions up to 52.0

I am currently using Java 8. Before I upgrade and risk having trouble using the older EQHazard.jar file, could you confirm whether the older EQHazard file will still work with later Java versions?