Dark handling of parameter correlations when duplicated locations interpreted from passed i,j (or x,y)

[briochh]

Currently, when parameter spatial information in list-like parameter files (passed to PstFrom.add_parameters()) results in collocated parameters (e.g. the same i,j information for different rows), we attempt to split the correlated parameters by an additional index, if passed (e.g. layer). This can get around the issue of trying to define correlations for identically located parameters. However it may result in us breaking correlations between pars that should actually be correlated (setting off-diags in the covariance matrix to 0).

Thinking that we need to provide an option to the user (more args!) to attempt to split, offset, or potentially tie collocated pars.

Will work on this, but any thoughts on desired behaviour welcome.

[jtwhite79]

Tying is probably the cleanest but adding jitter/offset and splitting/uncorrelating might also be useful in some settings. I wonder if we should add this handling to the prior builder and draw methods outside psrfrom? That might be easier and more general? Maybe?

[briochh]

Yeah that might be a good shout -- could help keep that add_parameters() clean (or not make it more dirty). You might want the flexibility to have diff behaviour for diff pars groups though so might need something passed at add_parameters() time