Support for OpenDSS default values in altdss-schema

[AadilLatif]

We are currently using the opendssdirect.py's Circuit.ToJSON() method to serialize the distribution model. We then use altdss_models to deserialize the model. We use this representation to convert the model into another format (also Pydantic models). The Issue we face is that in the serialized model, many of the fields are None.

Example:

Vsource_MVAsc3MVAsc1x1r1x0r0(
  Name='source', Like=None, 
  Bus1=BusConnection(root='sourcebus'),
 BasekV=115.0,  pu=1.0001, Angle=30.0, Frequency=None, Phases=3, ScanType=None, Sequence=None, Bus2=None, Yearly=None, Daily=None, Duty=None, Model=None, puZIdeal=None, Spectrum=None, BaseFreq=None, Enabled=None, 
MVASC3=20000.0, MVASC1=21000.0, 
X1R1=None, X0R0=None)

In the example above, X1R1 and X0R0 are None, as they are not defined in the master.dss file. Model conversion requires knowledge of these variables to allow us to convert to a different schema.

Observed Issue:

>>> odd.Text.Command("new circuit.test")
>>> odd.Vsource.First()
>>> odd.Vsources.First()
1
>>> odd.Text.Command("? vsource.source.r1")
>>> odd.Text.Result()
'1.60376682055275'

JSON Output:

 "Vsource" : [
    {
      "Name" : "source",
      "MVASC3" : 2.0000000000000000E+003,
      "MVASC1" : 2.1000000000000000E+003,
      "BasekV" : 1.1500000000000000E+002,
      "Bus1" : "sourcebus"
    }

Desired Outcome:

The values in the JSON object are whatever OpenDSS would use to solve the circuit (even if is uses default values)

[PMeira]

That's an open problem indeed.

There are a couple of issues with the defaults, some of them due to how Pydantic handles defaults.

• For this case, if we include all defaults below, the model cannot distinguish which submodel is active since there is no (discriminator) field in the OpenDSS properties to directly select the submodel -- if we don't find another good solution, adding one would work.

    // this is from the internal model, some names are different in the DSS properties
    MVAsc3 := 2000.0;
    MVAsc1 := 2100.0;
    R1 := 1.65;
    X1 := 6.6;
    R2 := R1;
    X2 := X1;
    R0 := 1.9;
    X0 := 5.7;
    Isc3 := 10000.0;
    Isc1 := 10540.0;
    X1R1 := 4.0;
    X0R0 := 3.0;
    PerUnit := 1.0;
    kVBase := 115.0;
    BaseMVA := 100.0;
    ZBase := SQR(kVBase) / BaseMVA;
    SrcFrequency := BaseFrequency;
    Angle := 0.0;
    Scantype := 1;
    SequenceType := 1;

• Many default values are functions, depending on other properties (the easy case to handle with computed properties and similar implementations), or on the circuit properties like the base frequency. For these, we would need a reference to the circuit.

Worst case, maybe adding a "fill_dss_defaults()" method for each submodel would help?

I'm also tracking some issues in Pydantic, especially v2, that affects even discriminated unions. It seems some issues should be fixed in v2.8.

For your example, specifically:

Vsource_MVAsc3MVAsc1x1r1x0r0

In the engine, technically we could mark the four properties (MVAsc3, MVAsc1, x1r1, x0r0) as set. That should be enough to always export them.

Besides digitizing some of my notes, and some experiments with C++ plus Python in this context, publishing some pages equivalent to https://dss-extensions.org/dss-format/Vsource.html but for the JSON Schema model is also in my TODO list. That would make it easier to point with model are problematic, and discussing the issues would be easier.

[AadilLatif]

Thank you for the quick response.

We had a lot of internal discussions within the larger team. The discriminator approach will not work in certain cases as you pointed out. We will run into the issues you highlight if we go with the discriminator approach.

We are fine with either the computed properties approach or the fill_dss_default (prefered) approach. If you have availability, we can set up a meeting to discuss this further.

[PMeira]

We are fine with either the computed properties approach or the fill_dss_default (prefered) approach.

OK, I'll try to implement this soon. I should be able to work more on this later this week.

If you have availability, we can set up a meeting to discuss this further.

That'd be great if you're available. My schedule is mostly open/flexible from 2024-05-06 to 2024-05-17 (except for 2024-05-07).

[KapilDuwadi]

Hi @PMeira Thanks for your flexibility. What's the best email to send you an invite ? I know this is not the best way to share an email but we can remove the comment once we sent an invite. Thanks.

[PMeira]

@KapilDuwadi I think you can use the email listed here: https://github.com/dss-extensions/dss_capi?tab=readme-ov-file#questions

[KapilDuwadi]

Great I just sent you an email. Let me know if you did not receive it.