Issue with method "smp_utils.smp_to_ins" in pyEMU

[Paszka1]

Is there an issue with the "smp_utils.smp_to_ins" method in pyEMU? I.e., due to a leading whitespace added in front of the observation name as the first character in each line of the .smp file created by mod2smp, the generated instruction files look erroneous. I.e., (1) if using the free format then one "w" marker is missing (only 3 instead of 4), and (2) if the fixed format is used, then the data field is shifted one column leftward (i.e., to the time column instead of the actual data (e.g., head) column).

[Paszka1]

I beleive the problem occurs as a result of "mod2smp" was modified since the script was first written. This probably needs to be confirmed by the author (i.e., John Doherty).

Another issue that I ran into is concerning reading spatial reference information in the second comment line of a namefile. The FloPy method "sr = model.modelgrid" yields correct results. As oposed to this the pyEMU method 'SpatialReference.from_namfile' doesn't read 'xll' and 'yll' information and places the lower left corner to (0, 0). Looking at the code it was clear that the pyEMU method only handles headers that spcify 'xul' and 'yul' (i.e., the code section handling 'xll' and 'yll' is missing).

[jtwhite79]

There is a gwutils_compliant boolean arg that you can pass to smp_to_ins() that is designed to deal with the leading whitespace issue from the smp files generated by the PEST utils. As long as the PEST utils havent changed how smp files are created, setting this to True should fix this issue.

The SpatialReference class in pyemu is not meant to be compatible with all the complexity of the flopy referencing stuff these days. We kept that so that users can create their own spatial reference for any structured grid model (modflow or otherwise) to use in PstFrom. @briochh maybe we should strip out the name file constructor from that SpatialReference class since the flopy approach continues to change?

[briochh]

@jtwhite79 and @Paszka1 , yes we could probably do with revisting that SpatialReference construction. I think the from_namfile() method was probably directed towards the older (pre MF6) MODFLOW nam file spatial ref storage. It should be possible to update this to handle changes in mf6 spatial ref metadata storage. If you are running with flopy, using sr=model.modelgrid "should" work (subject to us keeping up with changes in that flopy modelgrid object).

[christianlangevin]

If you decide to transition to flopy modelgrid and require some functionality that you want to be stable, please don't hesitate to add a test or ask us to do it.

[briochh]

@Paszka1, did you get to the bottom of the smp_to_ins issue? updated mod2smp work?

I'll leave this issue open as I think the SpatialReference stuff is still a bit messy and probably needs a clean up. But maybe we should edit the issue header here to reflect that issue too?

[reneangermeyer]

Hi! Sorry for bringing this thread back, but this is still an issue. I believe the root of the problem lies in the following definition:

if gwutils_compliant:
    ins_strs = ["l1  ({0:s})39:46".format(on) for on in onames]
else:
    ins_strs = ["l1 w w w  !{0:s}!".format(on) for on in onames]

The range 39:46 corresponds to the position of the time column, but when gwutils_compliant is False, a w seems to be missing — there are actually four columns.

[briochh]

@Paszka1, @reneangermeyer, @cnicol-gwlogic anyone keen to put in a PR with this fix (and maybe a test?)