Issue with binning at initialization 2D pcoords

[Isabel Thompson]

Hi all, 

I have been working with WE for a little over a year now and this is the first time I am noticing this issue, but have not changed anything in my run scripts or setup, so I am worried this has been going on the entire time and I just did not catch it. 

I am using westpa/2022.10.

I am trying to set up a trial run of 2D progress coordinates for unfolding with a single starting bstate. Upon initialization (which I run with the script attached using ./init.sh) it places the bstate in the wrong starting bins. I attached my west.cfg, system.py file and runseg.sh as well for further context and the output of init.log and w_bins info --detail. 

The bin bounds in system.py are weirdly spaced because I was trying to see if making the bins smaller in the initial mapping would help figure out if the issue was rounding or something. But that does not appear to be the case and I have never seen that behavior before. 

When I uncomment the "rmsdQuad3" etc. mappers to cover the quadrants of the outer mapper that don't currently have nested bins, ./init.sh and w_bins appear to bin the single bstate correctly. Has it always been this way? I did not think you had to add a recursive mapper to each quadrant of the outer mapper. 

The starting progress coordinates are (RMSD, MinDist): (1.375, 1.9776), so it should not be in the [(1.3, 1.4), (2.0, 2.05)] bin to start. 

I can confirm that the initial west.h5 file generated from ./init.sh has the correct p-coords, so my hunch is that something about my binning scheme/mappers or w_bins isn't working how I think it does. 

Thanks so much!

[Jeremy Leung]

Hi Isabel (hope I got your first name right via google search),

Recursive bin labels were potentially wrong up until 2022.13 (where we fixed it) so what's reported by `w_bins` before that version might not be entirely correct. Don't worry, this only affects the string labels and does not affect the binning capabilities. 

I tried remaking your bins in 2022.13 and the labels now match up with the bin id, so I think that was the issue. They don't match up if I'm on 2022.10 (reproducing what's in your email). If you want the full list (it's 231 lines long), run the following on 2022.13+.

```

# On 2022.13

In [1]: from system import System
In [2]: a = System()
In [3]: a.initialize()
In [4]: list(a.bin_mapper.labels)

[...]  # The 231 bin labels

In [5]: a.bin_mapper.assign([[1.375,1.9776]])
Out[5]: array([25], dtype=uint16)

In [6]: list(a.bin_mapper.labels)[25]
Out[6]: '[(1.3, 1.4), (1.975, 1.985)]'  # Correct label
```

Oh, and correct.  You do not need to add a recursive mapper in each base bin.

Sorry for the trouble and confusion! Thank you for the detailed bug report as well!

Best,

Jeremy L.

---
Jeremy M. G. Leung, PhD
Research Assistant Professor, Chemistry (Chong Lab)
University of Pittsburgh | 219 Parkman Avenue, Pittsburgh, PA 15260
jml...@pitt.edu | [He, Him, His]