Opal data

Description of Opal data

The Opal data comes from the Opal-RT model while it is running.

Opal first extracts the Wesim data and re-formats it by mapping five regions to 36 nodes using a proper ratio, and picks out 7 hours of data for running the model. The entire model will run for exactly 7 minutes, i.e., one real minute represents one hour in the simulation.

General Structure

Suggest choosing a Pandas DataFrame with column names from the table below and a time index for each new row of data that comes in.

Yue's current visualisation

The code is broken up into 3 main components:

• BMStart.py is the main function for Opal-RT real-time simulation.
• UDP_Server.py is the web interface based on streamlit. They should be run through the command streamlit run UDP_Server.py.
• UDP_Client_Demo.py is used for testing the interface: it will send mock data to the UDP servers so that Opal-RT model does not need to be enabled everytime when testing the interface.
• UDP_Client_Reset.py is used to clear all data currently in the interface. When ran, the file sends out the clear command to the server so that the interface will reset all data figures.
• Other files starting with UPD_ are for offline tests.

The model is initialised and run in this section of code.

The mock data is sent from this line in UDP_Client and further down inside the loop every 0.5 seconds.

The time index Yue uses for the visualisation is set to 2035-01-22 00:00 here.

The pre-set time can be changed for each case study, and Opal can also send out a time bias index (in hours) so that the start time can be formatted as 2035-01-22 00:00+bias.

While the model is running, Opal is able to send out ‘how long’ the model has run for, but that data can also be calculated by multiplying k-th data frame.

Every 7.5s in real world, a list of data is sent to the visualisation interface through UDP communication. That process occurs inside this if statement, where you can see the data1 variable is populated by getting the data by name and then sent to the streamlit-based vis tool. This list describes the list of data (note that the data1 variable is 45 elements long with the last few elements being EV-related):

Index	Variable	Signal Name	Operation
0	k-th data frame
1	Time of the model in seconds
2	Total generation in GW	TotalGen_path	/1000
3	Total Demand in GW	TotalDemand_path	/1000
4	Total offshore generation in GW	offwind_gen_path	/1000*(-1)
5	N/A
6	N/A
6	N/A
8	Value of Trade in Intra-day Market in £
9	Procured Generation from Intra-day Market in MW	Intra_Gen_path
10	Procured Demand from Intra-day Market in MW	Intra_Demand_path	*(-1)
11	Procured Storage from Intra-day Market in MW	Intra_Storage_path	*(-1)
12	Procured Generation from Balancing Mechanism Market in MW	BM_Gen_path
13	Procured Storage from Balancing Mechanism Market in MW	BM_Storage_path	*(-1)
14	Procured Demand from Balancing Mechanism Market in MW	BM_Demand_path	*(-1)
15	Expected offshore wind generation in MW (expected)	off_wind_exp_path	*(-1)
16	Real offshore wind generation in MW	off_wind_real_path	*(-1)
17	Battery generation in GW	Bat_gen_path	/1000*(-1)
18	Interconnector power in GW	Inter_gen_path	/1000*(-1)
19	Offshore wind generation in GW	offwind_gen_path	/1000*(-1)
20	Onshore wind generation in GW	Onwind_gen_path	/1000*(-1)
21	Other generation in GW	Other_gen_path	/1000*(-1)
22	Pump generation in GW	Pump_gen_path	/1000*(-1)
23	PV generation in GW	PV_gen_path	/1000*(-1)
24	Nuclear generation in GW	NC_gen_path	/1000
25	Hydro generation in GW	HyD_gen_path	/1000
26	Gas generation in GW	Gas_gen_path	/1000
27	expected demand in GW	TotalDemand_exp_path	/1000
28	real demand patheration in GW	TotalDemand_path	/1000
29	Value of Trade in Balancing Mechanism in £	BMCost_path
30	Total accepted power from Balancing Mechanism in MW	BMAccept_path
31	Expected Gridlington Demand in MW
32	Real Gridlington Demand in MW
33:39	Gridlington house hold acctivity (Work, Study, Home Care, Personal Care, Shopping, Leisure, Sleep) in number
40	Expected EV charging power in Gridlington in MW
41	Real EV charging power in Gridlington in MW
42:44	Gridlington EV Status: Charging, Travelling, Idle in number

 

data1[5:9] were being previously used for other results that are no longer tracked. data1[8:9] have been overwritten to record the data in the above table, but data1[5:7] still record useless data.

The 'data2' variable found in BMStart.py is currently defunct and can be ignored.

Interaction with Agent model data

There are two components to this:

• Pulling from Jacek's FTP server (line 252 in BMStart.py). This will be replaced with the Datahub.
• Sending a command directly to the Agents API (line 257 in BMStart.py). This component of the interaction will not go via the Datahub.