(Last update: 9th Mar 2014. Some of the comments below have direct inputs from Roger Dugan)
Use the right frequency
Always set the default base frequency to the one you normally use. Otherwise, if a circuit is specified with a different one, it will not run.
Don't forget the "sourcebus"
>> Set DefaultBaseFrequency=50
This might be obvious, but do not forget to define the "sourcebus" (i.e., the slack/reference bus) when appropriate (through a transformer or a line).
OpenDSS models networks as if they were 'real' networks. This means that for you to get 'data' out of it, you need to 'deploy' monitoring devices (particularly when doing time-series analyses and using the COM interface). These monitoring devices are divided into two categories: energy meters and monitors.
|---------| element |---------|----> Load
Energy Meter/Monitor at Terminal 1 will consider load-led current as positive, given that the model assumes currents flowing to the 'right'.
Energy Meter/Monitor at Terminal 2 will consider load-led current as negative, given that the model assumes currents flowing to the 'left'.
It is sensible to have one at the GSP to meter net imports/exports (in the presence of DG) and total losses. Bear in mind it is not possible to use meters for loads alone. Either one needs to use monitors or create a line connecting the load and actual connection point so the meter can be 'attached' to one of the ends. Meters can only be used in power delivery elements. If fictitious lines need to be created, use very low values of R and X=0.
Finally, note that energy meters do not work well for meshed networks. For instance, losses cannot be calculated with energy meters hence an indirect approach (via monitors) should be adopted.
Time-Series Analysis (Modes)
Loads (and generators) are first specified in terms of how they will be modelled, e.g. as 'daily' or 'yearly'.
When setting the solution mode this has to be consistent, i.e., daily/yearly for loads -> daily/yearly for the mode
Preparing the COM Interface (for Excel, Matlab, etc.)
Update: the comments below correspond to versions of OpenDSS previous to 7.6. The current OpenDSS installer automatically registers the OpenDSSEngine.DLL (not the ParserX though).
To use the COM interface you need to register the DLL Engine. If you update the OpenDSS version, then re-register the corresponding DLL.
Use the command prompt (run cmd from the start menu) as an Administrator. Then go to the folder where OpenDSS was installed and issue the following command:
If you are using ParserX (required for handling CSV files more effectively), it also needs to be registered (files are found in ...\OpenDSS\Examples\Excel\).
If you decide to move OpenDSS to another folder, then remember to register the DLL and the ParserX again. Otherwise, problems might arise when using the COM interface.
Using Vista or Windows 7? Click here (basically you need run the Command Prompt as an administrator).
Using Excel's VBA and the COM Interface
Do not forget to 'activate' macros.
When using different Excel versions certain libraries will not be 'found'. Untick these 'missing' libraries (tools-references) and reboot the computer.
Also, if you need to use previous versions of Excel, first downgrade the file (e.g., saving it from 2007 to 2003) before using it. Otherwise, problems running the VBA code will occur.
When compiling an OpenDSS file note that the compile command (DSSText.Command = "compile c:\example.dss") will not be able to cater for a path with blank spaces (e.g., c:\abc and def\example.dss), so modify your working path accordingly (e.g., c:\abc_and_def\example.dss).
Bear in mind that elements that do not contain more than one data and are defined/dimensioned as 'variant' will not be able to be treated as matrices.
Using the Redirect Command
When writing significant volumes of code (e.g., for a big network) it is advisable to be organised and use the 'redirect' command. Basically, you can at any point in the main code redirect it to a TXT file containing more code. For instance, you can have a line stating "Redirect Lines.txt" in which the file "Lines.txt" (in the same path as the main code) will contain all the info re the lines.
Note that if the main code (containing redirects) is to be compiled externally (e.g., from Excel VBA or Matlab) then it should be a TXT file as well - not a DSS file.
Modifying Parameters of Network Elements
Although most parameters of network elements are accessible via the COM interface, in some cases this is not possible. An alternative to this is via the use of the Active Circuit Element (only to certain parameters, for instance "enabled"). You need first to define a variable and assign it to the CktElement interface sometime after you start things up. That would be something like
DSSElement = DSSObj.ActiveCircuit.ActiveCktElement
Then whenever you select, for instance, a load by whatever means (such as looping through the Loads collection), you can just use the command below when you get to one you want to disable.
Also note that if the changes you want to do to a parameter is for all the corresponding elements in a circuit, then you can use the BatchEdit command. Here an example for the ZIPV of all loads.
DSSText.Command = [‘Batchedit Load..* ZIPV=[‘ num2str(num1) num2str(num2) … etc… num2str(num7) ‘]’ ]
Voltage Impact Analysis or Control - Be careful with the default voltages for loads and generators (Vmaxpu and Vminpu)
For loads the default values of Vmaxpu and Vminpu are 1.05 and 0.95, beyond these values the load model reverts to a constant impedance model. A similar default condition (but with different values) exists for generators. If you are carrying out voltage impact analysis or voltage control then it is crucial to set this values beyond what you are expecting to have as problems (e.g., Vmaxpu=1.15 and Vminpu=0.85). In this way you ensure the load or generator models you originally adopted are not reverted to constant impedance.LV Networks (three phases plus neutral)
The neutral can be explicitly model in OpenDSS (see Training Material part 4). By doing this it is possible to place monitors (e.g., for the neutral currents). This, however, creates another problem: voltages monitored will be line-to-ground rather than line-to-neutral. So, unless it is necessary, it's better to avoid explicitly defining the neutral.
Note that not defining the neutral does not mean that OpenDSS does not consider it. If positive-sequence impedances (derived from four-wire cables) are provided, then it will automatically create the 4x4 matrices and compute the effects of the neutral. The phase voltage results will be line-to-neutral voltages (which is what we want).
OpenDSS considers the impedance changes due to taps. The transformer object assumes the same percent impedance (%Z) for all tap positions on a 2-winding transformer. However, the ohmic impedance will be different looking into the winding assumed to have the taps. The ohmic value changes proportional to the %Z but by the square of the tap.