pestpp-ies identify run_ids in GLM which are considered part of the ensemble

[jmccreight]

This is a feature request to have pestpp-ies log/identify the run_ids of the GLM runs which are considered part of the ensemble in each iteration.

I am running a synthetic case where I want full parameter and state fields out of the (MF6) model for each iteration of IES. To that end, I save off all the runs performed by IES with a simple function added by PestFrom.add_py_function(). When I save it off, I keep the run.info files in the individual run directories.

I am able to identify the prior ensemble (size "num_reals"), then all the subsequent GLM (size 36 by default) and ensemble advances (size num_reals - ies_subset_size, which is size_num_reals -4 by default). What I can not easily identify are the (ies_subset_size) runs in the GLM phase which are considered part of the subsequent ensemble. I have a very baroque procedure for matching parameters from the parameters written for all the ensemble members (in *.iteration.par.csv files) against the parameters in a subset of the GLM run dirs which appears to work. But I think all this work could be simply replaced if IES could just log the GLM run_ids which are selected as part of the ensemble (which I havent seen anywhere).

Thanks!

[cnicol-gwlogic]

Try ies option Ies_save_lambda_ensembles(true) - then you will see these lambda test pars and "obs" (model outputs) saved in csv's at each upgrade.

But I guess these are reported in the end of iteration full results csv's, so I don't really follow why you can't just get the info from there. Those lambda upgrade csv's will include the best and worst of the tests, so you'd have to pluck out the ones you want (presumably the best ones - which ies does for the final iteration outputs anyway)...

If you're archiving model files (eg hds or interpolated k fields etc) that can't easily be recorded by ies to it's per-iteration results csv files (via it's obs/ins functionality), then that would best be done once your optimisation is complete (eg say 3 iterations), then run the optimized ensemble through pestpp-swp and archive from there.

[jtwhite79]

The parameter and observation realization ids selected for subset testing are recorded in the .rec file at the start of the lambda testing run process, but that is a little convoluted bc the realization names are reset for the lambda subset testing, so the run.info file wont help much for that is. That part of the rec file looks like this:

...subset idx:pe real name:  0:BASE, 9:3, 10:4, 20:16, 
...subset idx:oe real name:  0:BASE, 9:3, 10:4, 20:16, 

If you are after more explicit knowledge of what realization is being run for on specific worker, you can add a fixed parameter to the interface and assign it the realization number in the prior parameter ensemble (assuming you are supplying your own ensemble to ies). For fixed parameters that have values in a user-supplied ensemble, ies will use the ensemble values instead of the control file value. Then if you have a simple tpl file that just writes this fixed value at runtime, you can get the exact realization number of every model run.

You can also limit the lambda testing to just use a single value of lambda and backtracking factor and not use the subset testing process (the 36 runs), and instead each batch of runs will be for the full ensemble. This will be a cleaner process of calculate ensemble, evaluate ensemble. That might make it easier to implement your process (at least test that its working as expected).