Activity for OpenDSS
-
Davis Montenegro posted a comment on discussion Open Discussion
Thanks Alex, It’s pretty incredible how much can change in just a couple of years. Large language models are everywhere now, and I’m seeing more and more OpenDSS users experimenting with AI assistants built specifically to work with the tool. Some of these efforts are even coming from industry groups that want to push power‑system simulation tools like DSS forward. What’s interesting is that the industry seems to be taking the lead naturally—using DSS as the simulation backbone while layering modern...
-
Alex Payne modified a comment on discussion Open Discussion
This is a thoughtful suggestion, especially considering how much time engineers spend navigating documentation and debugging interface functions. An AI chatbot integrated with OpenDSS could significantly streamline workflows by providing instant, context-aware assistance for Matlab and Python COM interactions. Tools like the MATLAB AI chat feature have already shown how effective real-time support can be in improving productivity and reducing friction in complex tasks. It would be great to see OpenDSS...
-
This is a thoughtful suggestion, especially considering how much time engineers spend navigating documentation and debugging interface functions. An AI chatbot integrated with OpenDSS could significantly streamline workflows by providing instant, context-aware assistance for Matlab and Python COM interactions. Tools like the MATLAB AI chat feature have already shown how effective real-time support can be in improving productivity and reducing friction in complex tasks. It would be great to see OpenDSS...
-
Paulo Meira committed [r4143] on Code
OpenDSSC/Storage: fix init for dynamics in `InitStateVars`
-
OpenDSSC: fix formatting specifiers in some files (numbers were truncated to low precision).
-
OpenDSSC: Remove `Slice` (not useful in C++) and allow vectors in `TCommandList`.
-
OpenDSSC: Revert part of r4061 and handle some related issues
-
OpenDSSC/ClangFormat: specify line-endings and disable `SortIncludes`.
-
Hello, I think I need to understand your setup a bit better, because the issue you’re running into sounds more conceptual than technical. When you’re working within an OpenDSS session, whether it’s running locally or in the cloud, you don’t need to recompile the model every time you run a power flow. Once the session is up, the model stays in memory as long as that OpenDSS host process is alive. That’s why it sounds to me like you might be spinning up a Lambda function for each run, or maybe using...
-
Hello, I think I need to understand your setup a bit better, because the issue you’re running into sounds more conceptual than technical. When you’re working within an OpenDSS session, whether it’s running locally or in the cloud, you don’t need to recompile the model every time you run a power flow. Once the session is up, the model stays in memory as long as that OpenDSS host process is alive. That’s why it sounds to me like you might be spinning up a Lambda function for each run, or maybe using...
-
PAnderson posted a comment on discussion Open Discussion
Hello, I am using OpenDSS in a cloud environment and wanted to ask about a limitation I’m currently facing. My architecture is serverless, so each execution is short-lived. As a result, I need to compile the DSS files every time I run a power flow. For example, if I want to run the same circuit with 5 different load profiles (without any topology changes), I currently need to reload and compile the DSS files 5 times. For larger models, the compilation time becomes a significant overhead. Is there...
-
Andres Ovalle modified a comment on discussion Help
Hi Alex, The difference between both definitions is the winding where you change the default Rneut and Xneut values. For the first definition, you explicitly define them on the second winding. For the second definition, you define them on the last active winding (wdg=3, so you leave your secondary wdg ungrounded on the second definition). You can double check this with dump transformer.* or run a fault study with solve mode=fault and show fault and compare the currents you get for each fault type...
-
Hi Alex, The difference between both definitions is the winding where you change the default Rneut and Xneut values. For the first definition, you explicitly define them on the second winding. For the second definition, you define them on the last active winding (wdg=3, so you leave your secondary wdg ungrounded on the second definition). You can double check this with dump transformer.* or run a fault study with solve mode=fault and show fault and compare the currents you get for each fault type...
-
Hi Alex, The difference between both definitions is the winding where you change the default Rneut and Xneut values. For the first definition, you explicitly define them on the second winding. For the second definition, you define them on the last active winding (wdg=3, so you leave your secondary wdg ungrounded on the second definition). You can double check this with dump transformer.* or run a fault study with solve mode=fault and show fault and compare the currents you get for each fault type...
-
Alex Anderson modified a comment on discussion Help
Running into an issue that it doesn't seem to be possible to specify grounded wye transformers using the array format. Specifying the transformer as three separate winding gives the correct behavior New Transformer.Sub3 Phases=3 Windings=3 XHL=0.01 XHT=0.025 XLT=0.025 ~ wdg=1 bus=SourceBus conn=delta kv=115 kva=5000 %r=(.5 1000 /) ~ wdg=2 bus=650.1.2.3.4 Rneut=0 Xneut=0.4 conn=wye kv=4.16 kva=5000 %r=(.5 1000 /) ~ wdg=3 bus=650z conn=wye kv=13.2 kva=1000 %r=(.5 1000 /) Bus Node VLN (kV) Angle pu...
-
Running into an issue that it doesn't seem to be possible to specify grounded wye transformers using the array format. Specifying the transformer as three separate winding gives the correct behavior New Transformer.Sub3 Phases=3 Windings=3 XHL=0.01 XHT=0.025 XLT=0.025 ~ wdg=1 bus=SourceBus conn=delta kv=115 kva=5000 %r=(.5 1000 /) ~ wdg=2 bus=650.1.2.3.4 Rneut=0 Xneut=0.4 conn=wye kv=4.16 kva=5000 %r=(.5 1000 /) ~ wdg=3 bus=650z conn=wye kv=13.2 kva=1000 %r=(.5 1000 /) Bus Node VLN (kV) Angle pu...
-
This worked. Thanks.
-
Oh yes, that is common. Instead of clicking on the file, click in the button at the top that says "Download Snapshot", this will download the file for you within a zip file. Please let me know how it goes. Best,
-
Interesting that Source Forge has a size limit on the download. Got this error: File is 33.5 MB. Too large to download.
-
Hello, The documentation is distributed normally as a CHM file, you can download it here: https://sourceforge.net/p/electricdss/code/HEAD/tree/trunk/Version8/Distrib/Doc/OpenDSS%20Documentation.chm However, this is a Windows native format, but there are options if you want to read it in other OS like Linux: https://www.baeldung.com/linux/compiled-html-help-files . Please give it a try in the meantime. Best,
-
Apologies for a late response and great to hear that the update is in progress. Can you please attach the latest version of the documentation here? I am not in a Windows environment so will be unable to download the app.
-
C Wilson posted a comment on discussion Help
I am a new user of OpenDSS and wanted to implement simulations of communications-based protection schemes using the distance relay, particularly a DCB scheme. It looks as though using the python interface with a time-series dynamic solution might be the best way to get this done (open to input on that). But, looking into it, I don't see where I can access whether or not the relay is picked up in any location other than the debugtrace eventlog report, just wanted to confirm that I am not missing something...
-
For the time being, I left the branch that reorders the headers on GitHub here. Although it does touch a lot of files, it's not a lot of changes. Comparison here: https://github.com/dss-extensions/opendss-svn-mirror/compare/opendssc...opendssc-headers
-
Ed Beroset posted a comment on discussion Experts
Hi Davis, Got it and replied. I'm interested! Ed
-
Hi Alfonso, I gave it a try with some basic scripting, and everything behaved pretty much as I expected. I added a PV system with an InvControl to the model and ran four sequential 24‑hour simulations starting at time 0, adjusting the X values of the control curve each time. As you can see in the results, the reactive power injected by the PV follows the shape of the control curve, which gets progressively narrower in this setup. Take a look when you get a chance (attached - see script Solve_InvCtrl_XYCurve_dyn.dss),...
-
Hi Ed, Complementing Andres' reply, I think there is a way to work on a C++ idiomatic version without affecting EPRI's approach. I sent you a message through inbox, let me know if you got it. Lets get together and discuss this approach since, I believe it has significant value. Best,
-
Hi, Junjia, version 11.0.0.1 . Meanwhile, the local opendssdirect.py version is 0.9.4. Is there any version mismatch? Yes, 11.0.0.1 was released recently, on 2026-01-30. The pre-releases for ODD.py include the most relevant changes from that in the default AltDSS engine shipped on ODD.py, plus it can load the DLL from EPRI's latest release. Do you have any further suggestions on what else I might check or test? At first, I'd recommend trying the ODD.py pre-release for two reasons: the default engine...
-
Hi, Junjia, version 11.0.0.1 . Meanwhile, the local opendssdirect.py version is 0.9.4. Is there any version mismatch? Yes, 11.0.0.1 was released recently, on 2026-01-30. The pre-releases for ODD.py include the most relevant changes from that in the default AltDSS engine shipped on ODD.py, plus it can load the DLL from EPRI's latest release. Do you have any further suggestions on what else I might check or test? At first, I'd recommend trying the ODD.py pre-release for two reasons: the default engine...
-
Junjia Yang posted a comment on discussion Open Discussion
Hi Paulo, Thank you very much for the detailed explanation and suggestions. Really appreciate your time and help! Following your advice, I have updated PVSystemList to DERList, added a check for dss.Solution.Converged(), and also verified the OpenDSS GUI version on my system, which is version 11.0.0.1 . Meanwhile, the local opendssdirect.py version is 0.9.4. Is there any version mismatch? Unfortunately, I am still observing the same convergence issue in the GUI when MonBus is specified, so I suspect...
-
OpenDSSC/XfmrCode: fix PullFromTransformer (off-by-one error).
-
OpenDSSC/Recloser, Fuse: fix `"none"` strings (double quotes).
-
Hi, OpenDSS GUI Which versions did you check? IIRC, there was a bug in OpenDSS versions 9.6...9.8. It should be fixed in later versions. opendssdirect Besides the issue with older OpenDSS releases, there could be a bug in OpenDSSDirect.py if you're using old versions. Note that the default engine on OpenDSSDirect.py is AltDSS, not EPRI's binaries. It may not the case here, but if you need something specific to ODD.py, please report on GitHub (either https://github.com/dss-extensions/OpenDSSDirect.py/issues...
-
Hi, I am encountering a convergence issue with InvControl in the OpenDSS GUI that does not occur when running the same simulation via Python (opendssdirect). The problem: In the GUI, the simulation fails to converge with a "Max Control Iterations" warning as attached screenshot. In Python, using the same parameters, the solution converges reliably within 2–9 iterations. I have isolated the issue to the MonBus property in the InvControl definition. When MonBus is removed, the GUI converges, but I...
-
Ed, the plan for now is to continue with the approach we have been following, basically maintaining both versions 1:1 with the delphi one leading.
-
Speaking of reworking the C++ code, is there any desire to update it to make it more idiomatic C++, or is it intended to forever remain a 1:1 literal translation of the Pascal code? I'd be happy to help with it either way, but wanted to get some clarity on the intended trajectory before I spend significant time on it. Better still, if there is a wish-list of items for the C++ code, point me to it and I would be willing to take a look.
-
Speaking of reworking the C++ code, is there any desire to update it to make it more idiomatic C++, or is it intended to forever remain a 1:1 literal translation of the Pascal code? I'd be happy to help with it either way, but wanted to get some clarity on the intended trajectory before I spend significant time on it.
-
Hi, all, I also have a local branch that works around the std::complex with newer compilers (actually C++ standard library changes). In this branch, basically, the order of some includes was changed and Ucomplex is explicitly used in some files. This is indeed required to build with more modern compilers, and doesn't affect older compilers. I wouldn't necessary worry about removing using namespace std; until the d2c code is reworked. IMHO, it will affect a lot more lines/files than just working around...
-
Thanks Ed, This sounds like a coming thing, and since Paulo Meira is also pointing it out, I think its worth of a discussion. I'll reach out to you guys briefly. Best,
-
Hi, all, I also have a local branch that works around the std::complex with newer compilers (actually C++ standard library changes). In this branch, basically, the order of some includes was changed and Ucomplex is explicitly used in some files. This is indeed required to build with more modern compilers, and doesn't affect older compilers. I wouldn't necessary worry about removing using namespace std; until the d2c code is reworked. IMHO, it will affect a lot more lines/files than just working around...
-
Hi, all, I also have a local branch that works around the std::complex with newer compilers (actually C++ standard library changes). In this branch, basically, the order of some includes was changed and Ucomplex is explicitly used in some files. This is indeed required to build with more modern compilers, and doesn't affect older compilers. I wouldn't necessary worry about removing using namespace std; until the d2c code is reworked. IMHO, it will affect a lot more lines/files than just working around...
-
Affonso Ribeiro posted a comment on discussion Open Discussion
Hello, how are you? I am conducting an optimization study on the parameters of volt-var and volt-watt control curves for photovoltaic inverters. I have the attached system implemented (only the DG implementation) in OpenDSS + Python, where I run the simulation, collect the voltages for each hour, and based on that, using a genetic algorithm, I try to optimize the parameters of the inverter control's XYCurve. Overall, I have already verified that I am successfully updating the curve values (Xarray)...
-
Hi Davis, Thanks! I am using Fedora 43 distro which tends to be bleeding edge. In this case, it uses clang version 19.1.7 and gcc version 15.2.1 (I tried both). I've watched the video and the prerequisites are installed already, so I'm in the VersionC directory and from the command line, used cmake -DCMAKE_BUILD_TYPE=Release -S . -B build && cmake --build build. I suspect that when the other distros change to a newer version, this same problem will manifest on those platforms as well.
-
Hi Ed, Thanks for bringing this up and for the suggestions. To add to Davis' comment, there is one pending change to port to the C++ version around changes recently made to Relay.pas and associated changes in the direct dll. Once those are complete we will update Current_ver.txt. Thanks, Andres
-
Hi Ed, Long time no see, Sir. It does look like the version file wasn’t updated on the C++ side. I checked with Andrés, though, and most of the enhancements from Delphi version 11 are already in the C version, or at least the ones I worked on. Regarding the complex declaration, I can give it a look just to verify, however it doesn't seem to break anything so far. But probably I haven't seen the problem yet. I'll give it a try and will get back to you with my conclusions. Thank you Sir. Best,
-
Hi Ed, Long time no see, Sir. It does look like the version file wasn’t updated on the C++ side. I checked with Andrés, though, and most of the enhancements from Delphi version 11 are already in the C version, or at least the ones I worked on. As for compilation, I’m not seeing any issues. I’ve been building the latest code on Debian, Ubuntu, and a few other Linux distributions without problems. I’m curious about the exact procedure you’re following. The one listed here: https://opendss.epri.com/CompileusingCMDTerminal.html...
-
Hi Ed, Long time no see, Sir. It does look like the version file wasn’t updated on the C++ side. I checked with Andrés, though, and most of the enhancements from Delphi version 11 are already in the C version, or at least the ones I worked on. As for compilation, I’m not seeing any issues. I’ve been building the latest code on Debian, Ubuntu, and a few other Linux distributions without problems. I’m curious about the exact procedure you’re following. The one listed here: https://opendss.epri.com/CompileusingCMDTerminal.html...
-
I was hoping to compile the C++ version of OpenDSS 11 but I have encountered a few problems. First, I'm using svn://svn.code.sf.net/p/electricdss/code/trunk/VersionC revision 4136 which appears to be the latest, but the Current_ver.txt file there indicates 10.1.0.1, leading me to suspect there is not yet parity between the Pascal and C++ version. Second, that doesn't compile because the reference to complex is ambiguous; it could be struct Ucomplex::complex or it could mean std::complex. Part of...
-
Minor additional cleanup of hnd (fixed a few typos).
-
wsunderm1 committed [r4135] on Code
Committing sws footer and about changes
-
Minor pending updates and cleanups to documentation in preparation to publish updated documentation site.
-
Currently, the system behaviour looks reasonable, and the overall voltage range remains within a normal range under high PV penetration. and I suspect the 0.5p.u. is due to the fact that dss.Bus.PuVoltage[0::2] only got the real part of the complex array. After correcting the calculation to use the magnitude as below, the result is around 1.01p.u., which makes sense. v_pu_node1 = math.sqrt(v_pu_complex[0]**2 + v_pu_complex[1]**2) I then confirmed that the actual issue was related to how InvControl...
-
Hi Davis, Thank you very much for your detailed suggestions and for taking the time to look into my question.Really appreciate your prompt response. I had continued investigating the issue and found a workaround using the MonBus property to explicitly specify the monitored voltage for the inverter control. With the modification below, the Volt–VAR control appears to operate as expected:: New InvControl.InvPVCtrVV_pv_load_p1ulv37946 mode=VOLTVAR voltage_curvex_ref=rated **monVoltageCalc=AVG MonBus=[p1ulv37946.1.2]...
-
Hello, After reviewing your description, I have a few recommendations: DC/AC Ratio: Your DC/AC ratio is currently greater than 1. Was this intentional? With this setup, you leave essentially no headroom for VAR support. I would suggest using a DC/AC ratio below 1 instead, meaning the inverter kVA rating should exceed the pmpp. PV Connection Type: The PV system is modeled as wye-connected even though it is electrically tied between phases. In this case, a delta connection is more appropriate. In fact,...
-
I realized my earlier description might have been a bit confusing in words, so I have attached a simple diagram to illustrate the configuration. In this LV system, the loads are connected phase-to-neutral (120 V), while the PV inverter is connected across two phases (240 V). The diagram below shows the setup more clearly.
-
Hi, I am struggling to use InvControl for my PVSystem. The PV is installed at LV side as: New PVSystem.pv_load_p1ulv37946 bus1=p1ulv37946.1.2 phases=1 kV=0.24 kVA=83.33333333333334 Pmpp=100.0 kvarmax=36.66666666666667 %Cutout=0.1 %Cutin=0.1 Model=1 irradiance=1 !yearly=AUS_30.3828_-97.8095_15_180 The control curve is defined as: New XYCurve.VoltVarCurve_p1uhs4_1247_p1uhs4_1247--p1udt21090 npts=6 Yarray=(1.0,1.0,0.0,0.0,-1.0,-1.0) Xarray=(0.5,0.92,0.98,1.02,1.08,1.5) The corresponding InvControl is:...
-
Paulo Radatz posted a comment on discussion Open Discussion
You can find the latest documentation in the download folder for the current OpenDSS version (11.0.0.1). "C:\Program Files\OpenDSS\Doc\OpenDSS Documentation.chm" The online documentation update is in progress and will be uploaded soon. Thank you. Best regards, Paulo Radatz
-
Wondering if the EPRI team is working on updating the documentation to the latest version OpenDSS . The documentation mentioned in the official download page: is outdated (dated back to 2024) and have missing features from the latest version. Eg. RegControl properties do not include Cogen property. Furthermore, the reversible property is described as binary: {Yes/No} whereas the latest version expects something else based on the discussion here. The community would expect at least an up-to-date documentation...
-
Wondering if the EPRI team is working on updating the documentation to the latest version OpenDSS . The documentation mentioned in the official download page: is outdated (dated back to 2024) and have missing features from the latest version. Eg. RegControl properties do not include Cogen property. Furthermore, the reversible property is described as binary: {Yes/No} whereas the latest version expects something else based on the discussion here The community would expect at least an upto date documentation...
-
Wondering if the EPRI team is working on updating the documentation to the latest version OpenDSS . The documentation mentioned in the official download page: is outdated (dated back to 2024) and have missing features from the latest version. Eg. RegControl properties: https://opendss.epri.com/Properties23.html do not include Cogen property. Furthermore, the reversible property is described as binary: {Yes/No} whereas the latest version expects something else based on the discussion here: https://sourceforge.net/p/electricdss/discussion/861976/thread/fb726899ee/?limit=25#a426/c97c...
-
Bryan posted a comment on discussion Beginners
Thanks!! And Yes, I will check and try by your suggestion. If I have still problems, I will make a new ticket (new window) for my issue. Thanks agin and have a wonderful day.
-
Thanks!! And Yes, I will check and try by your suggestion. If I have still problems, I will make a new ticket (new window) for my issue. Thanks agin and have a wonderful day.
-
Yes, it's definitely possible to design the scenarios in the OpenDSS with the IEEE123 bus test system. You might consider relaxing the OV HC criteria since the voltage is already at 1.05puV. Maybe you could set it to 1.06puV or something similar. Then size the PV such that your voltage at times does exceed 1.06puV and sometimes does not exceed 1.06puV. Maybe 1.06puV is too high of a value, so you can set it to whatever makes sense for the educational cases you are developing. It may also be advantageous...
-
Thank you very much for your kind response. However, I believe the intent of my question may not have been fully conveyed. Our goal is to design five PV scenarios such that some satisfy the feasibility criteria (0.95 pu < Vmin, Vmax < 1.05 pu, and Load % < 100%), while others intentionally violate one or more of these conditions. However, after disabling the regulators for the Hosting Capacity study and adding PV, all scenarios appear to violate the criteria in a similar manner. We would like students...
-
For educational purposes, I think the IEEE123 bus test system is good. I would recommend solving the circuit first, with the regulators still active. This should give you a minimum voltage of roughly 0.979 puV and a maximum voltage of 1.05puV. Then disable the regulators for the HC study. Add the PV, and then solve again. This is the sequence that I would follow: Clear Compile IEEE123Master.dss Solve Disable RegControl.* ** Add PV ** Solve As for setting up the individual cases to show different...
-
Thanks and Yes, I resolved my previous problems. Thanks and I have extended questions from my 1st one. I am currently conducting a small hosting capacity exercise using the IEEE 123 test feeder (please see the attached screenshot). After compiling IEEE123Master.dss and disabling RegControl, the baseline minimum voltage drops to approximately 0.92 pu before any PV is connected. Under a strict 0.95 pu voltage criterion, all subsequent PV scenarios are classified as infeasible. Question 1) Is this behavior...
-
Thanks a lot and Yes, I resolved my previous problems. Thanks and I have extended questions from my 1st one. I am currently conducting a small hosting capacity exercise using the IEEE 123 test feeder (please see the attached screenshot). After compiling IEEE123Master.dss and disabling RegControl, the baseline minimum voltage drops to approximately 0.92 pu before any PV is connected. Under a strict 0.95 pu voltage criterion, all subsequent PV scenarios are classified as infeasible. Question 1) Is...
-
A few things that I see: For your case 1, you are trying to place a three-phase generator on bus 75. Looking at the IEEE123master.dss in the line definitions, I see the following definition for the line: New Line.L75 Phases=1 Bus1=74.3 Bus2=75.3 LineCode=11 Length=0.4 units=kft I see that the line has a .3 for the bus1 and bus2 definition. This means that there is only 1 node (phase) present, and it is node 3 (typically we refer to that as "C" phase). Confirming the number of phases, we can look...
-
Question 1) No change in Vmin/Vmax and Thermal Loading (%) I ran three PV generator cases on the IEEE 123 Test Feeder by pasting the commands into the OpenDSS Command window (including Compile, Disable RegControl.*, and Solve). However, the Summary values (Vmin/Vmax in pu) and Thermal Loading (%) (Current → Sequence view) did not change at all across the three cases. Could you please advise what is most likely? Is the PV size still too small relative to the IEEE 123 feeder, so the impact is negligible?...
-
If the goal is to control the inverter PF directly, I would not include the InvControl. It will over-ride any PF settings that the PVSystem is defined with (from your optimization routine), during the OpenDSS control loop, based on the vvar_curve and InvControl settings. For the PF sign, the OpenDSS help shows how it operates. Here's the snippet from the OpenDSS help that is in the program, for PF for the PVSystem: PF: "Setting this property will cause the inverter to operate in constant power factor...
-
I am performing a heuristic optimization for voltage control in an electrical distribution network through the “dispatch” of reactive power from photovoltaic inverters, in the context of distributed generation. Below is my current parameter model. To control the injection/absorption of reactive power, I need to control the inverter variable PF (power factor), where a negative value indicates reactive power absorption and a positive value indicates reactive power injection. Is that correct? If you...
-
I am performing a heuristic optimization for voltage control in an electrical distribution network through the “dispatch” of reactive power from photovoltaic inverters, in the context of distributed generation. Below is my current parameter model. To control the injection/absorption of reactive power, I need to control the inverter variable PF (power factor), where a negative value indicates reactive power absorption and a positive value indicates reactive power injection. Is that correct? If you...
-
I am performing a heuristic optimization for voltage control in an electrical distribution network through the “dispatch” of reactive power from photovoltaic inverters, in the context of distributed generation. Below is my current parameter model. To control the injection/absorption of reactive power, I need to control the inverter variable PF (power factor), where a negative value indicates reactive power absorption and a positive value indicates reactive power injection. Is that correct? If you...
-
EPRI created a blog post
OpenDSS Version 11.0.0.1 - Charlottesville - Released
1 >
