SimCenter Forum

Can you change "C:/quoFEM_Windows_Download\applications\opensees\bin" to "C:/quoFEM_Windows_Download\applications\opensees\bin\OpenSees" and see if it works?

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

Awesome, thanks for the update! We will get back to your new question soon

Hi Gaurav,

Regarding the third question, quoFEM and EE-UQ have an alternative surrogate modeling method (using Gaussian Process) which also displays LOOCV metrics that you may find interesting. See example here

Thanks,
Sang-ri

Awesome, thanks again for reporting this.

Hello Gaurav,

Thanks for reporting the issue! Can you please share the input/output files, or part of them, to help us reproduce the error? When we tested it on our side, it ran fine with the attached files. A slight difference in the file format may have caused the error.

We are indeed working on improving the documentation & error display, and your feedback like this is much appreciated.

Thanks,
Sang-ri

OpenSeesPy now works on DesignSafe. Please let us know if Example 2 still gives an error.

Thanks,
Sang-ri

Hello Pellumb, thanks for the question and for sharing the results!

It is likely that different algorithms will produce slightly different results because of the (1) sampling variability and (2) different assumptions that each algorithm makes. In this case, because you were able to run enough number of simulations, the results from dakota engine are likely more accurate and thus preferred.

The method in the dakota engine ( efficient monte-carlo ) is asymptotically unbiased, meaning it is guaranteed to converge to the 'exact' values when a large number of samples are available. If you specify 1500 samples, the results should be pretty accurate in most applications.

The approach in SimCenterUQ engine ( PM-GSA ), on the other hand, introduces more assumptions to achieve faster convergence. Because of these assumptions, even when we run enough number of simulations, the results may still be biased. However, there are situations where this method is preferred to the one above, for example: (1) when the simulation model is very expensive, so only a limited number of samples (maybe a few hundred) are available; (2) when the random variables are correlated; (3) when Monte Carlo samples are already available, so you want to directly import the dataset instead of running simulations again; (4) when you would like to calculate 'joint sensitivity indices' or 'higher-order sensitivity indices'

Hope this will help!

Sang-ri