pst_from.add_parameters: do the values in index_cols need to be ints?

[aleaf]

I came across this by accidentally not specifying a comment_char in the following call to add_parameters, which caused the index_cols (including the header) to be read a strings.

            pf.add_parameters(filenames=wel_file, par_type="constant",
                              par_name_base="wel_cn",
                              pargp="wel_cn",
                              upper_bound=1.2, lower_bound=0.8,
                              index_cols=[0, 1, 2], use_cols=[3],
                              datetime=perioddata.loc[per, 'start_datetime'],
                              geostruct=temporal_gs, par_style="multiplier"
                              )

this then caused this line (2532) to fail:

if not zero_based:
    df_ti.loc[:, "sidx"] = df_ti.sidx.apply(lambda x: tuple(xx - 1 for xx in x))

If index_cols should be comprised of ints, then would be good to add a check for this in _get_tpl_or_ins_df so that the user gets a more helpful error message. Or if not, we would need another way to handle the zero_based option.

[jtwhite79]

Sorry for the delay @aleaf . Can you post the first few lines of the well list file that's causing the problem?

[aleaf]

something like this would do it:

#k i j flux
1 2 2 1.0
1 3 2 10.0
1 3 1 100.0

again, this case is a user error, but I could imagine a situation where someone might want to index wells by site IDs (supplied as boundnames), which would be strings.

[briochh]

Hi @aleaf, I think this is a good thought. I guess the assumption that we were working with was that index_cols would refer to something positional within the model. But I guess there is no reason that an index_col couldn't be a unique string ID too, so we should probably support. Hopefully just a case of routing around that zero-based adjustment line but it may trip things up elsewhere. I'll take a look.