PESTPP-GLM limit/bound enforcement

[robinkeegan]

I am having some issues with change limits/bound enforcement in PESTPP-GLM. When I run GLM I get the below error message for all lambdas and phi only reduces for the first couple of optimizations before stabilizing.
WARNING: change limit/bound enforcement for lambda 1e+02resulted in less than 1% original upgrade vector length, see rec file for details
The stabilized phi is poor compared with that obtained using PESTPP-IES, suggesting something has gone wrong during the optimization. My initial thought was that this is to do with the parameter bounds, transform and change limit type. I have tried to ensure parameters are on a similar scale with K and Sy Log10 transformed and offset to avoid changes of sign in log space as that could be problematic for factor change limit. I have also tried modifying the change limits between fixed and relative and modifying the FACORIG parameter when using factor change limit.
What are some common causes and solutions for this issue?
Thanks,
Robin

[jtwhite79]

I usually see this issue when the SVD truncation settings are too aggressive - when you dont truncated enough small singular components, those small singular values get inverted into big (sometimes huge) numbers than then result in extreme parameter changes, which then means the upgrade vector has to be shrunk by a huge amount to meet the par change requirements. So...you can increase eigthresh to like 1e-5? Let us know if that works...

[robinkeegan]

Thanks Jeremy. I had not considered SVD settings as a potential cause. I have done a few runs this morning testing different EIGTHRESH values. Unfortunately I am still encountering the issue with change limit/bound enforcement for all tested EIGTHRESH values. It did influence how rapidly phi decreased. Below is a list of the percent of phi after 1 optimization for different EIGTHRESH values:

• EIGTHRESH 1e-3 - 87 % of starting phi
• EIGTHRESH 1e-5 - 96 % of starting phi
• EIGTHRESH 1e-7 - 96 % of starting phi
  I should have mentioned before that in this case the system is over determined (210 observations vs 38 parameters). I know generally we deal with underdetermined systems and PESTPP is probably designed with that in mind. Do the SVD settings need to be altered for over determined problems?

[sjepsen395]

All,

My understanding is that negative to positive values (crossing zero) in log-space is not an issue. For example, if K ranges from 0.1 to 10 ft/day and we log-transform K, log(K) ranges from -1 to 1. I don't think this presents a problem to PEST. At least I haven't seen any problems in my results. The factor change limits in different iterations, printed to the *.rec file, apply to the non-transformed parameter values. This can be readily verified from the *.rec output. I'd be interested in hearing your thoughts if you think anything I said here is incorrect.

Trying to keep track of which equations in the PEST docs (specifically the parameter change limits) apply to non-transformed versus transformed parameters can get pretty confusing (because the docs don't always make it explicit). Doing the transforms and scaling outside of PEST, as a pre-processing step, and then using PAR2PAR to back transform might be the way to go. At least it would make the factor change limits more transparent.

Steve

[doherty1234]

Hello Steve See responses below.

On Fri Sep 06 2024 sjepsen395 ***@***.***> wrote: ---------- Original Message ---------- All, My understanding is that negative to positive values (crossing zero) in log-space is not an issue. For example, if K ranges from 0.1 to 10 ft/day and we log-transform K, log(K) ranges from -1 to 1. I don't think this presents a problem to PEST. At least I haven't seen any problems in my results. The factor change limits in different iterations, printed to the *.rec file, apply to the non-transformed parameter values. This can be readily verified from the *.rec output. I'd be interested in hearing your thoughts if you think anything I said here is incorrect.

Yes, the factor change limits apply to non-transformed parameters.

Trying to keep track of which equations in the PEST docs (specifically the parameter change limits) apply to non-transformed versus transformed parameters can get pretty confusing (because the docs don't always make it explicit). Doing the transforms and scaling outside of PEST, as a pre-processing step, and then using PAR2PAR to back transform might be the way to go. At least it would make the factor change limits more transparent.

I don't think you need to do the transforms outside of PEST. Just log transform the parameters. Meanwhile factor change limits apply to the native parameters. John

…

Steve — Reply to this email directly, view it on GitHub ( #308 (reply in thread) ) , or unsubscribe ( https://github.com/notifications/unsubscribe-auth/AA56JHQM7IWNWVCG2K23QRLZVCIKTAVCNFSM6AAAAABMTJFTMWVHI2DSMVQWIX3LMV43URDJONRXK43TNFXW4Q3PNVWWK3TUHMYTANJWGA3DAMA ). You are receiving this because you are subscribed to this thread. Message ID: <usgs/pestpp/repo-discussions/308/comments/10560600 @ github. com>

[sjepsen395]

Hi John,

Thank you very much for confirming that. I can rest assured knowing that this is the case.

I mentioned the parameter scaling idea because I have log-transformed parameters with different range widths in log space. For example, Range log(K) = [-2, 2]; Range log(Ss) = [-1, 1]. I thought it would be good to have these log-transformed parameters all share a common scale in log-space, such as [-3, 3]. I wrote the log-transform functions that do this, and which could be back-transformed in my model batch file using the PAR2PAR utility. The SCALEPAR utility does something similar, but would not allow my initial parameter values to be anywhere within their ranges. Of course, all of this is probably not necessary as you well pointed out!

Thanks,
Steve