# SUEWS v2026.1.28rc1 crash in UMEP when saving results (TypeError with a dictionary instead of a string) **URL:** \ **Category:** General\ **Tags:** github-issue\ **Created:** [8 July 2026 10:27 UTC](https://community.suews.io/t/suews-v2026-1-28rc1-crash-in-umep-when-saving-results-typeerror-with-a-dictionary-instead-of-a-string/140 "2026-07-08T10:27:29Z")\ **Posts on this page:** 8\ **Page:** 1
**Author:** ![Adhaile](https://avatars.discourse-cdn.com/v4/letter/a/50afbb/32.png) [@Adhaile](https://community.suews.io/u/Adhaile)\ **Post date:** [8 July 2026 10:27 UTC](https://community.suews.io/t/suews-v2026-1-28rc1-crash-in-umep-when-saving-results-typeerror-with-a-dictionary-instead-of-a-string/140/1 "2026-07-08T10:27:29Z")
I’m running the “Urban Energy Balance: SUEWS” processing algorithm in UMEP (QGIS plugin), using SUEWS v2026.1.28rc1 with SuPy 2026.4.3rc1, on QGIS 3.40.11-Bratislava, Windows. The simulation itself runs correctly all the way through: the console shows the expected progression (“Initiating model”, “Loading forcing data”, “Running model”, then “Saving to disk”), and the full year of simulation for a single grid completes in about 7 minutes without any error. However, the process then crashes right at the final step, when the results should be written to disk. The full traceback is as follows: a TypeError is raised in `suews_algorithm.py` (part of the `processing_umep` plugin), at line 297, during the call `sim.save(yaml_dict['model']['control']['output_file'])`. This propagates into `suews_sim.py` in SuPy, at line 625, where the code tries to convert this argument into a `Path` object and fails with: “argument should be a str or an os.PathLike object where **fspath** returns a str, not ‘dict’”. From what I can tell, the YAML configuration file generated by “SUEWS Prepare (Database Typologies)” defines `output_file` under `model.control` as a nested structure with several keys (`format`, `freq`, `path`, `groups`), rather than a plain string. It looks like the UMEP plugin is passing this whole dictionary directly to `sim.save()`, while that function apparently expects a plain string path instead.I’m not familiar enough with the codebase to fix this myself, but here’s what I tried in case it’s useful: I first patched `suews_algorithm.py` to extract only the `path` key from the `output_file` dictionary before passing it to `sim.save()`, but this still failed with the exact same TypeError, suggesting `path` itself may be wrapped in another nested structure. I then tried bypassing the plugin entirely by running the simulation directly from the QGIS Python console, using `supy.SUEWSSimulation` and passing a plain string path straight to `sim.save()`. This time the call didn’t crash, but it produced two empty (0 KB) output files with nonsensical names (“grid no” and “df\_state\_grid no”), so no usable results were actually saved either way. I’d really appreciate any guidance on how to work around this, or confirmation of whether this is a known compatibility issue between the UMEP plugin and this version of SuPy. Happy to share my full YAML configuration file if that helps reproduce the problem. Thanks in advance for any help. ---
**Author:** ![sunt05](https://dub1.discourse-cdn.com/flex014/user_avatar/community.suews.io/sunt05/32/5_2.png) [@sunt05](https://community.suews.io/u/sunt05)\ **Post date:** [8 July 2026 13:33 UTC](https://community.suews.io/t/suews-v2026-1-28rc1-crash-in-umep-when-saving-results-typeerror-with-a-dictionary-instead-of-a-string/140/2 "2026-07-08T13:33:35Z")
Hi @Adhaile, Thanks for the careful write-up, and you have read it correctly: this is a compatibility gap between the current UMEP “SUEWS” processing tool and the newer SuPy. For now, the cleanest way to use the latest SUEWS features is to run SUEWS directly, from the command line or a Python session, rather than through the QGIS plugin. Your existing YAML files do not need rewriting by hand. SuPy ships an upgrade tool that brings an older config up to the current format: ``` suews schema migrate your_config.yml ``` That produces an upgraded config you can then run directly, either from the command line or via `SUEWSSimulation` in Python. There is a short walk-through in the transition guide: [4.5. Transitioning to YAML-based Configuration — SUEWS 2026.6.5 documentation](https://docs.suews.io/stable/inputs/transition_guide.html) Any other SuPy or SUEWS questions are very welcome here, and we are happy to help. ---
**Author:** ![Adhaile](https://avatars.discourse-cdn.com/v4/letter/a/50afbb/32.png) [@Adhaile](https://community.suews.io/u/Adhaile)\ **Post date:** [9 July 2026 15:03 UTC](https://community.suews.io/t/suews-v2026-1-28rc1-crash-in-umep-when-saving-results-typeerror-with-a-dictionary-instead-of-a-string/140/3 "2026-07-09T15:03:24Z")
Hi @sunt05, Thank you for your very quick answer and for confirming the compatibility gap between the current UMEP plugin and the newer SuPy version. Following your advice, I attempted to bypass the QGIS interface by running the simulation directly from the command line using the CLI tools. I first ran `suews schema migrate` on the plugin-generated configuration file, and then executed the simulation using `suews-run.exe`. Unfortunately, I am still obtaining empty files. The process completes without throwing any errors in the console, but the resulting output files are still the same… I also tried modifying the YAML configuration to use a clean, absolute local path for the output directory instead of `./Output` to avoid any potential path encoding issues, but the result remains the same. Could this behavior be related to how the grid IDs or the forcing file paths are structured in the YAML file prior to migration? I would appreciate any insights on why `suews-run.exe` might fail to write the simulated data under these conditions. Thank you very much ! ---
**Author:** ![sunt05](https://dub1.discourse-cdn.com/flex014/user_avatar/community.suews.io/sunt05/32/5_2.png) [@sunt05](https://community.suews.io/u/sunt05)\ **Post date:** [10 July 2026 09:42 UTC](https://community.suews.io/t/suews-v2026-1-28rc1-crash-in-umep-when-saving-results-typeerror-with-a-dictionary-instead-of-a-string/140/4 "2026-07-10T09:42:52Z")
Hi @Adhaile, sorry to hear it’s still not working – could you please share your YAML file here so we can take a look and do some debugging on our end? Thanks! ---
**Author:** ![Adhaile](https://avatars.discourse-cdn.com/v4/letter/a/50afbb/32.png) [@Adhaile](https://community.suews.io/u/Adhaile)\ **Post date:** [10 July 2026 14:17 UTC](https://community.suews.io/t/suews-v2026-1-28rc1-crash-in-umep-when-saving-results-typeerror-with-a-dictionary-instead-of-a-string/140/5 "2026-07-10T14:17:33Z")
[sma01.yml](https://community.suews.io/uploads/short-url/r7ve0KAKkO77MDAXJTOFN6gNoGg.yml) (431.4 KB) Hi, Thank you so much for your help ! Here is the latest version of my YAML file 🙂 ---
**Author:** ![sunt05](https://dub1.discourse-cdn.com/flex014/user_avatar/community.suews.io/sunt05/32/5_2.png) [@sunt05](https://community.suews.io/u/sunt05)\ **Post date:** [13 July 2026 08:11 UTC](https://community.suews.io/t/suews-v2026-1-28rc1-crash-in-umep-when-saving-results-typeerror-with-a-dictionary-instead-of-a-string/140/6 "2026-07-13T08:11:15Z")
Thanks for the YAML. I have a hypothesis, though I cannot test it on Windows myself, so worth confirming before we act on it. Your four sites are named `grid no: 0` … `grid no: 3`, and SuPy uses the first site’s name as the filename prefix (results as `{site}{grid}_{year}_{group}_{freq}.txt`, state as `df_state_{site}.csv`). That produces `grid no: 00_1985_SUEWS_60.txt` and `df_state_grid no: 0.csv`. A colon in a Windows filename is not part of the name: NTFS reads what follows it as an alternate data stream, which would leave exactly the 0 KB `grid no` and `df_state_grid no` files you saw, with no error raised. Could you run `dir /r "C:\SUEWS_Resultats"`? It lists alternate data streams, so if this is the cause your results should show up there. If it is, renaming the sites without a colon (`grid_0`, `grid_1`, …) should fix it, and I will raise an issue so SuPy stops accepting filesystem-illegal site names silently. ---
**Author:** ![Adhaile](https://avatars.discourse-cdn.com/v4/letter/a/50afbb/32.png) [@Adhaile](https://community.suews.io/u/Adhaile)\ **Post date:** [15 July 2026 08:14 UTC](https://community.suews.io/t/suews-v2026-1-28rc1-crash-in-umep-when-saving-results-typeerror-with-a-dictionary-instead-of-a-string/140/7 "2026-07-15T08:14:36Z")
Thank you so much it was indeed the problem !! I did the following commands and I finally have some results 🥰 ```auto C:\\PROGRA\~1\\QGIS34\~1.11>dir /r "C:\\SUEWS_Resultats" Volume in drive C is OS Volume Serial Number is DA88-C2AE Directory of C:\\SUEWS_Resultats 15/07/2026 01:35 . 15/07/2026 01:35 0 df_state_grid no 134,461 df_state_grid no: 0.csv:$DATA 15/07/2026 01:35 0 grid no 9,614,512 grid no: 00_1985_SUEWS_60.txt:$DATA 9,614,163 grid no: 01_1985_SUEWS_60.txt:$DATA 9,616,137 grid no: 02_1985_SUEWS_60.txt:$DATA 9,633,375 grid no: 03_1985_SUEWS_60.txt:$DATA 2 File(s) 0 bytes 1 Dir(s) 204,930,138,112 bytes free C:\\PROGRA\~1\\QGIS34\~1.11> C:\\PROGRA\~1\\QGIS34\~1.11>cd /d C:\\SUEWS_Resultats C:\\SUEWS_Resultats> C:\\SUEWS_Resultats>more < "df_state_grid no: 0.csv" > "df_state_grid_0.csv" C:\\SUEWS_Resultats>more < "grid no: 00_1985_SUEWS_60.txt" > "grid_00_1985_SUEWS_60.txt" C:\\SUEWS_Resultats>more < "grid no: 01_1985_SUEWS_60.txt" > "grid_01_1985_SUEWS_60.txt" C:\\SUEWS_Resultats>more < "grid no: 02_1985_SUEWS_60.txt" > "grid_02_1985_SUEWS_60.txt" C:\\SUEWS_Resultats>more < "grid no: 03_1985_SUEWS_60.txt" > "grid_03_1985_SUEWS_60.txt" ``` Thnak you again for your precious help ! ---
**Author:** ![sunt05](https://dub1.discourse-cdn.com/flex014/user_avatar/community.suews.io/sunt05/32/5_2.png) [@sunt05](https://community.suews.io/u/sunt05)\ **Post date:** [15 July 2026 08:43 UTC](https://community.suews.io/t/suews-v2026-1-28rc1-crash-in-umep-when-saving-results-typeerror-with-a-dictionary-instead-of-a-string/140/8 "2026-07-15T08:43:55Z")
Glad that got you unblocked, @Adhaile — and thanks for going the extra step with `dir /r` to confirm it. You pinned the cause exactly: the colon in the site name (`grid no: 0`) is treated as an NTFS alternate-data-stream separator on Windows, so the data ended up hidden in the stream rather than in a normal file. We’ve opened a GitHub issue to fix this at the source, so site/grid names are made filesystem-safe before they go into output filenames (no more silent 0-byte files on Windows): [Sanitise user identifiers before embedding in output filenames (colon in site name silently corrupts output on Windows via NTFS ADS) · Issue #1619 · UMEP-dev/SUEWS · GitHub](https://github.com/UMEP-dev/SUEWS/issues/1619)