my reweighting issue

[wkitlasten]

My current ies setup is failing to update any pars; every lambda (1-1000) and scale fac (default) combo looks identical.

I checked a few individual realizations using pst.parrep() and the input and output files are changing as expected. The changes are reflected in the obs ensemble, where individual obs have reasonable values and distributions (+/- 10m head, etc). The parameter ensemble looks good too, as far as I can tell. Is there a method to calc or save an empirical jco (pestpp-ies seem inpervious to setting pst.control_data.jcosave and I'm not seeing anything in pyemu... I think I might have asked this already, just can't seem to find the answer).

Could it be a weighting issue? I am reusing a previous setup. In the current setup I am assigning weight=0 for all obs with flag "tritium_measured" and "greater_". PSo my "balance_phi_groups" table is:

tritium_measured,0
head,1
flow,1
less_flw,1
greater_,0

I get a "...WARNING: no non-zero obs groups found for tag 'TRITIUM_MEASURED'" but it is intended, so I ignore it.

Any suggestions on where else to look would be greatly appreciated!

[jtwhite79]

Have you looked at the lambda ensembles? I guess you compare between them and also compare them to the prior to see how much change and in what direction ies is trying to move parameters? Are the lambdas ensemnles running into bounds? Is the prior ensemble "centered" between the par bounds?

Might also be worth looking at the weighted residual ensemble (you'll have to calculate this with the updated obs info and prior ibs ensemble) - the residuals will control the magnitude of the par changes.

What lambda are being used? That phi table sums to 3 so the initial phase are being multipled by 3...

I've not seen a real case where ies refuses to go downhill at all...but I've manufactured cases where the posterior is highly nonlinear/multimodal that cause no phi decreases because each realization needs to move in a different direction and the global ensemble gradient doesn't represent those directioons. Maybe a test with a much tighter prior (artificially collapsed around the initial par values) would reveal this issue?

[jtwhite79]

well the singular values show why the upgrades are numerically zero...whats that obs_diff matrix look like - those are the centered simulated values (from running the prior par ensemble...) and that matrix is what is factorized with SVD...

[wkitlasten]

When is the obs_diff file produced? Does it require calcs for all lambda mult and scale factors (still waiting on the last of those)?

[jtwhite79]

Should be just before ivec...there should be an obs_resid also with the same naming scheme also.

[wkitlasten]

The only files I am seeing with that naming convention are listed above... no obs_resid or obs_diff.

[jtwhite79]

thats weird. There is a try-catch in that matrix writer routine so i wonder if there is something bunk (nan, inf, etc) in the obs matrix and the writer is just skipping them. How big is this problem? I might be interested in trying to debug it and see what is happening...