Error reading variable of type integer in sfr connection

[wkitlasten]

Describe the bug
ERROR REPORT:

1. Error in block CONNECTIONDATA. Could not read variable of type INTEGER
   from the following line: '2 -16183'.

UNIT ERROR REPORT:

1. ERROR OCCURRED WHILE READING FILE
   'D:\modelling\data\SSIF4\hb_400\hb_400.sfr.connection.dat'

To Reproduce
Run the attached model.

hb_400.zip

Expected behavior
Reach 2 should discharge into reach 16183, as specified by the second line in the sfr.connection.dat file.

1     -4
2     -16183
3 -16185
4      1     -5
5      4 -16183
...
16183      2      5 -16184
16184  16183 -32736

For some reason MODFLOW cannot read the line. Admittedly, I do have a warning regarding unconnected reaches, but none seem to be associated with this error. I'm also fully open to the fact that I may have mucked something else up along the way, but this error does not seem to be an obvious error on my part.

Desktop (please complete the following information):

• OS: Windows 10, Intel
• MODFLOW VERSION 6.3.0 03/04/2022

[langevin-usgs]

@wkitlasten did you ever figure this out? I suspect your connection data is not consistent with the number of connections (ncon) specified in the packagedata block. Am closing this for now, but please reopen if you are convinced there is a problem in the code.

[emorway-usgs]

Hey Wes, you've probably identified this already, but as @langevin-usgs points out, in your PACKAGEDATA input, you have the following lines:

# rno  k  i    j           rlen       rwid      rgrd          rtp  rbth        rhk   man  ncon  ustrf  ndv
1      1  84   64    287.764502   2.058779  0.038200   788.271582   0.5  26.547303  0.04     1    0.0    0
2      1  83   63    249.705627   2.241125  0.038856   772.469649   0.5  22.720344  0.04     2    1.0    0
...

The third-to-last value on the last line quoted above should be a 1 instead of 2 since the number of connections listed on the 2nd line of the CONNECTIONDATA block only lists one connection, i.e.: 2 -16183

[wkitlasten]

Thanks! Yes, that was the issue. It stemmed from rearranging the poorly handled hack I was using to address this issue in flopy: modflowpy/flopy#1635 (comment)