Update sampling procedure

[WesIngwersen]

Current text is

BOUNDARY CONDITIONS
All processes are compiled by US region using boundaries based on electricity trading defined as 'subregions' in the Emissions and Generation Resource Integrated Database (eGRID). Generation processes are also aggregated by fuel or energy source and provide the flow of electricity after it has been transformed for transmission on average US high voltage transmission lines (230 - 765 kV ). Mix processes are mixes of generation by fuel type representing the average mix of electricity available on the grid within the region either based on production or consumption. Delivery to the final user is targeted toward an average end user without separation between different user types. The time span for all processes is one year, with the goal to represent the current (2018) year. DATA COLLECTION
All inventories were calculated using secondary data from publicly available datasets. UNCERTAINTY ESTIMATION
Flow-level data quality scores are assigned to each elementary flow exchange and process-level scores to each process using the USEPA LCA Data Quality Assessment guidance . In the generation processes, for each emission factor, five data quality scores were assigned on flow-level data quality scoring. Process data quality scores draw on the process US EPA DQ indicator guidance. Process completeness is calculated by first creating a list of expected flows for each fuel type. U.S. average profiles for the fuels used in electricity generation are developed for expected flows in the following categories: greenhouse gases (GHG), CAPs, toxic and hazardous air pollutants (HAP), toxic water discharges, toxic soil releases, and hazardous waste. To determine the expected flows in each category the number of flows reported in the underlying data sources NEI, TRI, eGRID, RCRAInfo are summed across eGRID subregions by fuel type. Expected flows by fuel type for other inputs and outputs including intermediate inputs, raw energy demands, and water inputs are determined based on flows reported for the relevant electricity generation fuel type in existing LCI datasets such as ANL's GREET model, NREL's USLCI, and ecoinvent. Expected nutrient discharges to water are derived from a sample of electric facilities reporting to USEPA's Discharge Monitoring Report (DMR). The actual flows evaluated for each fuel type by eGRID subregion can then be documented and compared to the U.S. average electrical fuel generation profiles to determine the overall process completeness according to the method described in USEPA LCA Data Quality Assessment guidance. Air emission flow data collection scores can also draw on these fuel-specific profiles by documenting whether an expected flow is being reported by the fuel type in the relevant eGRID subregion. An expected emission may not be captured if there are discrepancies between the facilities covered in eGRID and those reporting to the USEPA databases TRI, NEI, RCRAInfo. 

[WesIngwersen]

Boundaries should be described as BA's and not egrid subregions for model 1

[WesIngwersen]

Manual coded the BAA's as the region into process_metadata but this is only a temporary fix for model 1.

[WesIngwersen]

Reopening because eGRID region language still present in sampling procedure

[m-jamieson]

I'm seeing

The regions are defined as Balancing Authority Areas.

in the sampling procedure for the technology processes, generation mixes, consumption mixes, and distribution processes. Was this re-opened because you weren't seeing that in the openLCA processes are because we want it to be different depending on the selected region aggregation?

I would propose updating the language to be more generic as the easiest solution:

The regions are defined as specified by the user: Balancing Authority Areas, Federal Energy Regulatory Commission (FERC), eGRID subregions...

If we wanted to make it dynamic, I would suggest adding a place holder into the metadata and then replace it when generating the process documentation - replace \<RegionPlaceHolder> with whatever was chosen.

[WesIngwersen]

Yes that could be a good solution that we can use there an in a couple other places in the docs

[WesIngwersen]

I reviewed text, closing this issue