SimCenter Forum

Hi Peng-Yu,

The median_quantity of a component type is ideally based on what is in the building. If you are looking at a particular building and have the design documentation available, you can use that to estimate at least the structural component quantities.

If you are working with a hypothetical building you can either assume a particular design and use that to estimate components, or you can use the normative quantities in FEMA P58 to get a rough estimate.

Thank you for reporting this error!

Please let us know a few more details about your environment to help us figure out where the problem stems from:
- Is this a MacBook Pro? If yes, does it use the new M1 chip?
- Do you have multiple Python versions installed?
- Do you use Anaconda by any chance?

The job completes even if there is an error in the simulation process because the scheduler at TACC does not care if the backend application completed without a problem or terminated due to an error in the process.

The best way to check what happened is to take a look at the log file that is produced by the workflow. There are two .err and two .out files returned by the application; I can see on the screenshot that both of them are available to you. Please send those files to me in an email (adamzs@stanford.edu) - they will provide more information about what happened and we can start a conversation about how to fix it.

The downtime provided by the damage and loss application in the rWHALE v1.1 workflow should be in worker-days.

However, I suggest you migrate to a more recent version of rWHALE. We have been developing a major update over the last year that is accompanied by a desktop application and will become the supported version in the very near future. It also has more detailed documentation available that should facilitate its use. Although it has not been released yet, since its development is open-source, you can access the most recent version of the workflow applications and the documentation in Github.

The documentation is available here: https://nheri-simcenter.github.io/RDT-Documentation/
The User Manual describes the desktop application that is not yet available. The developer manual provides information about building the backend applications and has examples that can help you get started with running them.

The backend applications required to run the regional workflow are available here: https://github.com/NHERI-SimCenter/SimCenterBackendApplications

Are you referring to the DL.json file that is output by rWHALE v1.1 (from early 2019)?

Thank you for joining the PBE office hours today and providing more information about the calculations you would like to run.

Let me confirm a few things and ask a few questions:

- The information you have about the buildings is sufficient to generate the structural model with the MDOF-LU tool.

- The MDOF-LU tool generates a 3D structural model with identical parameters in the two horizontal directions. Hence, you can use two horizontal ground motion components with that tool and you will get structural response is two directions as a result.

- Please tell me more about the ground motion time histories you plan to use. You mentioned that you have about 150K buildings and you wrote in your previous response that you have a pre-defined grid.
    = Does your grid have a separate node for every building? I assume it does not.
    = Do you have your own logic to assign ground motions from grid nodes to building locations or you are planning to use our nearest neighbor approach?
    = Do you plan to run multiple simulations for each building? If yes, how many?
    = How many unique ground motion records do you have in total considering all grid nodes?

- I am also interested in a bit more information about the loss assessment:
    = Are you planning to use the default FEMA P58 fragility groups (i.e., component types) and damage and loss data, or are you using an edited/extended version?
    = My understanding from our discussion is that you have a python script that creates the performance model (i.e., type, location, and quantity of each component) given some metadata about the building. If that is the case, you will be able to feed that script to the workflow and we will create the performance model on the fly for each building as we are doing the calculation of that building.
    = The input files for pelicun are the same in rWHALE and in PBE. I am going to upload the examples from the PBE webinars to the online documentation in the coming days. I'll add a message here with a link to the input file examples when those pages are available.

- Finally, please explain the output information that you would like to have available in the end of the regional assessment.
Since you are interested in using the more detailed FEMA P58 approach, I expect you to have several fragility groups and possibly dozens of performance groups in each building. I suggest to consider the amount of data generated if you keep all samples and think about what is necessary to keep from each individual building's calculation. By default, rWHALE stores the data from the DL_SUMMARY.csv. We can change that if you are interested in keeping more information.
One way to estimate the data size is to take the product of the number of buildings you have, say 150K, and the number of loss samples you would like to run, say 10000. That is 1.5 billion pieces of data if you only keep a single value for each assessment. We have some measures already implemented to keep the file size at bay. I suggest storing the data in 16 bit floating point numbers (instead of the default 64 bit numbers) in a compressed HDF5 format. Even then, keeping a single data point will generate about 1-2 GB of data.
The above example shows that storing hundreds of data points for each realization for each building is probably not feasible. Considering the above, please let us know what outputs you are interested in.

(1)
The directions (the last number in the ID) you use when defining EDPs shall correspond to the directions you use in the Performance Model. If you define the performance model with components in both directions, in general, you are expected to provide EDPs in both directions.

If you only have EDPs in one direction, you can either i) use only one direction and assign all components to that direction in the performance model; or ii) use identical data for the two directions - as you suggested - and have a more realistic performance model with components assigned to two directions in the building. Both approaches are supported and should provide identical results.

Floor accelerations are special because the corresponding components are almost always non-directional, i.e., their damage is controlled by the governing acceleration value across all horizontal directions. In such a case, the direction of the component is not important. In the current release, I recommend using '1' as the direction for such components. In a future release I will make the direction attribute optional, so that these components will not request such information.
When you only have PFA in one direction, use 1-PFA-1-1 (or replace the penultimate ID with the appropriate floor number) and there is no need to provide an identical second column. If you have PFA in more than one direcion, provide all columns; pelicun will take the governing value automatically in the background.

(2)

You are correct, both cases should work as long as you use the RID to evaluate irreparability.

(3)

The warning you receive is posted if the sample covariance matrix of the EDPs is not positive semidefinite. This can typically happen when the number of available samples is less than the number of EDPs. In many of those cases, the covariance matrix is rank-deficient, but still positive semidefinite and we can handle that, so you see no error.
I agree with you that it is unexpected to observe such behavior if you provide 40 samples across 8 EDPs, so this might be a bug.

Would you mind sending me a private message with a sample of the EDP data that leads to this behavior? I could use that to find the bug.

Thanks!

Hi,

Residual story drift is called Residual Interstory Drift and goes by the acronym of RID in pelicun. You can define it for each story in each direction just like you do the PID value. When evaluating irreparability, the governing value is used among the provided RID values in each story. So, if you have only one value for your building, you do not need to create two EDPs using identical drifts in them; it is sufficient to provide a single one, say 1-RID-1-1 for the first story and a similar value for each story.

SP3 works a bit differently. In pelicun, I aim to have a generic framework and treat all EDPs similarly, hence the option to provide RID values for each story. As long as you use RID only to identify irreparability, you can assign the maximum residual drift across all stories to the first story and it will work just fine.

Let me know if you have more questions.