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 - AakashBS

Pages: [1] 2
The files shared in this post pertain to using quoFEM to conduct global sensitivity analysis and Bayesian calibration of a liquefaction-capable material model available in OpenSees, and probabilistic prediction of lateral spreading due to seismic soil liquefaction employing the calibrated material model.

On unzipping the attached folder, there will be three directories, each of which contains all the files necessary to run an analysis in quoFEM. The shared files have been tested on quoFEM Version 3.1.0

Refer to the attached preprint for a detailed description of the problem and the models used. Citation information will be provided once available.

Each model evaluation during the sensitivity analysis and calibration phase takes about 1 minute. Each model evaluation for predicting the lateral spreading takes about 20 minutes to complete. (Runtimes on a 2020 MacBook Pro with 2 GHz Intel Core i5 processor with 32 GB memory).

You can also try increasing the standard deviation to have a wider prior, as 10% coefficient of variation results in a narrow, informative prior. If the predictions from the model evaluated at the samples drawn from the prior are all too far away from the data, this can cause numerical difficulties during the algorithm run.

Using a log-normal prior instead of a normal prior will ensure that the input parameter values are admissible, if the parameters should always have positive values.

The most common reason for this to happen is that the number of requested samples is small in comparison to the number of parameters to be estimated. This can make the sample covariance matrix ill-conditioned, which causes difficulties when generating new sample points. As a result, during subsequent stages of the TMCMC algorithm, new sample points might not be accepted and each workdir will end up with the same parameter value.

However, since increasing the sample size to a larger number did not resolve the problem, I am not sure what could be the cause of the issue.. It would help if I can reproduce the issue, to diagnose the source of the problem. Sharing the model script or the contents of one of the workdirs will let me recreate the analysis on my machine and help identify the cause.

Can you please share your model script, in a private message if you would prefer, so that I can reproduce the issue and try a few solutions?

Thank you for sharing the file. Please increase the number of samples requested to 100 and try again.


Can you please share the "logFileTMCMC.txt" located in "~/Documents/quoFEM/LocalWorkDir/tmp.SimCenter"?

Best regards,


Can you try running again after removing the blank space at the end of the name of the RV "gKLim " (lines 143 and 146 in the input2.json file)?

If this did not resolve the issue, we might need some more information.


Uncertainty Quantification (quoFEM) / Re: QuoFem Parameter Estimation
« on: January 07, 2022, 10:59:09 PM »
Hello Josh,

By observing the results, we think there could be two potential issues:

1) The model might not be numerically stable (going by the large changes in the MaxStrength residuals for small changes in the parameter values, as seen in evaluation 2 vs all the others).

2) A gradient-based (i.e., local) optimization algorithm is used to perform parameter estimation. This algorithm works for continuously differentiable objective functions and will converge to a local minimum. It seems that there are multiple minima even in a very small range of the parameter values (caused by noisy MaxStrength results) - see attachment. That is why the algorithm is taking small steps and converging to a local optimum in the vicinity of the start point of the search.

We recommend that you first perform a parameter study (for e.g. forward propagation using LHS in quoFEM) to identify any such discontinuity/noisiness in the model outputs before performing a parameter estimation study. Sometimes the noisy behavior indicates that the model can be improved (for example by setting stricter convergence tolerance, if feasible). If this is not feasible, you can perform a Global Sensitivity Analysis using quoFEM and decide to not calibrate the values of parameters that are causing this noisy behavior, provided that parameter has a low sensitivity index. If the output is sensitive to the parameter which is causing the noisy behavior, then your option is to use a global parameter estimation method. Currently, you can use the TMCMC algorithm in quoFEM to perform probabilistic parameter estimation, which works for such noisy landscapes too. The trade-off is that it will require a large number of model evaluations, in comparison to a local search method. But you can use DesignSafe's computational resources to overcome this issue. In the future, we might make other global deterministic parameter estimation methods available in quoFEM.

P.S. Please double check if the MaxStrength values are being returned correctly. We ran simulations with the model script that you had previously shared with us over a large range of the parameter values and the MaxStrength residuals were around -4.

Aakash and Sang-ri

Uncertainty Quantification (quoFEM) / Re: Optimal parameters values
« on: October 18, 2021, 05:35:29 PM »
Thanks for sharing the files, Rashad.

The model script was running the OpenSees analysis successfully, but the issue was caused by the post-processing script. This post-processing script uses the QoI name that you provide in quoFEM to extract the corresponding output. In this case, the QoI name provided was 'Node_16_Disp_1', so the script was trying to find the 1st component of the displacement of node 16. But, since there were only 6 nodes in the model, the post-processing script was unable to find a node with the tag 16 and was instead simply writing an output of 0.

There are two ways you can fix this issue -

a) Simply rename the recorder output file name to 'results.out' instead of 'Model1.out' in Line 74 of the 'Model1.tcl' script.
Then, the post-processing script is not necessary, and should not be provided in the FEM panel of quoFEM. If a post-processing script is not being used, then you are also free to set any valid variable name in the QoI panel.

b) Alternatively, if you would like to use this post-processing script, then you should
  • Change the variable name to 'Node_2_Disp_1' in the QoI panel of quoFEM.
  • Remove the 'wipe' command in Line 87 of the 'Model1.tcl' script.

Uncertainty Quantification (quoFEM) / Re: Optimal parameters values
« on: October 15, 2021, 09:47:28 PM »
Hello Rashad,

1) The parameter estimation methods require data to be provided (either from experiments or otherwise), since the data are necessary to define how 'good' different parameter values are relative to each other.

In the absence of data, if there are no recommendations in literature of good parameter values for your problem, you might want to first explore how the parameter values map to the outputs to get an idea if the parameter values that you have chosen are satisfactory. You can do this by performing either forward propagation or global sensitivity analysis in quoFEM by defining uniform distributions for the parameters in the RV panel and setting wide bounds corresponding to the range of values that you want to explore. Inspecting the scatter plots of the parameter values vs. the outputs in quoFEM's RES panel after the analysis (as in the example shown in the screenshot attached) will show you the range of outputs that are produced corresponding to different parameter values. Sensitivity analysis results will also tell you how much influence each of the parameters in the range that you have defined will have on the outputs from your model. You can check whether the parameter values you have used can produce the outputs that you want. If not, try expanding the range of the parameter values and run the forward propagation/sensitivity analysis again. You can then pick a particular target output value from this plot, provide it as data and perform parameter estimation in quoFEM.

Once you have chosen some parameter values, you can specify a narrow Normal distribution centered at those parameter values and run a forward propagation analysis. You can check the outputs produced and judge if the parameter values are satisfactory.

2) If the finite element analysis is running successfully, then the parameter estimation methods should find parameter values that produce outputs from your model that best match the data. If your analysis is running successfully but you still are having any issues performing parameter estimation in quoFEM, please get back to us with more details (the 'ops.out' and 'dakota.out' files) and we can help resolve the issue.


Thanks for sharing the files, Rashad. I can confirm that you have set up the problem in the GUI correctly, and quoFEM is functioning correctly. The problem, as you also identified, was in the convergence of the model in OpenSees.

Thank you,
I have download quoFEM 2.3 version, I wanted to check the app before I check my model parameters. then I logged in and hit “run” for a selected example in the category, it showed me this "No dakota. err file - dakota did not run- problem with dakota setup or the applications failed with inputs provided" however, in the old version (2.2) it works well. please what's the problem is?

A solution to this problem is available here -

The calibration data is provided correctly (assuming the units are consistent with your problem).

1- Can you share the 'dakota.out', 'dakotaTab.out', 'dakota.err', and '' files in the 'tmp.SimCenter' folder under your Local Work Directory?

2- This is normal. When you load an example from the menu, the information required to populate all the panels in the quoFEM GUI is read in from a json file. You can also create json files like this by using the 'Save As' option in the 'File' menu, once you have filled all the required inputs to define the problem. Then, you can load the json file using the 'Open' option in the 'File' menu. This will automatically fill in all the fields.

Uncertainty Quantification (quoFEM) / Re: Running on quoFEM
« on: September 22, 2021, 08:27:53 PM »
Summary of the issue for users of quoFEM Version 2.3 on Windows:

quoFEM might not find the right path to the Python executable on Windows, resulting in this error message when an example is run - "No dakota.err file - dakota did not run- problem with dakota setup or the applications failed with inputs provided".

The workaround to this bug is to create a registry item for ‘pythonExePath’ under ‘Computer\HKEY_CURRENT_USER\Software\SimCenter\Common’, as described in this chain.

This bug will be fixed in the next release of quoFEM, expected at the end of September/early October 2021. An update will be posted here after the release.

Uncertainty Quantification (quoFEM) / Re: Running on quoFEM
« on: September 22, 2021, 08:22:48 PM »

Thank you for working with us while we located this bug. Sorry for the inconvenience!


Pages: [1] 2