Cara,

We store the region from the path cuts in the database as a single EnPower Region.  That means that we can only map California to one of R10, R11, and R12.  Are you intending the regions within Path Confirmation to represent a group of EnPower Regions?  If so, we will need to make a database change to store those groupings.  I expect that the database change would take a long time because it will involve a Global database change.

Thanks,
Will

 -----Original Message-----
From: 	Semperger, Cara  
Sent:	Monday, August 13, 2001 4:11 PM
To:	Bentley, Corry; Poston, David; Smith, Will; Venkataswami, Vishwanatha
Subject:	More on the Region Choices for Path Cut

Good Afternoon,

I do want the regions to understand Enpower Regions, but at the same time not be so specific to the user.  Here is the breakdown that I would want:

California = R10, R11, and R12

Northwest = R9
	Enpower calls it MidColumbia, but many more delivery points than Just Mid Columbia are contained within it, and I don't want to list them all in the region choice or 	confuse the useres further by them looking for something in the northwest that is not MidColumbia.

WSCC-S=R7

Rockies = R7A

WSCC-N=R8

Please also see my notes below on the existing system. I am happy to provide any further explanation you would like.

Cara


 -----Original Message-----
From: 	Smith, Will  
Sent:	Monday, August 13, 2001 1:53 PM
To:	Semperger, Cara
Subject:	RE: Testing PSW and Path confirmation

Cara,

It appears that some clarification on the Regions is necessary.  Vish has implemented the cuts to show regions as defined by the Regions table in EnPower.  This is the same table that is used in many of our reports.  Should the regions that you are speaking of be separate from EnPower's list of regions?  

Vish tells me that "California" equates to all of NP-15, SP-15, ZP-26.  Also he is unable to resolve "Northwest".    Should we not resolve your list of regions to the EnPower list?


Also, as an aside, I took a look at the West Discussion - Schedule Information in Notes and noticed that when looking at cuts the tree hierarchy was as follows

Hour Ahead / Real-Time
Region?  (e.g.  Montana, MARKETER, WSCC, NW, SW, FED Utility) This is why I want preset regions, right now they are user defined and a mess
Date
Path
Cuts

I think the best way is to have the sort selection as it is in the new system, by date primarily, and then the nifty sort tool you all have written

Is the second item in the tree related to the region selection for path cuts?  Yes

Thanks,
Will

 -----Original Message-----
From: 	Semperger, Cara  
Sent:	Monday, August 13, 2001 1:16 PM
To:	Bentley, Corry; Poston, David; Smith, Will; Venkataswami, Vishwanatha
Subject:	Testing PSW and Path confirmation

Good Afternoon,

Here are my findings for the latest Release of the PSW and Path Conf. I am re-running the date of June 22, as I see no data in the path confirmation for that date.

PreSchedule Workspace:

I tried to open the sheet "PV_JUNE22_LIMITED"  and got this error "Access violation at address 00000016. Read of address 00000016.  I could not save, close or do anything, I had to end task to get out of the sheet and the PSW.  I had run the COB sheet prior to opening the PV sheet, and had closed the COB sheet. When I re-opened the "PV_JUNE22_LIMITED"  sheet, it was completely blank.  This kind of data loss would be catastrophic in production if we were not using an outside Excel spreadsheet. 

Error checking
The workspace seemed to get stuck on one deal not being a market deal (#657854.1) that was put in the market deal number area. It is an EPMICALPOOL deal that is a buy/resale.  This error is understandable in the rows where the deal is present, but the routing error check mentioned it in rows 69-192, where the deal number was not present. Can the sheet be made to understand that a buy/resale should be tolerated in either the Supply or Market deal number cell?

I also got just "Error:" with no explanation of what the error was for rows 3-6, 9-11 and 21-28.  Rows 3-6  and 9-11, has a NW delivered upstream and Portland General System Downstream, both identified as Portland General System on the sheet. Rows 21-28 I see no errors apparent. 

My second PV sheet gave me  routing error  "Error:"  with no explanation on rows 2-45.  The only thing I see is that I have chosen R instead of X for the export.  I changed all rows to X, and still got the routing error with no explanation.  I have enclosed that sheet for your inspection. Could it be that the system already detects routes?

 << File: PV_JUNE22_LIMITED.psc >> 



Path Confirmation:

The Transmission information seems to be populating correctly, all trans looks good and has the -E- on each side. I can put my POR/POD info in the Oasis cell, and all the info looks great!
The Global ID Sorting is working just right.
The Tag Sorting is also working just right.
The expanded view is showing the entire path regardless of length.
I like the POR and POD sort capability, this will be very helpful.

In the Expanded View,  even though I know the counterparty, this view sometimes shows me a blank drop down box where the counterparty should be. Allegheney did not show a counterparty name here. This actually looks like it might be specific to Allegheney.

In the line view My counterparty on the sheet CPS shows Constellation Power Source, Inc.  but in the expanded view I see City Public Service of San Antonio. They both have CPS as their short name, but the second counterparty is an East Desk Counterparty. Corry, Can you get their short name changed to something else you like?

Path Cut:

The regions are not what I have repeatedly asked for.  I only want to see the following:  California   Northwest   WSCC-N   WSCC-S  Rockies.  If I need to provide more explanation on this, I am happy to do so. The current breakout is too detailed as well as incomplete, and will be cumbersome for real-time and settlements to use.  These regions will correlate with the same region choices in the Discussion Dbase that I am working with Poston to get done.

Closing path cut seems to take quite a long time even when no saving is done, just over a minute. Users will percieve this as something broken.

I think that Bill Williams III and the real time group here will have more to add on path cut, I will hand this off to them very soon.  



Overall Findings:

I feel that with this release we are very close to what we need for production.  We will definately have to get a handle on the data loss issue, but the functionality looks really good.  My goal is to release this and the discussion Dbase at the same time so that we are able to tell settlements that from "X" date previous the records are in lotus, and from "X" date forward they are in the new system. Those groups will have huge confusion if we overlap days in both.

Please let me know anything else that I need to do, and when I may test again.  Thanks

Cara