You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Running EnergyPlus with a command like the following will cause it to fail:
energyplus.exe -d D:\ß D:\ß\sample.idf
Output:
EnergyPlus Starting
EnergyPlus, Version 23.2.0-7636e6b3e9, YMD=2024.05.01 11:29
**FATAL:The SQLite database failed to open.
EnergyPlus Run Time=00hr 00min 0.19sec
Program terminated: EnergyPlus Terminated--Error(s) Detected.
If however the folder were named B instead of ß, all else being equal, it would work normally.
The folder D:\ß actually has to exist for this error to occur. The contents of the IDF file don't seem to matter.
Notes - I think the problem occurs when using a folder path having any ASCII/Unicode character over 7F. Furthermore, varied higher bitness characters fail in different ways.
I tried the following examples as folder names (all char values in hex):
B (ASCII 42) - runs normally
� (ASCII 7F or "del" - the last 7-bit value) - not a printable character, but still runs normally
€ (ASCII 80 - the first 8-bit value) - fails with SQLite error
ß (Unicode 00DF) - fails with SQLite error (the example given above)
Б (Unicode 0411) - fails but in a different way - see below
For the example of Б which is 2 bytes in Unicode, EnergyPlus terminates without ever writing anything to the terminal, unlike the 128-bit ASCII and 1-byte Unicode examples which show the SQLite error.
Note on relevance -- This was discovered because I support users who can have usernames containing Unicode characters, and therefore their local paths also contain that character. (Just to point out that this is not at all a hypothetical problem.)
We used to use EnergyPlus 9.5 before updating to 23.2, and to my knowledge never ran into this before. Perhaps this is related to some of the command-line updates for CLI11 in 23.2 (mentioned in #10322) although that's just a guess and might not actually make sense given the SQLite error. [EDIT - maybe similar issues did exist earlier, I'll add a follow up post]
Details
Some additional details for this issue (if relevant):
Platform: Windows 10, 11
Version of EnergyPlus: 23.2
The text was updated successfully, but these errors were encountered:
A colleague ran tests with earlier versions and found similar problems, though the exact error messages are not all the same.
9.5
C:\>EnergyPlus\EnergyPlusV9-5-0\EnergyPlus -d d:\ß\ d:\ß\Test_V950.idf
EnergyPlus Starting
EnergyPlus, Version 9.5.0-de239b2e5f, YMD=2024.05.01 11:56
File "<string>", line 1
SyntaxError: (unicode error) 'utf-8' codec can't decode byte 0xdf in position 0: unexpected end of data
**FATAL:ERROR adding "d:\\▀" to the sys.path in Python
EnergyPlus Run Time=00hr 00min 0.20sec
Program terminated: EnergyPlus Terminated--Error(s) Detected.
9.6
C:\>EnergyPlus\EnergyPlusV9-6-0\EnergyPlus -d d:\ß\ d:\ß\Test_V960.idf
EnergyPlus Starting
EnergyPlus, Version 9.6.0-f420c06a69, YMD=2024.05.01 11:56
File "<string>", line 1
sys.path.insert(0, "d:\\�")
^
SyntaxError: (unicode error) 'utf-8' codec can't decode byte 0xdf in position 0: unexpected end of data
**FATAL:ERROR adding "d:\\ß" to the sys.path in Python
EnergyPlus Run Time=00hr 00min 0.09sec
Program terminated: EnergyPlus Terminated--Error(s) Detected.
22.1
C:\>EnergyPlus\EnergyPlusV22-1-0\EnergyPlus -d d:\ß\ d:\ß\Test_V2210.idf
EnergyPlus Starting
EnergyPlus, Version 22.1.0-ed759b17ee, YMD=2024.05.01 11:57
File "<string>", line 1
SyntaxError: (unicode error) 'utf-8' codec can't decode byte 0xdf in position 0: unexpected end of data
**FATAL:ERROR adding "d:\\ß" to the sys.path in Python
EnergyPlus Run Time=00hr 00min 0.09sec
Program terminated: EnergyPlus Terminated--Error(s) Detected.
22.2
C:\>EnergyPlus\EnergyPlusV22-2-0\EnergyPlus -d d:\ß\ d:\ß\Test_V2220.idf
EnergyPlus Starting
EnergyPlus, Version 22.2.0-c249759bad, YMD=2024.05.01 11:57
File "<string>", line 1
SyntaxError: (unicode error) 'utf-8' codec can't decode byte 0xdf in position 0: unexpected end of data
**FATAL:ERROR adding "d:\\ß" to the sys.path in Python
EnergyPlus Run Time=00hr 00min 0.09sec
Program terminated: EnergyPlus Terminated--Error(s) Detected.
Issue overview
Running EnergyPlus with a command like the following will cause it to fail:
energyplus.exe -d D:\ß D:\ß\sample.idf
Output:
If however the folder were named
B
instead ofß
, all else being equal, it would work normally.The folder
D:\ß
actually has to exist for this error to occur. The contents of the IDF file don't seem to matter.Notes - I think the problem occurs when using a folder path having any ASCII/Unicode character over 7F. Furthermore, varied higher bitness characters fail in different ways.
I tried the following examples as folder names (all char values in hex):
B
(ASCII 42) - runs normally�
(ASCII 7F or "del" - the last 7-bit value) - not a printable character, but still runs normally€
(ASCII 80 - the first 8-bit value) - fails with SQLite errorÂ
(Unicode 00C2) - fails with SQLite errorß
(Unicode 00DF) - fails with SQLite error (the example given above)Б
(Unicode 0411) - fails but in a different way - see belowFor the example of
Б
which is 2 bytes in Unicode, EnergyPlus terminates without ever writing anything to the terminal, unlike the 128-bit ASCII and 1-byte Unicode examples which show the SQLite error.Note on relevance -- This was discovered because I support users who can have usernames containing Unicode characters, and therefore their local paths also contain that character. (Just to point out that this is not at all a hypothetical problem.)
We used to use EnergyPlus 9.5 before updating to 23.2, and to my knowledge never ran into this before. Perhaps this is related to some of the command-line updates for CLI11 in 23.2 (mentioned in #10322) although that's just a guess and might not actually make sense given the SQLite error. [EDIT - maybe similar issues did exist earlier, I'll add a follow up post]
Details
Some additional details for this issue (if relevant):
The text was updated successfully, but these errors were encountered: