Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

FOSM: prior parameter SDs potential read as variance #151

Closed
Smith0710 opened this issue Dec 10, 2021 · 5 comments
Closed

FOSM: prior parameter SDs potential read as variance #151

Smith0710 opened this issue Dec 10, 2021 · 5 comments

Comments

@Smith0710
Copy link

Hi

For a FOSM analysis, I am supplying the prior parameter uncertainties in an uncertainty file (uploaded) which contains a single data block listing the prior parameter standard deviations. The FOSM analysis does not progress well and upon examining the pest.par.usum.csv result (uploaded) the prior parameter standard deviations values are all equal to the square root of the values supplied in the uncertainty file, perhaps suggesting they are being read as variance instead of standard deviations.

Specific yield and recharge parameters in my example have standard deviation values less than one, such that square rooting those values results negative values entering the distribution range. If correct, this may be causing the failed runs that occur during FOSM with Monte Carlo analysis.

Thanks.

prior_par.zip
pest.par.usum.csv

@jtwhite79
Copy link
Collaborator

You are correct that the standard deviation wasnt being handled correctly (and has been fixed with release 5.1.7). But also know that with parameter estimation plus fosm process is pestpp-glm, its entirely possible that the upper and/or lower confidence intervals may not be plausible - this is because fosm is using the estimated (or for prior, initial) parameter value as the mean and the hanging the implied gaussian distribution off this mean. So if your parameter uncertainty is larger than the mean, then you can negative lower confidence limits. Two more points: 0) the fosm parameter summary is reported in log space if the parameter is log transformed (this can also confuse..) and 1) the posterior fosm monte carlo process will enforce parameter bounds to keep parameters in the plausible space...

@Smith0710
Copy link
Author

Thanks for this advice @jtwhite79.

I have the current release 5.1.6 installed. Is 5.1.7 also available now? In the meantime, would squaring the standard deviations in my uncertainty file work as a temporary fix or are there other unintended implications of doing this?

I have been testing the following approach and would appreciated any further pointers:

  • In the model calibration all parameters are log transformed.
  • If parameters are left as log transformed in the FOSM analysis, then the SD values pertain to the log transforms, making the log transform distributions gaussian but not the parameter distributions (which can have undesired or unintended shapes).
  • To get better control over the prior uncertainties, I change the parameter transformations to 'none' for the FOSM analysis and setup the uncertainty file so that the parameter distributions are gaussian about the calibrated values supplied in the PEST control file.
  • Using this approach, I have more control in setting the prior parameter uncertainties and can avoid parameter distributions encroaching into 'negative' space.

Can you see potential problems with this approach?

Thanks again for your help.

@jtwhite79
Copy link
Collaborator

Its a pre-release for now...

https://github.com/usgs/pestpp/releases/tag/5.1.7

I would be careful swapping prior conceptualizations midstream. For example, in the parameter estimation side, the log transform is used when calculating the parameter perturbation values, which means the sensitivity entries in the jacobian are with respect to the log of the parameter (the denominator par delta is in log space). And the FOSM linear algebra calcs are expecting the prior covariance matrix entries to be consistent with the jacobian entries with respect to the log transform. Otherwise, bad times....

More fundamentally, if a parameter is specified as log, then that means you are declaring its prior to be log-gaussian for any following uncertainty or data assimilation analyses. I dont think having log-gaussian is bad or "undesired", its just a different prior definition. Is there something in particular about the log-gaussian prior that is troubling you?

@Smith0710
Copy link
Author

Smith0710 commented Dec 14, 2021

Thanks for the pre-release link.

Apologies, I should have been clearer in my description. For the FOSM analysis, I'm am recalculating the Jacobian after the log transformations are removed, and hoping that will avoid the bad times.

Regarding the effect of assuming a gaussian distribution for the log transformed parameter, I was experimenting in the attached Excel to see what this looks like. In the attached example, the log transformed parameter has a mean (calibrated value) of 1 and SD 0.5, which gives a parameter (untransformed) distribution with highest probability at value 10 and lower and upper limits 1 and 100 at -+2 x SD. Nevertheless, the parameter distribution is far from gaussian with a large bias toward values greater than the mean (calibrated) value in this particular example. To me, this suggests I believe the prior parameter probability distribution has this skewed distribution, which I have no reason to assume. Within this context, the approach outlined early is my attempt to specify gaussian distributions for the prior parameter uncertainties that are easier for me to understand (explicitly) and perhaps more straightforward to explain to others.

transformed_distribution.xlsx

@jtwhite79
Copy link
Collaborator

It sounds like you have this idea sorted out. feel free to re open this issue if the unc file bits are not as expected

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants