Electronic Data Exchange with PRT
This page describes various methods for electronic data exchange with PRT for the services to which you subscribe.
Transfer Methods
SFTP
You can exchange data with PRT servers via SFTP protocol. You will be provided with a single username and password for your SFTP account. The SFTP URL is: ftp.prt-inc.com. Your SFTP account will directly point to the folder that is set up for your account. The listing of the folder is disabled, so you will not be able to view the list of the files in the directory. The specific names of the files you need to upload or download will be provided to you. Any SFTP client at your end can be used, and the exchange through commands such as PUT and GET can be automated. Outgoing TCP port 22 needs to be opened in your network firewall.
API
The API method for data exchange uses a standard HTTPS endpoint described by Swagger specification. The Swagger page can be used for experimentation with the API. The cURL command-line tool is suitable for easy integration and automation. You can try the following snippets using the demo credentials to test the API. Once you subscribe, you'll receive credentials to your private realm.
Upload of actuals and download of private forecast
The current working directory needs to contain the file Actual.csv for this snippet to work. All the validators are executed, but since this is a public demo account, no data are stored or used for inference. Please make sure to replace the credentials with your own.
curl --fail -F login=demo -F password=demo -F node=private -F file=@Actual.csv http://prt-api.com/api
The forecast will be printed out to the standard output. You can use the output redirection operator > or save the file directly to the file via --output option of curl.
Download of public market forecast
curl --fail -F login=demo -F password=demo -F node=demo http://prt-api.com/api/zip --output forecast.zip
This snippet downloads a set of public market forecasts which are zipped. These forecasts will be saved to your working directory under the forecast.zip file (see --output parameter)
Download of coincidental peak alerts
curl --fail -F login=demo -F password=demo -F node=demo http://prt-api.com/api/coincidental-peak-alerts
Download from Web Postings
The forecasts you subscribe to are available on the web. There are two types of web postings. The first type uses PRT's legacy websites. You will be provided with the URL(s) of the pages for the forecasts to which you subscribe. The data is posted on these pages in chart and tabular forms and are also made available as CSV formatted files via clickable links on the page. The second type of web posting is via an interactive web portal. There are clickable icons on this site for the download of the desired data in CSV format.
Excel Interface
Depending on the service you subscribe to, you may be provided with an Excel interface that includes a number of features, including download and viewing of the forecasts and sheets for input and upload of data needed from the user.
Available File Formats
The downloadable files made available on the web are in CSV format. The CSV format is also used for the files exchanged via SFTP or API. However, we can provide and work with other formats such as XML and ASCII text on a case-by-case basis.
Actual Load Data Workflow
The e-LoadForecast users need to upload their actual load data on an ongoing basis. This data should be in a CSV file with a specific name of Actual.csv. This name should stay the same for each upload. Users with several load regions will be assigned a folder for each load region and be given the names of these folders. Separate Actual.csv files should be created for each load region and uploaded to the corresponding load region folder.
The highest load forecast accuracy can be achieved if the models are provided with the latest available actual load on an ongoing basis. Therefore, if possible, it is best if the actual load can be uploaded every hour with the load of the immediately preceding hour included. However, if this is not possible, the actual load data can be uploaded with whatever frequency possible.
The arrangement of data in the Actual.csv file should be on a day-by-day basis, with each day placed in a single column. Each column of data starts with the load of HE 1 (Hour Ending 1) and ends with HE 24. Note that HE * data is the average of sub-hourly loads of the previous hour. For instance, HE 1 data is the average of loads from midnight to right before 1 am. There should not be any gaps in the days placed in this file, and the columns should be for consecutive days. Also, there should not be any missing data for any of the 24 hourly values except for the last column. In most cases, the last column is for the data of the current day, which will be partially available from HE 1 up to the most recent hour for which you have actuals. Note that in this case, the unavailable data for the remaining hour of the current day should be left blank and not filled with any values or symbols such as -999 or *.
The date of the first column of data should be for a day that is at most immediately after the last day for which the actual data for all 24 hours of that day had been already uploaded. For instance, if the last day of the complete 24 hourly loads previously uploaded is February 1, the first column of the Actual.csv file should at most be February 2 and not any other date after that. Note that the starting date can be February 1 or any different date before February 1; i.e., the starting date can have overlap with the previously uploaded dates. The preferred arrangement for the Actual.csv file is to have two columns of data starting with yesterday's data as the first column and the current day as the second column. An example of this file, assuming it is being uploaded after 7 am on 9/27/2012, is shown below. This is the format including words and date formats that should be followed for the Actual.csv file.
Hour , 09/26/12 , 09/27/12
01 , 953 , 928
02 , 948 , 917
03 , 953 , 925
04 , 1024 , 991
05 , 1120 , 1090
06 , 1226 , 1172
07 , 1258 , 1198
08 , 1294 ,
09 , 1327 ,
10 , 1335 ,
11 , 1350 ,
12 , 1352 ,
13 , 1318 ,
14 , 1283 ,
15 , 1237 ,
16 , 1210 ,
17 , 1183 ,
18 , 1212 ,
19 , 1252 ,
20 , 1221 ,
21 , 1146 ,
22 , 1059 ,
23 , 1002 ,
24 , 965 ,
The first row contains column headings. The first column should have the word Hour and the following columns after the days in chronological order. The format for the date is MM/DD/YY. However, - can be used in place of /, and the year can be specified as YYYY if desired.
The hour of the day is placed in the first column in two-digit integer format, starting with 01 in row 2 and ending with 24 in row 25. The load data for each hour of the corresponding date is placed in rows 2 to 24 of each column in integer format. The data fields in each row are separated by commas. The spaces shown in the above example are for illustration purposes, and there is no need for any specific number of spaces before or after a comma.
Note that in case of a missing data value for an hour, the models only process the data up to that hour and do not append the data beyond the gap to the actual load file in our database. The same applies to a missing date in this file.
The data in Actual.csv should always be for 24-hour days. Load regions in areas subject to Daylight Savings/Standard time switchover should provide 24 load values for both switchovers Sundays in the fall and spring. For the 23-hour Sunday in the spring, the HE 1 value can be used in place of the missing 2 am hour. For the 25-hour Sunday in the fall, the average of the two 2 am loads can be used for HE 2, or one of the two 2 am values can be ignored, and only one of them be used for HE 2 load.
The upload of the Actual.csv file can be done using API or e-LoadForecast website.