Dev ~ How to Debug a Gridlab Model

By Nikhil Gupta at PNNL, edited by David Pinney at NRECA.

In 2014, the OMF development team was faced with a feeder where loadflow could be solved with the FBS algorithm but not with NR. Here are the steps that were taken to debug it:

Step 1: fault_check

Include a fault_check object in the .glm and run to see if there are any islanding issues.

object fault_check {
    check_mode ONCHANGE;
    output_filename youroutput.txt;
}

Step 2: --verbose flag

Run the glm with verbose: "gridlabd main.glm --verbose". This give information about blown fuses etc.

Using both the above steps, see for any odd/suspicious messages. If nothing suspicious found:

Step 3: volt_dump

Add volt_dump object to the .glm. It will generate a .csv file. Look at the nominal voltages in the output file to see if those are the expected values. Please note that if the model doesn't run (creates errors) then this file will not be created.

Step 4: gdb (for advanced users only)

Run the .glm with a debugger (Example: gdb)

In this case, step-3 helped figure out the problem. Step-4 helped to confirm there is nothing wrong with the solver_nr.cpp. Few sub-steps of how this was narrowed down:

We know that the model was never converging (from the warning messages), so when I ran the .glm with gdb, I looked at this portion of the code where it checks for a "convergence":

In solver_nr.cpp (around line 4898-4910):

CurrConvVal=DVConvCheck[0].Mag();
if (CurrConvVal > Maxmismatch)      //Update our convergence check if it is bigger
      Maxmismatch=CurrConvVal;
if (CurrConvVal > bus[indexer].max_volt_error)  //Check for convergence
      newiter=true;                       //Flag that a new iteration must occur
CurrConvVal=DVConvCheck[1].Mag();
if (CurrConvVal > Maxmismatch)      //Update our convergence check if it is bigger
      Maxmismatch=CurrConvVal;
if (CurrConvVal > bus[indexer].max_volt_error)  //Check for convergence
      newiter=true;     
//… (line 4986-4989) :
CurrConvVal=DVConvCheck[jindex].Mag();
if (CurrConvVal > bus[indexer].max_volt_error)  //Check for convergence
      newiter=true:
//So, never converges, so it’s not going to find any solution (line 5170-5173)
if (newiter == false)
{
      gl_verbose("Power flow calculation converges at Iteration %d \n",Iteration+1);
}

and once newiter reaches 100 since that’s the iteration limit set in the .glm, it errors out. If the limit is not set, glm enters the infinite (kind of) loop because it’s not converging at all.

All this is happening in between 4882-4996. But it is doing what it is supposed to do which means there is NO problem with the library.

Step 5: optional: switch to Forward Backward Sweep (reduced functionality)

The Forward Backward Sweep (FBS) solver in GridLAB-D is typically more resistant to bad data and will converge more reliably. However, many features require the Newton Raphson solver to work correctly (such as breaker/fuse opening). You can switch to FBS by specifying it in the powerflow module as follows:

module powerflow {
solver_method FBS;
};

Solution found: wrong nominal voltage.

So, follow step-3 and look at the .csv file generated by the volt_dump, you'll see around 240V in each phase A, and B (where it is supposed to be 120V for each phase).

Look at one of the nodes (example: grep for S1905-25-015 in .glm), and the nominal voltage was set to 120V, where as the secondary_voltage for the split_phase_center_tap_transformer (1806-0052transformer_configuration32701) was set to 240V. When this is changed to 120V, the model runs fine with NR solver.

Note: "triplex_load" voltages can also be seen/verified from the .xml file created by gridlabd.