Rahil's Notebook.

Entry 1 - 9/21/2023

Today, I mainly spent in understanding the GridLAB-D model

Understanding the GridLAB-D model:

1. GridLab-D has its own clock. Each of its simulation steps is time-synchronized. Flow, Residential, etc...
2. There are 3 main things in GridLabD - Clock, modules, and objects.

1. Each line in GridLab-D has different objects. This has information like: If they are underground, or overground. It takes care of the physics as well.
2. This is why it is written in an object-oriented programming language (C++). All of these objects work together in a co-simulation while being time-synchronized as well.
3. Objects provide tremendous modularity as well. It makes the code to easy to edit, as well as deal with.

1. You can have Direct objects, and you can have supporting objects
   • Examples of Direct objects: A load, a node, an overhead line, etc...
   • Examples of supporting objects: A line configuration.
2. Supporting objects complete the definition of other objects.
   • Example: We need a line configuration object in order to complete a line. If we don't use a line spacing object as a supporting object, we might run into several errors.

1. Child objects cannot exist without a parent object.

Citation: YouTube. (2017). YouTube. Retrieved October 4, 2023, from https://www.youtube.com/watch?v=_B0q_Fj0A_E

Entry 2 - 9/28/2023

While using the cps-cosimulation-env README file, I found it important to understand the workings of the NIX package manager, since we use it. Hence, here is the research that I did:

Benefits of using NIX as a package manager:

1. In a normal package manager, the files are in the package, which is installed on the local system. Whenever the package manager is updated, the old files or packages are overwritten by the upgraded files or packages. This is what makes nix different. In nix, the packages are not installed on the local machine. Instead, there are files that contain memory address locations to the actual files on the laptop, called a symlink file. So, whenever NIX is upgraded, the new memory locations of the packages are changed on the symlink file. This way, the old packages don't get corrupted if there is a problem with the upgrade.

1. The configuration file ends with ".nix", and it is present in the NixOS. It is written in a functional languages. What packages are installed, what Desktop, Applications, and Services are running, etc...
2. This config file is used to set up your system and dictates how you want to use it, and the several changes that you make afterwards.
3. With the help of this file, you can set up your system just as you want it.
4. If 2 machines have the same configuration file, this means that there are identical packages on the machines.

Citation: YouTube. (2020). YouTube. Retrieved October 4, 2023, from https://www.youtube.com/watch?v=oPymb2-IXbg.

Understanding the flake.nix file before running "nix develop" on my system.

description = "HELICS";

inputs = {
  nixpkgs.url = "github:nixos/nixpkgs";
  flake-utils.url = "github:numtide/flake-utils";
};

outputs = { self, nixpkgs, flake-utils }:
  flake-utils.lib.eachSystem [
     "aarch64-linux"
     "aarch64-darwin"
     "x86_64-darwin"
     "x86_64-linux" ]
  (system:
   let
     pkgs = import nixpkgs {
       inherit system;
     };

     packageName = "vip-cosim";

  in {
    devShells.default = pkgs.mkShell {
       LD_LIBRARY_PATH = "${pkgs.stdenv.cc.cc.lib}/lib:${pkgs.zlib.outPath}/lib";
       shellHook = ''
         source $(realpath ./.)/nix-shell-setup.bash
       '';
       buildInputs = with pkgs; [
         # C/C++ build utils
         gnumake
         (cmake.override {
           uiToolkits = [ "ncurses" ];
         })
         extra-cmake-modules
         
         boost
         czmq
         ncurses

         poetry
         python310
        ];
       };
      }
    );
}

1. This is a nix flake config file.
2. The package description is the package used, which is: "HELICS".
3. The "inputs" are the external dependencies that the file relies on. Which, in this case, are the 2 urls: "nixpkgs.url" and "flake-utils.url". These point to the Nixpkgs repository on the Git, and the Flake-utils repository respectively.
4. The "outputs" are "self", "nixpkgs", and "flake-utils".
5. There are a bunch of target systems as well: "aarch64-linux", "aarch64-darwin", "x86_64-darwin", and "x86_64-linux". these are macos versions that can be used.
6. That package that is being imported by the system is: "vip-cosim".

All in all, this Nix flake configuration is designed to build the HELICS package for multiple target systems using NIX package manager. The inputs section specifies external dependencies, and the outputs section defines how to build HELICS for different systems, setting up the development environment and necessary dependencies for each.

This research helps me comprehend what exactly I am installing on my local machine.

I got the following message after running the "nix develop" command:

This was the nix garbage collector that was inbuilt:

Entry 3 - 10/09/2023

I attended office hours today to help debug the following problem I was facing:

1. Trying to run "./run_example.sh" in the directory, the code was stopping at the following point:

2. After suspending the process with "control + Z", and checking the foreground with "fg", I realized that I was getting a segmentation fault due to the file, "IEEE_123_feeder_0.glm". As you can see below:

3. I attempted to rebuild gridlab-d and rerun these commands. All objects built and installed by gridlab-d were going to the correct place. However, we realized that I was facing this issue because of an error in running gridlab-d on M1 & M2 Macbooks.

4. I have submitted an issue on GitHub regarding this problem:

Entry 4 - 10/12/2023

We structured the paper and assigned different roles to different members of our team. We tried to use lldb in order resolve the bug faced on 10/09/2023.

Entry 5 - 10/19/2023

Today essentially went into delegating parts of the paper to the team members. After delegation, we came up with the following sections:

1. Executive Summary - Isabella

2. Introduction - Rahil

3. Background Research:

• Case Studies - Hussein
• HELICS rundown - Raj
• Working of the line inspection robot - Suraj

4. Research Sections -

• ROS & HELICS simulation integration with Gazebo - Safiy
• Sensing Team -
  • Sensors on the robot and interaction - Suraj
  • Pros of using renewable energy on the robot - Raj
  • Testing the model on lines with different voltages and simulating damage on the
    robot - Rahil
• Future Solutions to challenges in our MVP and physical environment - Hussein

5. Conclusion -

• Roadmap - Rahil

6. References -

• Everyone includes 2 citations down here. Make sure that one citation is an academic article.

In order to delegate these roles accurately, we took a vote as to who would want to do what in the paper.

Entry 6 - 10/24/2023

We have assigned research topics to every single group member. Specifically, we have divided people in our group into the following sections:

1. HELICS - Safiy
2. GridLab-D - Rahil, and Raj
3. ROS - Suraj and Isabella
4. Installing VnC on the server - Hussein

In the group meeting today, everyone researched and presented a detailed description of the topics above.

In my research specifically, I have included the following information about GridLab-D:

GridLAB-D can be thought of as a core simulator with a collection of modules that contain model implementations for various entities that are relevant for distribution system simulations. Said differently, the GridLAB-D core is responsible for managing the flow of the time and interactions between a number of objects that have been assembled to simulate the effects of a distribution system as a whole. Because of the modular nature of GridLAB-D, there are a few terms that should be clarified as they will frequently come up during discussion of the design and use of GridLAB-D.

• “Model”- An engineering or mathematical term (rather than programming). There are two somewhat related ways in which this term is used in the GridLAB-d world,

1. A general term to describe how a particular part of GridLAB-D functions or is represented in code. For example, "How does GridLAB-D model solar panels?"
2. A "model file" (commonly ending in ".glm") containing the description of the distribution system being studied. This file contains the specific statement used to model a distribution system as a whole. For example, "Where is the model you used for that assignment?"

• "Class" - A C++ programing term with a similar usage as "model". Much of GridLAB-D is written in C++ and sometimes GridLAB-D developers and programmers will use this term somewhat interchangeably with "model", particularly after a long day of programming and trouble-shooting. To be specific, a "class" is the collection of code that contains the equations, parameter declarations, and algorithms that define how a particular entity will behave in GridLAB-D.

For example, in GridLAB-D there are classes that define the operation of capacitors, air-conditioners, voltage regulators, houses, and solar panels, among others. In the air-conditioner class, there is code that defines, for example, how much current air-conditioners draw when operating, and how much cold air they put out; these types of definitions are essential to create some kind of model of an air-conditioner that interacts with the grid and buildings realistically. Also note that in a class, these kinds of model/class parameters are generic and have no specific values associated with them (though default values may be defined). The code in the class definition describes how the current from the grid relates to the amount of cold air produced but does not necessarily define any specific amount of current drawn for all air-conditioners ever created in GridLAB-D. The specific current draw will get defined when all the class parameters are given specific values as a part of a specific instance of the air-conditioner class being created in a model file (".glm").

• "Object" - Another C++ programming term used in a very similar way to that language. In C++, an object is a specific instance of a class. That is, an object is one particular, air-conditioner, house, or solar panel that may operate slightly differently than another one next door or down the street. The inner workings of all air-conditioners are defined by the air-conditioner class but their size, efficiency, and location can be different from one particular air-conditioner to another. All air-conditioners function in the same way as defined by code for their class (e.g. turning electrical energy into cold air) but the specific values assigned to the parameters for each object will produce unique operational patterns.
• “Module” - A collection of related classes typically defined in the same source code file. Modules will often need to be explicitly included in a model file to give GridLAB-D access to their functionality. When looking at a GridLAB-D model file (“.glm”), almost all the text in the file is devoted to defining objects. All of these objects are specific instances of classes (models) and their parameter definitions and relationships between each other constitute the system as a whole that is being modeled.

GridLab-D structure –

1. Model - .glm files – Contains the description of how a particular part of GridLAB-D functions is represented in code. Description of the system that is being studied.
2. Class – Collection of code that has equations, declarations, algorithms that define how an entity will behave. (Air conditioners, Voltage regulators, houses, solar panels.
3. Object – Under the class. It is an instance of the class. Can have wires, nodes. How does one object differ from the other object? 2 wires can have diff lengths, how does one voltage transformer differ from the other?
4. Module – Collection of related classes defined in the same source code file. They have to be explicitly mentioned in the Model file for GridLab-D to use them.

Multi-Domain –

• Has information that is out of the electrical system as well.
• An air-conditioner runs, and for how long it runs.

Discrete Time –

• It doesn’t simulate a continuous flow of time as seen in other simulators. The time steps are small enough and close enough to model it like continuous time.
• Jumps from one step of time to the other, asking the components to model the values depending upon how much time has passed since the previous time gap.
• Objects interact with each other. Output of one can be the input of the other. Therefore, GridLab-D can reupdate the values depending on this as well.
• This repeats until the objects have reached a new steady state.
• Also attached to the house is an object called a recorder (lines 34-38). This object is one of the primary means of collecting data from a simulation and it is one of those special objects which regularly tells the GridLAB-D core when it next needs to be updated. One of the parameters of the recorder is its interval which is the number of seconds between data collection times. The recorder interval is currently 3600 seconds, indicating it will log a value once an hour. Running this simulation with the profiler turned on
• Note the difference in total simulation time; it should be significant. By asking the recorder to collect data every 6 seconds instead of every 3600 seconds, we have forced GridLAB-D to update all the objects much more often which requires significantly more calculation. Comparing the entries in the lower table individually, you can see that when we updated every 3600 seconds, the vast majority of the simulation time was spent in the climate class, updating the weather being experienced by the house. When we move the time step down to 6 seconds, now the calculations of the house are largest, followed closely by the power flow of the meter attached to the house.
• This example should make it clear that when we change the interval on the recorder, we are not simply changing which results are written out to a file, as if the results were calculated at a very fine time step and sampled as needed by the recorder. By changing the interval on the recorder, we are changing how often the simulation stops to recalculate the state of the system. For many simulations, the effective timestep of the simulation ends up being defined by the recorder, due to its special status in driving the simulation forward.

GridLAB-D was originally designed as a distribution system simulator and deals most directly with the electrical system from the substation on down (green and blue boxes). As you'll see in coming chapters, this entails building systems that include both the electrical distribution system wiring (green) but also representations of the the end-user loads (blue). By including both in the system, it is possible to cleanly capture their effects on each other. This can be very powerful as it allows us to explore interactions that may not be initially obvious at first. For example, what happens to the distribution system line losses if everybody in the neighborhood lowers their thermostat one degree in the summer? As we'll see, GridLAB-D can answer that.

Research code –

There are objects that define a substation node, a substation transformer, a substation meter, an overhead line, a meter for a load, and the load itself; the figure below provides a graphical representation of the model.

Description of the diagram above:

1. Nodes and Meters: • The electrical distribution network is represented using nodes and lines. • Nodes are connection points between lines and provide essential electrical information such as voltage, current, and power. • Nodes can have parameters like name, bustype, phases, and nominal voltage. These parameters define the node's characteristics and behavior in the network.

2. Lines: • Lines connect nodes and serve as the paths for electrical energy to flow. • Parameters of lines, such as the objects they connect, their length, and configuration, have a significant impact on the network's behavior.

3. Recorders: • Recorders are used to capture data from GridLAB-D simulations at regular time intervals. • They are attached to objects and record specific parameters, which are then saved in CSV files for analysis. • Recorder parameters include a name, the file for storing data, recording interval (in seconds), and a list of parameters to record.

4. Supporting Objects and Relationships: • Several supporting objects like line_configuration, line_spacing, transformer_configuration, and recorder are introduced. • These objects either complete the definition of other objects or provide additional functionality. • Relationships between objects can be defined as 'From/To' for transformers and lines, or 'Parent/Child' where one object is linked to another for necessary parameter access. • Configuration and spacing objects must be defined separately.

5. Results from Simulation: • The text discusses running a GridLAB-D simulation and examining the results captured by recorders. • Simulation results are stored in CSV files, and the data includes timestamps, complex voltages, currents, and powers recorded by the meters. • It notes that losses in the overhead distribution line contribute to a change in power between the substation and the load.

6. Distribution System Alternative Form: • The text also explores alternative representations of the distribution system that do not affect the simulation results. • It mentions that spaces in object names and parameters can be supported by enclosing them in quotes. • The structure of recorder objects can be altered to make them explicit or implicit children of meters. • Parameters and units in the model can be changed without affecting the simulation results.

Issue - I am still facing the exact same issue I was facing during Entry 3: GridLab-D is unable to run on M1 & M2 Macbooks. Whenever I try to run the simple_gridlabd_example on my macbook, I receive a segmentation fault. We have attempted to find the reason of this segmentation fault by using lldb to debug the original source code of GridLab-D. However, this has not worked.

Entry 7 - 10/26/2023

Today is another Group Meeting with the Instructors. We have gone over the issue spoken about in Entry 6, however, even after checking stack overflow for other people who have faced this same issue, we have not been able to come up with a solution.

Hence, something that we have thought about is to use a common cloud server on Google Cloud to be able to run ROS, and GridLab-D together as a group. Hence, we created a GCP instance to do this. We git cloned the necessary repositories from the Class GitHub on the GCP instance, as well as installed ROS2 on the same.

Entry 8 - 10/26/2023

Towards the end of our group meeting in Entry 7, Will told us about a computer at his lab we can "ssh" to run ROS2 as well as GridLab-D. Today, in our subgroup meeting, we discussed the prospects of getting this account as well as what we can run on ROS2 once we get this access.

We discussed the prospect about redividing our group to get more background research done. We divided our group into the following sub groups:

1. Team for ROS' integration with HELICS.
2. Team for Gridlab-D's communication with HELICS.

We believed that if we specialise in these specific tasks, we can achieve more progress in the direction of getting a virtual bot running on the server.

Moreover, we discussed the prospect of requesting the instructors for a repository for our group on the class discord.

Entry 9 - 10/31/2023

We have successfully gotten the repository for our sub team. We are still attempting get gridlab-d to run as well as access the same VM on the cloud.

We spoke about the different sensors we can have on the Bot today.

Entry 10 - 11/07/2023

Today, we discovered a website that lets you understand the basics of ROS with an online User Interactive interface. We told everyone from the team today to go through this website, and learn the workings of ROS before the next meeting.

Entry 11 - 11/14/2023

We were informed that the issue of GridLab-D not running on a Macbook as been solved today. So we focused on running GridLab-D and exploring different .glm fiiles today.