SimCenter Forum

Hi,

Thanks for sharing the file. We are still struggling to identify the issue. From my understanding, the automated process of overwriting the evaluation_concurrency value is exactly the same as the process we tried manually, as shown below.

Hi,

Thank you for the info. We think this number should be 128 instead of 64. While we figure out the solution, can you try the following workaround and let us know if this makes CPU occupied 100%?

1. Modify the number after "asynchronous evaluation_concurrency" in dakota.in from 64 to 128
2. Remove all files and folders in the local working directory except for "dakota.in" and "templatedir"
3. Find the path of the Dakota executable from the preference window of quoFEM. Let us denote this {dakota path}
4. Open the command prompt, cd into the folder where dakota.in is located, and type "{dakota path} dakota.in" (without the quotation marks)

It will run the forward propagation analysis, and the results will be shown in dakotaTab.out.

Thank you,
Sang-ri

Regarding this, is it possible that when we manually tried, dakotaTab.out file was not properly created even though the CPU was occupied 100%? Sorry, I should have asked this earlier.

If unsure, please just let me know. We will continue investigating the issue on our side.

Thanks,
Sang-ri

Many thanks, Sang-ri.

1. I will try to perform the sensitivity analysis on quoFEM as per your instructions. Fingers crossed. Let's see how the sensitivity index values are.
2. For the GP-based surrogate model, could you please suggest which tools will be easier for my case, provided I have no machine learning experience? I am comfortable with Python and MATLAB.

Hi Atish,

Thanks much for clarifying! I hope you get fully recovered soon.

Dealing with high-dimensional input is typically more tricky than high-dimensional output, partially because of the algorithmic challenges (e.g. the number of parameters to be optimized increases), but more importantly, because this means it is likely that the sensitivity index values are very low. In an extreme case, imagine the case where 50 variables equally contribute to the response - the sensitivity of each variable can be less than 0.02, and getting the estimation accuracy of this level will require an enormous number of samples. With 512 samples, the estimation can be significantly perturbed by the sampling variability. However, on the other hand, if only a few variables actually dominate the response of your model, some algorithms can work. The best way to figure it out is to test it out 

To run quoFEM analysis using existing Monte Carlo results, please follow the below:

• In the UQ tab, select "Sensitivity Analysis"-"SimCenterUQ"-"Import Data Files". Set # samples to 512 and import the data files that are prepared following the instructions.
• In the FEM tab, select "none".
• Then, if you click the RV tab, quoFEM should already have auto-populated 50 variables (nothing to change), and finally, in the QoI tab, you can set any name for the output variable and set the length to 4.

Some caveats:

• Please note that the total sensitivity index coming from the algorithm in SimCenterUQ is likely not credible for such high-dimensional inputs (the challenge is in fitting a Gaussian mixture distribution in 50-dim space; see here for the reference). So, only the main index should be useful.
• If you want to get the reliable total index, you may want to run the algorithm in the Dakota engine, but this typically requires a much larger number of simulations and cannot be estimated using pre-simulated samples (need to import the model in FEM tab). But this algorithm is guaranteed to converge to the exact solution if the number of samples is very large
• One more caveat is warranted for the case where the input variables are correlated. If this is the case, please note that the contribution can be "double counted" for the correlated variables, and be careful with the interpretations of Sobol indices.

For the surrogate model, I assume GP in quoFEM would not work - With 512 samples for 50 input dimensions, it will very likely result in overfitting.

Please let me know if something is unclear or have difficulty running the analysis.

Best,
Sang-ri

Dear Sang-ri,

I have updated the QuoFEm application on our HPC and located the config.jason file in the same directory as the QuoFEM executable. Now when I run it with 128 samples all the 128 cores are called and it seems the Opensees analyses are performing successfully, but I get this error at the end and QuoFEm does not give me any results!

Error Running Dakota: Too many processes (128) in wait_setupCurrent limit on processes = 64

And here is the error message that I get from dakota.err file:

Too many processes (128) in wait_setup
Current limit on processes = 64



I am not sure where the problem is, because it should work. Please let me know what you need me to share with you to find the reason for this error.

Hi,

Collecting inventory data is difficult. Although R2D can be used to assess the performance of building inventory stocks in natural hazards, it is not designed to collect building inventory data. You may refer to the testbeds in R2D https://nheri-simcenter.github.io/R2D-Documentation/common/testbeds/sf_bay_area/index.html to see examples of collecting building inventory data. If you would like to study highway transportation infrastructure, the BRIALS-transportation tool (which can be found in the "Tools" drop-down menu) in  R2D can generate the transportation infrastructure data for HAZUS-style earthquake performance assessment. Please let us know if you need further assistance.

Best,

Jinyan