KeyError when rendering network graphics

[FirokOtaku]

Summary

I created a .inp file with some labels in Chinese by EPANET 2.2.
The file was originally in GBK encoding and was converted to UTF-8.

A exception was thrown when trying to run simulation on that network ( sim = wntr.sim.EpanetSimulator(wn); results = sim.run_sim() ):

Traceback (most recent call last):
  File "F:\Projects\epanet-wntr-demo\src\main.py", line 70, in <module>
    results = sim.run_sim()
  File "F:\Projects\epanet-wntr-demo\conda-env\lib\site-packages\wntr\sim\epanet.py", line 103, in run_sim
    write_inpfile(self._wn, inpfile, units=self._wn.options.hydraulic.inpfile_units, version=version)
  File "F:\Projects\epanet-wntr-demo\conda-env\lib\site-packages\wntr\network\io.py", line 511, in write_inpfile
    wn._inpfile.write(filename, wn, units=units, version=version, force_coordinates=force_coordinates)
  File "F:\Projects\epanet-wntr-demo\conda-env\lib\site-packages\wntr\epanet\io.py", line 488, in write
    self._write_labels(f, wn)
  File "F:\Projects\epanet-wntr-demo\conda-env\lib\site-packages\wntr\epanet\io.py", line 1989, in _write_labels
    f.write(' {}\n'.format(label).encode('latin-1'))
UnicodeEncodeError: 'latin-1' codec can't encode characters in position 40-41: ordinal not in range(256)

It turns out wntr/epanet/io.py use latin-1 encoding to perform filesystem IO everywhere. After replacing all those latin-1 to utf-8, simulation can proceed normally. But a new exception was thrown:

Traceback (most recent call last):
  File "F:\Projects\epanet-wntr-demo\conda-env\lib\site-packages\wntr\network\base.py", line 613, in __getitem__
    return self._data[key]
KeyError: 'j1'

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "F:\Projects\epanet-wntr-demo\conda-env\lib\site-packages\wntr\network\base.py", line 616, in __getitem__
    return self._data[key.name]
AttributeError: 'str' object has no attribute 'name'

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "F:\Projects\epanet-wntr-demo\src\main.py", line 84, in <module>
    wntr.graphics.plot_network(
  File "F:\Projects\epanet-wntr-demo\conda-env\lib\site-packages\wntr\graphics\network.py", line 196, in plot_network
    link = wn.get_link(link_name)
  File "F:\Projects\epanet-wntr-demo\conda-env\lib\site-packages\wntr\network\model.py", line 778, in get_link
    return self._link_reg[name]
  File "F:\Projects\epanet-wntr-demo\conda-env\lib\site-packages\wntr\network\base.py", line 618, in __getitem__
    return self._data[str(key)]
KeyError: 'j1'

It seems that wntr/graphics/network.py#L196 were trying to get j1 as a link which should be a node and cause that exception.

Is there something wrong with my code or operation?
Or it's a bug of WNTR framework?

Example

Related .inp and .py files are listed at here.

Environment

• Operating system: Windows 10
• Python version: Python 3.10.10 (conda)
• WNTR version: 1.0.0

all pakcage versions

# packages in environment at F:\Projects\epanet-wntr-demo\conda-env:
#
# Name                    Version                   Build  Channel
bzip2                     1.0.8                he774522_0
ca-certificates           2023.01.10           haa95532_0
certifi                   2022.12.7       py310haa95532_0
contourpy                 1.0.7                    pypi_0    pypi
cycler                    0.11.0                   pypi_0    pypi
fonttools                 4.39.3                   pypi_0    pypi
kiwisolver                1.4.4                    pypi_0    pypi
libffi                    3.4.2                hd77b12b_6
matplotlib                3.7.1                    pypi_0    pypi
networkx                  3.0                      pypi_0    pypi
numpy                     1.24.2                   pypi_0    pypi
openssl                   1.1.1t               h2bbff1b_0
packaging                 23.0                     pypi_0    pypi
pandas                    2.0.0                    pypi_0    pypi
pillow                    9.5.0                    pypi_0    pypi
pip                       23.0.1          py310haa95532_0
pyparsing                 3.0.9                    pypi_0    pypi
python                    3.10.10              h966fe2a_2
python-dateutil           2.8.2                    pypi_0    pypi
pytz                      2023.3                   pypi_0    pypi
scipy                     1.10.1                   pypi_0    pypi
setuptools                65.6.3          py310haa95532_0
six                       1.16.0                   pypi_0    pypi
sqlite                    3.41.1               h2bbff1b_0
tk                        8.6.12               h2bbff1b_0
tzdata                    2023.3                   pypi_0    pypi
vc                        14.2                 h21ff451_1
vs2015_runtime            14.27.29016          h5e58377_2
wheel                     0.38.4          py310haa95532_0
wincertstore              0.2             py310haa95532_2
wntr                      1.0.0                    pypi_0    pypi
xz                        5.2.10               h8cc25b3_1
zlib                      1.2.13               h8cc25b3_0

[FirokOtaku]

Okay I found problem. I passed the wrong dict with pressures of nodes as the link_attribute param of plot_network.

[dbhart]

@FirokOtaku I had previously had problems with EPANET and unicode labels failing. My understanding is that EPANET only accepted 8-bit encoding, not unicode wide characters (certainly in the binary output file). Has this changed, then? I had not seen notice on the EPANET github that it had.

[FirokOtaku]

@dbhart My understanding is that EPANET only accepted 8-bit encoding, not unicode wide characters (certainly in the binary output file). Has this changed, then?

When setting Chinese as major language of Windows, GBK would be the default encoding and lots of programs would just use that to perform filesystem IO.

I'm not sure about how underlying code of EPANET runs. Only thing I can tell is that .inp files exported by EPANET 2.2 are in the default encoding of OS (which is GBK in my enviroment). That behavior is similar to other softwares.

Hope that information can help a little.