standardize: Standardize
In SWS-Methodology/faoswsAupus: Package to perform the AUPUS calculation.

Description Usage Arguments Details Value

This function standardizes the SUA level commodities using the logic implemented by Marteen Van't Reet in "Flexible Aggregation of FAO's Supply Utilization Accounts."

standardize(aupusData, fbsElements = c(51, 61, 91, 101, 111, 121, 141, 151,
  71), calorieElements = c(261, 271, 281), productionElement = 51, fbsTree,
  suaTree)

standardize(aupusData, fbsElements = c(51, 61, 91, 101, 111, 121, 141, 151,
  71), calorieElements = c(261, 271, 281), productionElement = 51, fbsTree,
  suaTree)

`aupusData`	A list of two data.table objects, the names of which should be "nodes" and "edges". This object thus contains the AUPUS data. This object is usually the output from the Aupus function.
`fbsElements`	The element codes for nodes that should be standardized. These correspond to the different "elements" of the FBS, such as production, imports, exports, etc. Usually the default value will not need to be modified (it has production (51), imports (61), exports (91), feed (101), seed (111), waste (121), food (141), industrial uses (151), and to stocks (71)).
`calorieElements`	The numeric codes for the elements which should be standardized via simple addition (i.e. calories, proteins, fats)
`productionElement`	The numeric code for production. This code should be specified separately as it is not standardized.
`fbsTree`	The commodity tree which specifies how a commodityID (the commodity code) aggregates to the FBS aggregates (fbsID4 < fbsID3 < fbsID2 < fbsID1). Additionally, conversionFactor is a column which specifies how items are rolled up, and is almost always 1. Generally loaded from a file.
`suaTree`	The tree specifying how commodities should be standardized in the SUA. Required columns are childID, parentID (both commodity codes), extractionRate, target (a flag indicating forward or backward standardization, or none) and calorieExtractionRate. Generally loaded from a file.
`aupusData`	A list of two data.table objects, the names of which should be "nodes" and "edges". This object thus contains the AUPUS data. This object is usually the output from the Aupus function.
`fbsElements`	The element codes for nodes that should be standardized. These correspond to the different "elements" of the FBS, such as production, imports, exports, etc. Usually the default value will not need to be modified (it has production (51), imports (61), exports (91), feed (101), seed (111), waste (121), food (141), industrial uses (151), and to stocks (71)).
`calorieElements`	The numeric codes for the elements which should be standardized via simple addition (i.e. calories, proteins, fats)
`productionElement`	The numeric code for production. This code should be specified separately as it is not standardized.
`fbsTree`	The commodity tree which specifies how a commodityID (the commodity code) aggregates to the FBS aggregates (fbsID4 < fbsID3 < fbsID2 < fbsID1). Additionally, conversionFactor is a column which specifies how items are rolled up, and is almost always 1. Generally loaded from a file.
`suaTree`	The tree specifying how commodities should be standardized in the SUA. Required columns are childID, parentID (both commodity codes), extractionRate, target (a flag indicating forward or backward standardization, or none) and calorieExtractionRate. Generally loaded from a file.

Below are some comments of interest about standardization. These decisions may seem arbitrary, but they were made to cause agreement between the numbers produced from the R standardization and the existing FAOSTAT numbers.

Forward Standardization: For a few of the commodities (in particular sugar), standardization proceeds forward: even though raw sugar beet sugar (159) is processed into sugar (162), we standardize to sugar. This creates some complexity in the code. Moreover, it seems strange that sugar beets (157) which are a parent of raw beet sugar (159) do not get standardized to sugar (162) but instead remain in their own group in standardization.
Production: Production does not get standardized, as production of (for example) flour (16) is computed based on the amount of wheat (15) allocated to processing. This leads to some complexity in the code as well, in particular when also accounting for forward standardization. The code simply leaves the production element fixed for each commodity, and then reports production for all elements. However, only elements of interest will be included in the FAO roll-ups, and so this approach should be valid.
Country specific extraction rates can overwrite the default extraction rates, and the default standardization shares are used only when no availability exists for any of the parents. Note that if no parents have any availability, and if exports exceed imports, we will have negative utilization.

Forward Standardization: For a few of the commodities (in particular sugar), standardization proceeds forward: even though raw sugar beet sugar (159) is processed into sugar (162), we standardize to sugar. This creates some complexity in the code. Moreover, it seems strange that sugar beets (157) which are a parent of raw beet sugar (159) do not get standardized to sugar (162) but instead remain in their own group in standardization.
Production: Production does not get standardized, as production of (for example) flour (16) is computed based on the amount of wheat (15) allocated to processing. This leads to some complexity in the code as well, in particular when also accounting for forward standardization. The code simply leaves the production element fixed for each commodity, and then reports production for all elements. However, only elements of interest will be included in the FAO roll-ups, and so this approach should be valid.
Autocuts: Some children do not get standardized to their parents (such as beer products). These commodities should be specified in an autocuts file, but examination of this file and the data showed that it was missing many autocuts. Thus, instead we force an autocut whenever a commodity is listed as an FBS aggregate. For example, Oil of sunflower seed (268) is a child of sunflower seed (267) and is not specified in the autocuts file. Thus, we would assume that oil of sunflower seed should be standardized to sunflower seed. However, this leads to wrong numbers, particularly as oil of sunflower seed should be included in the oil aggregation (contained under FBS commodity code 2573). Thus, any commodity code appearing as a component of the FBS commodity code was forced to be autocut.
Some edges of annex 6 (the default extraction rates used to construct the trees, provided by Marteen van't Reet) go from a commodity to it's grandchild. The problem with such a conversion is that if country specific extraction rates become available, we miss the new information. For example, suppose we have a 75 to bread. We could then write a default conversion rate of bread to wheat of 1/(.75*.75) = 1.7778. But, we may obtain country specific information that states the extraction from wheat to flour is 50 from bread to wheat should be much different. But, the default conversion won't be updated to reflect this unless we change the two-level conversion into the individual one level conversions. This was done manually, but in such a way that the product of the parent-child and child-grandchild extraction rates will give the same parent-grandchild extraction rate as originally provided.
900 (Dry Whey) is a child of 903 (Whey, Fresh) and vice-versa. One must be removed, so we'll remove the edge from 900 to 903 (to agree with documented commodity trees).
Weights of zero in the commodity tree were implemented via infinite extraction rates.
Country specific extraction rates can overwrite the default extraction rates, and the default standardization shares are used only when no production exists for any of the parents. If production does exist, then the standardization shares are proportioned according to the proportions of production of the parent.

A list of two elements: suaOutput and fbsOutput. The first, suaOutput, is a data.table with the SUA data standardized back to the primary commodity. The second, fbsOutput, is a list of four data.tables, each of the same format as suaOutput. The first element of this list is suaOutput standardized to the first FBS level, the second element is the second FBS level, etc. Higher FBS levels simply group more commodities together.

SWS-Methodology/faoswsAupus documentation built on May 9, 2019, 11:45 a.m.