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.
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
Any other SuPy or SUEWS questions are very welcome here, and we are happy to help.
2 Likes
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 !
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!
sma01.yml (431.4 KB)
Hi,
Thank you so much for your help !
Here is the latest version of my YAML file 
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.
1 Like
Thank you so much it was indeed the problem !!
I did the following commands and I finally have some results 
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 !
1 Like
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
1 Like