ult_bnds getting changed unexpectedly

[wkitlasten]

I have been able to track my parfile_relations to line 338 in pst_from.py and all looks good at that point. The following values are in pr:

      upper_bound lower_bound
0   [100000000.0]     [1e-06]
1   [100000000.0]     [1e-06]
2   [100000000.0]     [1e-06]
3        [4000.0]      [-1.0]
4        [4000.0]      [-1.0]
5   [100000000.0]     [1e-06]
6   [100000000.0]     [1e-06]
7   [100000000.0]     [1e-06]
8   [100000000.0]     [1e-06]
9          [0.05]     [1e-08]
10         [0.05]    [-0.003]
11    100000000.0    0.000001
....

But the following code (and similar for lbound) changes the upper and lower bound to the max and min of the columns for a give file.

if ubound.nunique(0, False).gt(1).any():
    ub_min = ubound.min().fillna(self.ult_ubound_fill).to_dict()
    pr.loc[g.index, "upper_bound"] = g.use_cols.apply(
        lambda x: [ub_min["ubound{0}".format(c)] for c in x]
        if x is not None
        else ub_min["ubound"]
    )

To give this:

    upper_bound lower_bound
0        [0.05]     [1e-06]
1        [0.05]     [1e-06]
2        [0.05]     [1e-06]
3        [0.05]     [1e-06]
4        [0.05]     [1e-06]
5        [0.05]     [1e-06]
6        [0.05]     [1e-06]
7        [0.05]     [1e-06]
8        [0.05]     [1e-06]
9        [0.05]     [1e-06]
10       [0.05]     [1e-06]
11  100000000.0    0.000001

The file being parameterized (using use_rows in the 'pf.add_parameters` call) has parnames as rows and parvals in a column (plus some other columns I use for other stuff, so simply transposing the table gets awkward):

                      value
parnme                     
coast.cond_c_layer1       1
coast.cond_c_layer2       1
reach.rhk_c_layer1        1
stage.value_c_layer1      0
satx.elev_c_layer1        0
k_c_layer1                1
k_c_layer2                1
k33_c_layer1              1
k33_c_layer2              1
mrch_c                    1
pmet_c                    0

Is there a reason all parameters (rows) should have the same bounds?

[briochh]

Short answer -- no, no good reason why pars should have the same bound.

There is a bit of a legacy here though, the original conceived use-case was that and ultimate bounds for the native model input file values might reasonably be applied across a "group". This together with the assumptions that for list-like, tabular input files, parameters groups would be along a column (so across rows). I guess we did this to try and keep that mult2model_info.csv file manageable, and simplify things at apply_pars() time. Potentially this now tips the scale towards restrictive. @jtwhite79 @mnfienen maybe we need to look at a new model here? @kmarkovich might have some thoughts on this too.

For now, your best bet might be to tackle the application of bounds in our own pre-processing func (presumably these pars are being sucked into another method anyway at some point?). Or see you go with a transposed input file.

[wkitlasten]

Makes sense, as always. Although I can imagine a case where you select certain rows (e.g., by layer) that have different par bounds. Obviously ways around that in MODFLOW (with the exception of the period data) , but maybe less obvious in other modelling software?

Maybe worth noting (although a personal problem) this issue came up because using pf to apply a constant parameter to an array creates a tpl file resembling the array (makes sense to deal with zones). For a big model (e.g. a long diagonal island) that caused issues with pest_hp reading the long lines. Thanks for adding support for column arrays... problem solved once I get around to chasing that through my code!