SimCenter Forum

Hi,

Thanks much for sharing the files!

Can you please move the quoFEM folder (with the exe file in it) to some folder under C drive? I assume it is currently under D drive, but the local jobs directory is by default in C drive. This mismatch had caused some permission issues before. Alternatively, you can try changing the local jobs directory to some folder under D drive.

If it still does not work, can you please share two screenshots that show the list of files in templatedir and workdir.1, respectively?

Thank you,
Sang-ri

Thank you so much for revisiting the previous tests! The test was immensely helpful as it clarified that the limitation comes from the UQ engine rather than the interface.

I apologize for the late reply - I was out of the office last week. In the meantime, our team made some effort to find a workaround, but unfortunately, we could not find an immediate solution, especially without being able to reproduce the error. Also, the source of issue is related to the internal function of Dakota program, which is slightly beyond SimCenter's development focus. It seems like we cannot provide a solution at this point.

However, we will keep you posted in case of further updates.

Thanks again,
Sang-ri

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

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

Hi,

Thanks for the post! I have some quick questions before going into details.

1. Can you let me know the dimensions of the model input (=number of the parameters whose contribution to the responses will be inspected) and output (=number of the responses from a simulation run) of interest? I am assuming that the output dimension is 50, but I just wanted to clarify. I believe the number of simulations you ran is 512.

2. Regarding the sensitivity analysis that did not converge, was it performed using quoFEM?

Thanks,
Sang-ri

Hi, thank you for letting us know of this! We have now updated the meeting link.

I see, {python path} should also be "C:/quoFEM_Windows_Download/applications/python/python". Sorry for the confusion.