Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Messages - Anne Hulsey

Pages: 1 2 3 [4] 5

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, Kuanshi!

I misunderstood how loading examples works - I thought that it meant that I didn't have to do anything else before hitting "Run". It ran correctly once I followed your suggestion. Perhaps there could be a note about it in the log for loading the example. This is what it currently says:

* Loading example E4: AutoSDA and Nonlinear Response Analysis
* Loading Example file. Wait till Done Loading appears before progressing.
* Done loading. Click on the 'RUN' button to run an analysis.

The last line could be:
* Done loading. Click on the 'Select Ground Motions' button in the EVT panel, then the 'RUN' button to run an analysis.

While the example did successfully run once, every subsequent time I've tried it has resulted in a Not Responding message and needing for force close EE-UQ. I will keep troubleshooting and start a new thread if I am unable to figure it out.


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 file.

Based on Frank's response, I checked whether the file was available. The log refers to 'C:/SimCenter/EE-UQ/EE-UQ/applications/createSAM/AutoSDA/', 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.

Installation / Re: EE-UQ interface doesn't fit on screen
« on: July 02, 2021, 09:12:07 PM »
Thanks, Kuanshi. Yes, adjusting the display settings made it better. I kept the same resolution but changed the scaling from the recommended 150% down to 100%. I'll just toggle back and forth whenever I want to use SimCenter products.

Regarding using the mouse to resize horizontally or vertically, there is a limit on how small it can get. Also, sometimes resizing (especially pulling up from the top edge) makes the window disappear. The icon remains on the task bar but I can't view the window again unless I close it and restart.


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.

Installation / Re: EE-UQ interface doesn't fit on screen
« on: July 02, 2021, 07:03:29 PM »
Thanks for the quick reply. Restarting with the monitor unplugged gives the same result.

Earthquake Engineering (EE-UQ) / update documentation for Examples
« on: July 02, 2021, 06:58:09 PM »

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.


Installation / EE-UQ interface doesn't fit on screen
« on: July 02, 2021, 06:53:17 PM »

I just installed EE-UQ on a Windows laptop connected to a second monitor. When the interface opens, it is far too large for the screen. When I click the maximize, the interface doesn't scale well. When the log window pops up, it is not centered on the screen and I can't reach the top bar to move it. When the results are viewed, the graph is either too small to see (if the window is maximized) or the window is so large that I cannot see all the features.

Could you give any advice on how to get it to fit the screen better? Let me know if any details about the screen configuration would be helpful.


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.

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?

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.

Nice update. Thanks!

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!

This is excellent. For consistency with the rest of my work, I would appreciate having UCERF2 as well.

If the sample will be released by September, no need to share it in advance. If not, I will request it when I am ready to use it.

Much appreciated!

Excellent!! This will massively streamline my work flow for creating ground motion maps for an aftershock.

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?

Pages: 1 2 3 [4] 5