MOU - How to find stack realization name

[cnicol-gwlogic]

Hi,

When running MOU with stack-based chances (I provide a param realisation csv from a previous IES run), is there a way to identify the realization name from that IES csv during a worker's model run? Normally I use run.info with IES/SWEEP to read the runid, from which I can work out the realisation name because the stack is run in sequential order).

In the case of MOU, this is not a straightforward relationship, and I thought I could read the "realization" part of run.info, but it is in the form of: "REALIZATION:GEN=3_MEMBER=348_DE" - but to my knowledge there is nothing at the worker end that allows me to link back to the corresponding param stack realization name. Is there?

I guess a solution if the answer is no is to add a parameter to the stack which is the realization name, and get pest to write that via a tpl file to a file in each worker folder during a model run. Is that the best bet?

Cheers,
Chris.

[jtwhite79]

Those names you are seeing are the member names of the population in mou. But when you run the stack for chances, you should get the parameter realization name in the run.info file on the workers. If you are using chance_points = single, then its the original par realization name in run.info. But if you are using chance_points = all, then the run.info file will have a strange aggregated name like 0||gen=1_member=0_de where the double vertical bar || separates the parameter realization name on the left from the mou population member name on the right. Note that for all other model runs (like when mou is evaluating populations), the parameter realizations arent being used...

[cnicol-gwlogic]

Thanks for that - I thought I had seen realization names from the stack csv in there in earlier tests, and had coded around this concept. I think I must have been looking at run.info after the chance runs had been done (derr....and yep, I'm using chance_points=single, and re-evaluate every 20 generations). ta.

[cnicol-gwlogic]

For the record, for other users, the relevant line in run.info (for obtaining the opt_par_stack() realization name), when chances are being calculated) looks like this: info_txt, DA_CYCLE:-9999 REALIZATION:178
When chances are not being calculated (eg if opt_recalc_chance_every() is something other than 1), then in generation 2 you would see something like this in run.info: info_txt, DA_CYCLE:-9999 REALIZATION:GEN=3_MEMBER=348_DE - and based on the answer above, means that parameter values from the control file are being used (true story @jtwhite79?).

[jtwhite79]

True story @cnicol-gwlogic . Ive wondered tho if there is a stack, if the mean of the stack parameters should be used in those mou runs where the stack is not being evaluated (rather than the control file values)?

[cnicol-gwlogic]

Yeah I wondered about this too @jtwhite79 . Mean of stack values could cause issues I guess (decalibrate, assuming I'm following you). What I did was make sure my pst file pars are the base realisation from my history matched stack; I figure everything else is centred around that (because I use ies_centre_on(base)), so this is probably about as good as it can get. I think...

[jtwhite79]

Thats the approach I use also: getting some representative par values into the ctl file...