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
16
Earthquake Engineering (EE-UQ) / Re: retrieving tmp files from DesignSafe
« on: October 02, 2021, 07:55:37 PM »
Excellent, thanks! Yes, an option to include the periods.out file would be great. I currently also use the response.csv file but if the new EE-UQ release includes a corrected Save Data button (such that the output includes record identifiers) then I would have everything I need.

17
Earthquake Engineering (EE-UQ) / Re: pushover results for AutoSDA
« on: October 01, 2021, 06:19:29 PM »
Thanks!

18
Earthquake Engineering (EE-UQ) / retrieving tmp files from DesignSafe
« on: October 01, 2021, 12:42:32 AM »
Hello,

When I run AutoSDA locally, I save the entire tmp.SimCenter folder so that I can retrieve the geometry, loading, periods, etc. Is it possible to retrieve this whole folder when running it on DesignSafe?

Also, I got an error when retrieving my results. Do you recognize the error: Error Running Dakota: -- Expected 14 function value(s) but found 5?

Thanks,
Anne

19
Earthquake Engineering (EE-UQ) / Re: pushover results for AutoSDA
« on: September 30, 2021, 10:22:23 PM »
Thanks, Kuanshi.

The instructions for running it in the command prompt helped solve the issue. The script you uploaded was identical to what I had been using yesterday, when EE-UQ would successfully run but not output the pushover results. When I tried to run it in the command prompt, the script couldn't launch because I didn't have OpenSees installed as a standalone program. Once I installed it on my computer and could get the script to run via the command prompt, the pushover analysis also worked successfully via the EE-UQ interface. However, I am quite surprised at the solution, because AutoSDA has been successfully launching OpenSees from EE-UQ for everything else, so I'm not sure why the installation would matter for the pushover analysis.

Today Adam and I discussed the fact that the design process is reinitiated for every ground motion. He said he would discuss his ideas with you but I wanted to add one additional feature request: it would be great if there were a radio button in the EE-UQ interface that allowed you to include a pushover analysis during the design process, if desired.

Thanks!
Anne

20
Earthquake Engineering (EE-UQ) / Re: pushover results for AutoSDA
« on: September 29, 2021, 07:33:10 PM »
Thanks, Kuanshi!

I couldn't get it to work, either with the if statement or the first way you described. However, I also didn't get an error. Could it be that it ran correctly but the results didn't get saved? Here is a link to the directories: https://drive.google.com/drive/folders/185v1cHEr1WSitlreTpHo_PkO4pCHfIvU?usp=sharing

In case this continues to need more troubleshooting on my end, how can I run it in the command line so that I can get more feedback on what might be going wrong?

Also, I see that my question about the design wasn't clear. I agree that the structure will always be the same, as the design method is not dependent on the selected ground motion. But is the process of design being re-initiated for every workdir? i.e., is line 79 in main_program part of a loop for all the ground motions or does it occur only once, after which the results are copied over into every workdir?

Thanks,
Anne


21
Earthquake Engineering (EE-UQ) / Re: pushover results for AutoSDA
« on: September 28, 2021, 07:48:20 PM »
Thanks, Kuanshi! Does this mean that it would produce the same results in the individual workdir for each selected ground motion? Based on the comment about how long it can take, is there a way to make it only run for the first workdir? I tried setting up an if statement but I had a hard time following how it iterates through each ground motion and what variables I could use to identify whether I wanted the pushover analysis to run.

Speaking of which, at first glance it appears that it might be redesigning the building for every selected ground motion. If this is correct, is there a way to make it more efficient, such as run the design and everything else that is not gm specific (e.g. the pushoever) first and then copy over everything that will be duplicated?

Thanks,
Anne

22
Earthquake Engineering (EE-UQ) / pushover results for AutoSDA
« on: September 28, 2021, 12:12:13 AM »
Hello,

Is there a way to get pushover results from the AutoSDA analysis? It looks like they have been commented out of the main_program script. Speaking of which, I'm a little surprised to see that the Eigen Value Analysis has also been commented out, given that I am still getting eigen value results, such as the first few periods of the building.

If you could help me confirm how to get all the results, in particular the pushoever curve, I would appreciate it.

Thanks,
Anne

23
Regional Hazard Simulation (R2D, rWhale) / Re: newest openquake implementation
« on: September 22, 2021, 06:19:26 PM »
Hi Kuanshi,

Nice, thanks for having already been proactively thinking about/working on this! I don't know how most uses interact with openquake/local features. But I can definitely imagine it - in my case, that would mean having the custom gmms added in the local openquake version, without needing to remember to add them in the R2D version. Or having two local versions - one so I can replicate Nick's results on the old version and one to replicate the NSHM results on the new version.

One of the biggest benefits that I see is that it might allow me to switch back and forth between running openquake from the command line and from R2D, without needing to delete the db.sqlite3 file. Do you think that would be possible with what you are describing? For me, the biggest benefit of R2D will be when I can run it on DesignSafe for huge jobs, while there are helpful things about running openquake locally without R2D (such as being able to easily manipulate the .ini file, e.g., listing multiple poe values).

Thanks,
Anne

24
Regional Hazard Simulation (R2D, rWhale) / newest openquake implementation
« on: September 21, 2021, 08:45:19 PM »
Hi Kuanshi,

Now that I have confirmed that openquake is producing the same results, I'm switching to using the standard gmms that the New Zealand NSHM is going to use (not the custom GNS ones I recently sent you). In particular, the Kuehn, Parker, and Abrahamson&Gulerce subduction models from 2020, all available here: https://github.com/gem/oq-engine/tree/master/openquake/hazardlib/gsim.

They were not automatically included in the openquake version that was packaged in the R2D build so I copied them over. However, openquake recently reorganized somethings and it looks like the R2D build cannot accommodate them. (For example, they require the base.add_alias function from the same folder I linked above.)

Would it be possible to include the openquake version that is on github, instead of what we are currently using? (I recall at one point I asked you to go back to a previous version - maybe that is what is included now.) Unfortunately, replacing the openquake folder wasn't sufficient because FetchOpenQuake calls openquake.commands.run.run, which is no longer included.

Thanks,
Anne

25
Regional Hazard Simulation (R2D, rWhale) / Re: openquake poe values
« on: September 21, 2021, 05:53:23 PM »
Great, thanks!

After a little more trial and error, I'm still not sure what the best option is. Here is the line I used for what I described above:

'poes': 1 - np.exp(-scen_info['EqRupture']['TimeSpan']*(1.0/scen_info['EqRupture'].get('ReturnPeriod', 100)))

But it gives a lot of significant digits for 500yr RP in 50 years instead of 0.1, as I would prefer. I can't think of a good way to generically round it to the appropriate number of decimal places (perhaps to one significant digit, e.g., 0.1 and 0.002)? For now I am hardcoding 0.1 into the backend script.

26
Regional Hazard Simulation (R2D, rWhale) / openquake poe values
« on: September 21, 2021, 12:24:58 AM »
Hi Kuanshi,

I just discovered that the poe terms in the oq .ini files is for the investigation time, not annual. Could you update line 238 in FetchOpenQuake.py to be (something like):

1 - np.exp(-n_years * (1/RP))

Thanks,
Anne

27
Regional Hazard Simulation (R2D, rWhale) / backarc term in openquake site file
« on: September 21, 2021, 12:10:21 AM »
Hello Kuanshi,

I've been crosschecking the new oq results against previous results. It turns out that the backarc term that automatically gets included in the OpenQuakeSiteFile.csv is messing up the Abrahamson GMM for subduction interface ruptures. In future builds, could you remove line 217 from CreateStation.py?

Thanks,
Anne

28
Earthquake Engineering (EE-UQ) / Re: AutoSDA results for 10+ stories
« on: September 20, 2021, 11:23:51 PM »
This worked perfectly, thank you! I'm not super familiar with opensees recorders. I see the lines in the commit where you added the roof node for roof drifts. But how did these few changes in the main_program.py file actually tell opensees to record the drifts?

29
Earthquake Engineering (EE-UQ) / AutoSDA results for 10+ stories
« on: September 18, 2021, 12:22:48 AM »
Hello,

It looks like the AutoSDA edps above the 10th story are getting collected incorrectly. The attached results have identical edp for the 11-15th and the 1-5th stories. See this (unrestricted) folder for the backend files: https://drive.google.com/drive/folders/1ZjFFgGKpcCBHp27bh84q2LogAQgC1jKI?usp=sharing

Also, would it be possible to collect the peak drifts, in addition to the displacements and accelerations?

Thanks,
Anne

30
Earthquake Engineering (EE-UQ) / Re: AutoSDA's default .tcl file
« on: September 17, 2021, 09:22:23 PM »
Great, thanks for confirming. Given that fact, I think it would be more intuitive if the .tcl file for any AutoSDA analysis were stored in and automatically called from C:\SimCenter\EE-UQ\EE-UQ\applications\createSAM\AutoSDA

However, I realize that this might be harder to implement than the current solution of auto-loading the file as part of the example folder. An alternative would be to include a note in the AutoSDA documentation, saying that the relevant .tcl file for any AutoSDA analysis can be found in the example folder.

Thanks,
Anne

Pages: 1 [2] 3 4 5