Bug description
Setting dss.generators.vmin_pu and dss.generators.vmax_pu via the property API appears to succeed (the getter returns the new value), but the value is not persisted to the underlying OpenDSS C engine. This causes silent data corruption in power flow results.
The equivalent load properties (dss.loads.vmin_pu, dss.loads.vmax_pu) work correctly.
Reproduction
import py_dss_interface
dss = py_dss_interface.DSS()
dss.text("compile [master.dss]")
dss.generators.name = "sgen_0"
# Write via property API
dss.generators.vmin_pu = 0.0
# Read back via property — looks OK
print(dss.generators.vmin_pu) # → 0.0
# Read back via text command — value unchanged!
print(dss.text("? Generator.sgen_0.Vminpu")) # → 0.90 (default)
Expected: Both should return 0.0.
Actual: The text command reveals the C engine still has the default value.
Root cause
The bug is in the OpenDSS C library (libOpenDSSC.so), not in py-dss-interface's Python code.
In GeneratorsF.py, the setters correctly call:
GeneratorsF(11, value) for Vmaxpu
GeneratorsF(13, value) for Vminpu
However, the C library's handler for these indices doesn't write the value to the active Generator object — it only echoes the parameter back. The equivalent DSSLoadsF handler (indices 29/35 for loads) works correctly.
Impact
When Vminpu/Vmaxpu are not actually set, OpenDSS uses the defaults (0.90/1.10) and may switch the generator model from constant power to constant impedance at unexpected voltage levels, producing different P/Q results without any warning.
Workaround
Use text commands instead of the property API:
dss.text(f"Generator.{name}.Vminpu=0.0")
dss.text(f"Generator.{name}.Vmaxpu=2.0")
Fix
PR #106 implements this workaround directly in GeneratorsF.py, replacing the broken C API calls with text commands while keeping the same public API.
Environment
- py-dss-interface version: 2.2.1 and master (2.3.0)
- Platform: Linux (tested)
- OpenDSS C library: bundled
libOpenDSSC.so
Bug description
Setting
dss.generators.vmin_puanddss.generators.vmax_puvia the property API appears to succeed (the getter returns the new value), but the value is not persisted to the underlying OpenDSS C engine. This causes silent data corruption in power flow results.The equivalent load properties (
dss.loads.vmin_pu,dss.loads.vmax_pu) work correctly.Reproduction
Expected: Both should return
0.0.Actual: The text command reveals the C engine still has the default value.
Root cause
The bug is in the OpenDSS C library (
libOpenDSSC.so), not in py-dss-interface's Python code.In
GeneratorsF.py, the setters correctly call:GeneratorsF(11, value)forVmaxpuGeneratorsF(13, value)forVminpuHowever, the C library's handler for these indices doesn't write the value to the active Generator object — it only echoes the parameter back. The equivalent
DSSLoadsFhandler (indices 29/35 for loads) works correctly.Impact
When
Vminpu/Vmaxpuare not actually set, OpenDSS uses the defaults (0.90/1.10) and may switch the generator model from constant power to constant impedance at unexpected voltage levels, producing different P/Q results without any warning.Workaround
Use text commands instead of the property API:
Fix
PR #106 implements this workaround directly in
GeneratorsF.py, replacing the broken C API calls with text commands while keeping the same public API.Environment
libOpenDSSC.so