powerflow: FBS recorder NAN; NR convergence

2013-01-02
2013-03-16
  • Cedric de La Beaujardiere

    Hi, Happy New Year.

    I am having trouble with NR unable to converge, while FBS gives me NAN (presumably, "Not a Number") for anything I try to record with the multi_recorder.  I have tried with and without loads, and placing triplex_meter above or below triplex_node.  I have measured the meter and the line, all without success.

    When I run using FBS, then look at the output files from my multi_recorder, I get values like:

    # ...
    # timestamp,ohPrimaryLine_4005:current_in_A
    2010-01-01 00:00:00 AST,+1.#QNAN+1.#QNANj
    2010-01-01 00:01:00 AST,+1.#QNAN+1.#QNANj
    2010-01-01 00:02:00 AST,+1.#QNAN+1.#QNANj
    ...
    

    Ideally we would like to use NR rather than FBS, but NR will not converge:

    WARNING [INIT] : installation type not specified
    ERROR [2010-01-01 00:00:00 AST] : node substation_Node (node:0): Newton-Raphson method is unable to converge to a solution at this operation point
    ERROR [2010-01-01 00:00:00 AST] : 2010-01-01 00:00:00 AST: object substation_Node stopped its clock (exec)!
    WARNING [2010-01-01 00:00:00 AST] : last warning message was repeated 1 times
    WARNING [2010-01-01 00:00:00 AST] : synchonization failed
    ERROR [2010-01-01 00:00:00 AST] : exec halted: synchonization failed
    FATAL [2010-01-01 00:00:00 AST] : shutdown after simulation stopped prematurely
    dump to 'gridlabd.xml' complete
    FATAL [2010-01-01 00:00:00 AST] : environment startup failed: Domain error
    

    I am on Windows 7, using gridlabd version 2.2, patch 0, build 4171, Branch "Four Corners", I think the 64Bit version (located in C:\Program Files (x86)\GridLAB-D\bin\gridlabd.exe).

    By the way, in my glm file contents below, in the clock, I used a different timezone, "AST+4ADT", for which I added the following four lines in the appropriate locations of the file etc/tzinfo.txt, but I have the same problems if I use a timezone which already existed in tzinfo.txt:
    AST4 ; Atlantic no DST
    AST+4ADT,M4.5.0/02:00,M10.5.0/02:00 ; Atlantic, DST last Sun/Apr to last Sun/Oct
    AST+4ADT,M4.1.0/02:00,M10.5.0/02:00 ; Atlantic, DST first Sun/Apr to last Sun/Oct
    AST+4ADT,M3.2.0/02:00,M11.1.0/02:00 ; Atlantic, DST second Sun/Apr to first Sun/Nov

    Here is my simplified network:

    #define stylesheet=http://gridlab-d.svn.sourceforge.net/viewvc/gridlab-d/trunk/core/gridlabd-2_0
    module tape;
    module powerflow {
        solver_method NR;
        default_maximum_voltage_error 0.000000001;
    };
    clock {
        timezone AST+4ADT;
        starttime '2010-01-01 00:00:00';
        stoptime '2011-01-01 00:00:00';
    };
    object node {
        name substation_Node;
        phases ABC;
        nominal_voltage 19918.6000823975;
        bustype SWING;
    };
    object transformer_configuration {
        name transformer_config_T1;
        connect_type WYE_WYE;
        primary_voltage 19918.6000823975;
        secondary_voltage 7621.01984024048;
        powerA_rating 10000;
        resistance 0.358999991416931;
        reactance 7.17999982833862;
    };
    object transformer {
        name transformerBank_T1;
        phases ABC;
        from substation_Node;
        to transformerBank_T1_Node;
        configuration transformer_config_T1;
    };
    object node {
        name transformerBank_T1_Node;
        phases ABC;
        nominal_voltage 7621.01984024048;
    };
    object line_spacing {
        name line_spacing_ug_15kv 2CU UG;
        distance_AB 0.29160000000000003;
        distance_BC 0.29160000000000003;
        distance_AC 0.29160000000000003;
        distance_AN 0.6906000000000001;
        distance_BN 0.6906000000000001;
        distance_CN 0.6906000000000001;
    };
    object underground_line_conductor {
        name ug_line_conductor_15kv 2CU UG;
        outer_diameter 0.84960000000000002;
        conductor_gmr 8.8000000000000005E-3;
        conductor_diameter 0.29160000000000003;
        conductor_resistance 0.83952000000000004;
        neutral_gmr 3.1800000000000002E-2;
        neutral_diameter 1.0896000000000001;
        neutral_resistance 0.83160000000000001;
        neutral_strands 16;
        shield_gmr 0;
        shield_resistance 0;
    };
    object line_configuration {
        name line_configuration_4085;
        conductor_A ug_line_conductor_15kv 2CU UG;
        spacing line_spacing_ug_15kv 2CU UG;
    };
    object underground_line {
        name ugPrimaryLine_4085;
        phases A;
        nominal_voltage 7621.01984024048;
        from transformerBank_T1_Node;
        to ugPrimaryLine_4085_Node;
        configuration line_configuration_4085;
        length 116.584609985352;
    };
    object node {
        name ugPrimaryLine_4085_Node;
        phases A;
        nominal_voltage 7621.01984024048;
    };
    object transformer_configuration {
        name transformer_config_3-000727;
        connect_type SINGLE_PHASE_CENTER_TAPPED;
        primary_voltage 7621.01984024048;
        secondary_voltage 239.999897616065;
        powerA_rating 25;
        resistance 0.110000002384186;
        reactance 2.20000004768372;
    };
    object transformer {
        name transformerBank_3-000727;
        phases AS;
        from ugPrimaryLine_4085_Node;
        to transformerBank_3-000727_Node;
        configuration transformer_config_3-000727;
    };
    object node {
        name transformerBank_3-000727_Node;
        phases AS;
        nominal_voltage 138.564005494118;
    };
    object triplex_line_conductor {
        name oh_line_conductor_tri_4 AL Tri 0;
        resistance 2.4516;
        geometric_mean_radius 7.0000000000000001E-3;
    };
    object triplex_line_configuration {
        name line_configuration_4005;
        conductor_1 oh_line_conductor_tri_4 AL Tri 0;
        conductor_2 oh_line_conductor_tri_4 AL Tri 0;
        conductor_N oh_line_conductor_tri_4 AL Tri 0;
    };
    object triplex_line {
        name ohPrimaryLine_4005;
        phases AS;
        nominal_voltage 138.564005494118;
        from transformerBank_3-000727_Node;
    //  to ohPrimaryLine_4005_Node;
        to ohPrimaryLine_4005_Load;
        configuration line_configuration_4005;
        length 90.0940017700195;
    };
    //object triplex_node {
    //  name ohPrimaryLine_4005_Node;
    //  phases AS;
    //  nominal_voltage 138.564005494118;
    //};
    object load {
        phases AS;
        name ohPrimaryLine_4005_Load;
        voltage_A 24.000000 -13.640646j;
        voltage_B -24.000000 -13.640646j;
        voltage_C 0.000000+27.281292j;
        constant_power_A 1400.000000+700.000000j;
        constant_power_B 1400.000000+700.000000j;
        constant_power_C 3500.000000+1750.000000j;
        nominal_voltage 138.564005494118;
    }
    object triplex_meter {
        name serviceLocation_3756_Node_Meter;
    //  parent ohPrimaryLine_4005_Node;
        parent ohPrimaryLine_4005_Load;
        phases AS;
    };
    object multi_recorder {
    //  property ohPrimaryLine_4005:power_in;
        property ohPrimaryLine_4005:current_in_A;
        file "rec.tri_lines.16.csv";
        interval 60;
        limit 60;
    }
    object multi_recorder {
        property serviceLocation_3756_Node_Meter:measured_power;
        file "rec.meters.16.csv";
        interval 60;
        limit 60;
    }
    

    Any help would be greatly appreciated.

    Thank you,
    Cedric

     
  • Jason Fuller

    Jason Fuller - 2013-01-02

    Cedric,

    Since FBS is giving you a NAN, this means that your model has convergence errors.  Here are a few things to check (in order of importance):

    1) The "load" object is not designed to work with the S-phase system, but rather the ABC-system. This is something we should probably catch and not allow the model to attach in this way.  I'm not really sure what that will do w/in the powerflow solution. To fix it, you will want to use a triplex node, which has much of the same functionality (but not all) as the load:

    object triplex_node {
         name triplex_node_A;
         phases AS;
         nominal_voltage 120.00;
    }
    object triplex_line {
         from triplex_node_A;
         to tpm_A;
         groupid Triplex_Line;
         phases AS;
         length 10;
         configuration TLCFG;
    }
    object triplex_meter {
         phases AS;
         name tpm_A;
         nominal_voltage 120;
    }
    object triplex_meter {
         phases AS;
         name triplex_load_node;
         parent tpm_A;
         nominal_voltage 120;
    
         power_1 1000 W; //constant power load on phase 1 to neutral (120V)
         current_2 1 A; //constant current load on phase 2 to neutral (120V)
         impedance_12 100 Ohm; //constant impedance load between phase 1 & 2 (240V)  
    }
    

    2) You've got some odd units in your transformers.  For example, your center-tap transformer shows a per-unit impedance of 0.11+2.20j, but these are typically on the order of 0.0011+0.022j.  Similarly for your WYE-WYE.

    3) Your convergence criteria is really tight (currently 1e-9, or on the order of microvolts).  We typically only use this for validation purposes.  Typical solvers are usually on the order of 1e-3 or at most 1e-6.

    Give those a shot and let's see what happens!

     
  • Jason Fuller

    Jason Fuller - 2013-01-02

    Cedric,

    The second "triplex meter" should be a "triplex node".

    Also note the order of the triplex meter versus triplex node (or load) - if you want to use the meter as a metering device, then connect the load through the meter to the power system.  In other words, make the meter the connection point for the line object, then add the load as a child to that meter.

     
  • Cedric de La Beaujardiere

    Jason,

    Thank you for your suggestions.  I implemented the changes you recommended, but the NR solver still fails to converge.

    Below is the glm I tried to run, which changed from the prior run in that I set the default_maximum_voltage_error to 0.001, I divided the transformer_configurations' resistance and reactance values by 100, I used a triplex_node instead of a load and placed the triplex_meter between it and the triplex_line.  I also used the same power_1, current_2 and impedence_12 values for the triplex_node as you had in your example.  Here is that glm file (which, for my own reference, is called powerflow.16E.SmallModel.WithLoadsAsTriplexNodes.glm):

    #define stylesheet=http://gridlab-d.svn.sourceforge.net/viewvc/gridlab-d/trunk/core/gridlabd-2_0
    module tape;
    module powerflow {
        solver_method NR;
        default_maximum_voltage_error 0.001;
    };
    clock {
        timezone AST+4ADT;
        starttime '2010-01-01 00:00:00';
        stoptime '2011-01-01 00:00:00';
    };
    object node {
        name substation_Node;
        phases ABC;
        nominal_voltage 19918.6000823975;
        bustype SWING;
    };
    object transformer_configuration {
        name transformer_config_T1;
        connect_type WYE_WYE;
        primary_voltage 19918.6000823975;
        secondary_voltage 7621.01984024048;
        powerA_rating 10000;
        resistance 0.00358999991416931;
        reactance 0.0717999982833862;
    };
    object transformer {
        name transformerBank_T1;
        phases ABC;
        from substation_Node;
        to transformerBank_T1_Node;
        configuration transformer_config_T1;
    };
    object node {
        name transformerBank_T1_Node;
        phases ABC;
        nominal_voltage 7621.01984024048;
    };
    object line_spacing {
        name line_spacing_ug_15kv 2CU UG;
        distance_AB 0.29160000000000003;
        distance_BC 0.29160000000000003;
        distance_AC 0.29160000000000003;
        distance_AN 0.6906000000000001;
        distance_BN 0.6906000000000001;
        distance_CN 0.6906000000000001;
    };
    object underground_line_conductor {
        name ug_line_conductor_15kv 2CU UG;
        outer_diameter 0.84960000000000002;
        conductor_gmr 8.8000000000000005E-3;
        conductor_diameter 0.29160000000000003;
        conductor_resistance 0.83952000000000004;
        neutral_gmr 3.1800000000000002E-2;
        neutral_diameter 1.0896000000000001;
        neutral_resistance 0.83160000000000001;
        neutral_strands 16;
        shield_gmr 0;
        shield_resistance 0;
    };
    object line_configuration {
        name line_configuration_4085;
        conductor_A ug_line_conductor_15kv 2CU UG;
        spacing line_spacing_ug_15kv 2CU UG;
    };
    object underground_line {
        name ugPrimaryLine_4085;
        phases A;
        nominal_voltage 7621.01984024048;
        from transformerBank_T1_Node;
        to ugPrimaryLine_4085_Node;
        configuration line_configuration_4085;
        length 116.584609985352;
    };
    object node {
        name ugPrimaryLine_4085_Node;
        phases A;
        nominal_voltage 7621.01984024048;
    };
    object transformer_configuration {
        name transformer_config_3-000727;
        connect_type SINGLE_PHASE_CENTER_TAPPED;
        primary_voltage 7621.01984024048;
        secondary_voltage 239.999897616065;
        powerA_rating 25;
        resistance 0.00110000002384186;
        reactance 0.0220000004768372;
    };
    object transformer {
        name transformerBank_3-000727;
        phases AS;
        from ugPrimaryLine_4085_Node;
        to transformerBank_3-000727_Node;
        configuration transformer_config_3-000727;
    };
    object node {
        name transformerBank_3-000727_Node;
        phases AS;
        nominal_voltage 138.564005494118;
    };
    object triplex_line_conductor {
        name oh_line_conductor_tri_4 AL Tri 0;
        resistance 2.4516;
        geometric_mean_radius 7.0000000000000001E-3;
    };
    object triplex_line_configuration {
        name line_configuration_4005;
        conductor_1 oh_line_conductor_tri_4 AL Tri 0;
        conductor_2 oh_line_conductor_tri_4 AL Tri 0;
        conductor_N oh_line_conductor_tri_4 AL Tri 0;
    };
    object triplex_line {
        name ohPrimaryLine_4005;
        phases AS;
        nominal_voltage 138.564005494118;
        from transformerBank_3-000727_Node;
        to serviceLocation_3756_Node_Meter;
        configuration line_configuration_4005;
        length 90.0940017700195;
    };
    object triplex_meter {
        name serviceLocation_3756_Node_Meter;
        phases AS;
        nominal_voltage 138.564005494118;
    };
    object triplex_node {
        phases AS;
        name ohPrimaryLine_4005_triplex_node_Load;
        parent serviceLocation_3756_Node_Meter;
        power_1 1000 W;       //constant power load on phase 1 to neutral (139V)
        current_2 1 A;        //constant current load on phase 2 to neutral (139V)
        impedance_12 100 Ohm; //constant impedance load between phase 1 & 2 (278V)
        nominal_voltage 138.564005494118;
    }
    object multi_recorder {
        property ohPrimaryLine_4005:current_in_A;
        file "rec.tri_lines.16.csv";
        interval 60;
        limit 60;
    }
    object multi_recorder {
        property serviceLocation_3756_Node_Meter:measured_power;
        file "rec.meters.16.csv";
        interval 60;
        limit 60;
    }
    
     
  • Jason Fuller

    Jason Fuller - 2013-01-04

    Cedric,

    That one took me a little time to find, and has been hidden in there since the beginning of GridLAB-D, so way to go!!

    It turns out we don't have an error check on the diameters within the underground line conductor.  Your outer_diameter is less than the neutral_diameter, but the outer_diameter is the size of the outer shell of the entire cable (so it must be the greatest in size).  Figure 4.11 in William Kersting's book "Distribution System Analysis and Modeling, Third Edition" shows this quite well.

    As soon as I made your _outer_diameter _larger than the neutral diameter, everything worked okay.  I've also added an error check that will make it into v2.3.

    J

     
  • Cedric de La Beaujardiere

    Hi Jason,

    Thank you for catching my underground conductor size configuration bug, and for indicating the model used to represent UG cables.  I found Figure 4.11 online.  It looks like my too-small outer_diameter dimension is probably the insulation betweem the conductor and neutral strands.

    However, when I increase the outer_diameter to 1.1, it still fails to converge (I also tried 1.09, 1.2 & 1.3).  I wonder if you are using a different version of gridlabd, such that your model simulation converges but mine does not?  Or maybe your environment has gridlabd configurations different than the default.  I was using version 2.2 (32-bit not 64).  I downloaded the latest nightly 64-bit build, but it also won't converge.  I can't find a windows executable installer for 3.0, maybe I need to build one from trunk?  Building will likely present its own set of problems, as I think I tried before and had issues.

    Finally, even looking at the diagram of Figure 4.11 and the powerflow users guide, I am not clear on the meaning of the Underground Line Conductor parameters.   (I will try to post the figure 4.11 image in a subsequent post, as apparently my reply looks like spam…)

    1) If there is no external jacket/shielding, would the outer_diameter then be the distance from the center of the cable to the furthest edge of one of the neutral strands, in the Figure 4.11 equivalent to R + d_s?

    2) Is it correct that (once adjusted for units) the conductor_gmr should be less than half the conductor_diameter because the conductor is composed of several strands so it is not a smooth cylinder but a bumpy surface, and the geometric mean radius takes into account the valleys and peaks of that surface?

    3) Does neutral_gmr correspond to the radius from the center of the UG assembly to the distance of the k neutral strands spiraling about that center, approximately R in the diagram?

    4) Does neutral_diameter correspond to d_s in Fig 4.11, the diameter of a single strand of neutral?

    5) Can the neutral be at the center and the conductor around it? Our client utility's underground conductor specification file has some neutral GMRs which are smaller than the conductor GMRs, which doesn't fit with figure 4.11.  Example,  0.321 phase (conductor) gmr > 0.318 ft neutral gmr:

                     ----- Outside Diameter (in feet) -----   # Neut    -- GMR (feet) --   -- Resistance (ohms/1000ft) --  Distance to
    Description      Insul   Jacket  Neutrl  ExtJkt  Cond     Strands   Phase    Neutral       Phase         Neutral       Cn (feet)
    15kv 750 MCM UG  0.1242  0.1325  0.1633  0.0000  0.0832     25      0.0321   0.0318        0.0141        0.0400        0.0383
    15kV 1/0 CU UG   0.0708  0.0775  0.1000  0.0000  0.0311      9      0.0111   0.0318        0.1000        0.2800        0.0383
    

    Thank you again,
    Cedric

     
  • Cedric de La Beaujardiere

    Here I try to post the image of Figure 4.11:

     
  • Cedric de La Beaujardiere

    Finally, my table with neutral GMR smaller than phase/conductor GMR was too long, so here it is without the last three columns:

                     ----- Outside Diameter (in feet) -----   # Neut    -- GMR (feet) --
    Description      Insul   Jacket  Neutrl  ExtJkt  Cond     Strands   Phase    Neutral
    15kv 750 MCM UG  0.1242  0.1325  0.1633  0.0000  0.0832     25      0.0321   0.0318
    15kV 1/0 CU UG   0.0708  0.0775  0.1000  0.0000  0.0311      9      0.0111   0.0318
    
     
  • Jason Fuller

    Jason Fuller - 2013-01-10

    Cedric,

    (1) We only specifically support that style of underground cable (as you've posted above), as these and tape-shielded (also not implemented) are the two most common cable stye.  There are literally hundreds of cable configurations out there for specific applications.  Beyond that, you will either need to do some "trickery" to get it to work (i.e., fudge some of the configuration numbers to fit within the described figure) or determine the impedance values yourself and directly input them using the z11, z12, etc. variables.  This looks like:

    object line_configuration {
            z11 0.45755107+1.07803450j;
            z12 0.15595008+0.50247120j;
            z22 0.46662760+1.04816342j;
            z13 0.15348432+0.38493375j;
            z23 0.15800624+0.42364872j;
            z33 0.46147200+1.06505784j;
    }
    

    You could also use a different, but similar configuration to represent your models (see Kersting's appendix).

    (2) Correct.
    (3) Correct.
    (4) Correct.
    (5) Not specifically modeled in GLD.

    Not solving:
    Version 2.2 and 2.3 are fairly similar.  We are adding features to 2.3 (to be released this month), but solutions in powerflow should be identical. Try adding:

          /// From a standard triplex model we use
          insulation_thickness 0.08;
          diameter 0.368;
    

    to your triplex_line_configuration.  I didn't think those were required variables, but I may be wrong.  Please let me know if they are, because that may require an error check also.

     
  • Jason Fuller

    Jason Fuller - 2013-01-10

    Cedric,

    Sorry.  Also just noticed that your center tap transformer secondary voltage is double what it should be (we define the turn ratio to a single phase-to-neutral rather than across the phases):

    secondary_voltage 239.999897616065; --->  120.0

     
  • Cedric de La Beaujardiere

    Hooray! Adding appropriate insulation_thickness and (conductor) diameter to the triplex_line_configuration solved the convergence problem, and my multi_recorders are now outputting values instead of NAN.

    As long as I have either insulation_thickness or diameter or both, my simulation converges, but if don't have either, it does not converge.  It appears that, when they are not specified, the default value is 0.0.  So if I specify both values but they are 0, it also does not converge.

    Thanks for all your help,
    Cedric

     
  • Cedric de La Beaujardiere

    By the way, FYI, the powerflow user guide indicates that the object overhead_line_conductor takes a "diameter" parameter, but when I tried to use it, gridlabd 2.2 gave me an error complaining that the input is not valid.  I can not easily replicate because I have already switched to 2.3, which is not giving me this error.

     

Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:





No, thanks