Import BEA Supply and Use tables #238
Conversation
R/LoadIOTables.R
Outdated
| @@ -150,6 +153,9 @@ loadIOcodes <- function(specs) { | |||
| "GovernmentDemand"), | |||
| "Codes")], | |||
| use.names = FALSE) | |||
| if (specs$BasePriceType == "BAS") { | |||
| io_codes$FinalDemandCodes <- io_codes$FinalDemandCodes[!io_codes$FinalDemandCodes %in% io_codes$ImportCodes] | |||
| } | |||
There was a problem hiding this comment.
io_codes needs further refactoring to handle sectors in SUTs' Use table, because BEA code of 'V002 - Taxes on production and imports, less subsidies' is broken down to the following three sectors in SUTs' Use table.
- T00OTOP - Other taxes on production, which is part of VA in BAS
- T00TOP - Taxes on products and imports, which is part of VA in PRO
- T00SUB - Less: Subsidies, which is part of VA in PRO
Considering modifying schema info tables
R/IOFunctions.R
Outdated
| UseSUT_BAS <- UseSUT_PRO - sweep(ratio_m, | ||
| MARGIN = 1, | ||
| STATS = tax_less_subsidies, | ||
| FUN = "*") |
There was a problem hiding this comment.
Tax less subsidies was allocated across columns in each row of UseSUT_PRO based on consumption of each commodity (row) by industries (columns).
|
@WesIngwersen I figured that the comm/ind output validation failed because UseBAS was not correctly generated because of margins. The proposed approach used margins matrix calculated from (UsePUR - UsePRO), both in Make-Use framework, to convert UseSUT_PUR to UseSUT_PRO, but I found that total margins by commodity summed from the matrix do not equal to total margins calculated from the TRADE and TRANS columns in Supply. Knowing that the output from Supply equals to the output from Use when they are in PUR and BAS, and that the conversion from PUR to BAS used TRADE and TRANS columns in Supply, I would propose to use margins values summed from TRADE and TRANS columns in Supply, allocate them to columns based on the margins matrix calculated from (UsePUR - UsePRO), then subtract the matrix from UseSUT_PUR. This will ensure the totals are balanced and the industry-specific margins effect is preserved. |
| # Allocate margins_Supply throughout Use based on margins matrix | ||
| margins_ratio_m <- margins/rowSums(margins) | ||
| margins_ratio_m[is.na(margins_ratio_m)] <- 1/ncol(margins_ratio_m) | ||
| UseSUT_PRO <- UseSUT_PUR[rows, cols] - diag(margins_Supply) %*% as.matrix(margins_ratio_m) |
There was a problem hiding this comment.
This change closes the gap (with diff of +/- $10 Mill.) between commodity output from Supply and that from Use, both in BAS. But there still are noticeable gaps between industry output because the PUR->PRO->BAS conversion adjusted Use by columns but not rows.
I think a RAS balance is needed after the price type conversion, the target row sums will be industry output in BAS.
There was a problem hiding this comment.
Scratch what I said about RAS balance above.
In fact, industry output summed from UseSUT_BAS can never equal to output summed from Supply (BAS), because by definition, industry output (BAS) = intermediate consumption (PUR) + value added (BAS), see excerpts from the BEA tables below.
- Use
- Supply
This means we can (and should) only aim to
- Ensure commodity output (BAS) are equal between Use (BAS) and Supply (BAS)
- Calculate industry output (BAS) from Supply (BAS) instead of Use (BAS)
|
@WesIngwersen @bl-young @jvendries I made a small change in 1139aae according to my earlier comment and am able to build a USEEIOv2.0.2-411 model all the way to |
|
The two things I remember talking about was a matrix like phi or rho to be able to convert from Basic to Producer price. And also a wrapper function of some kind to produce just the economic portions of the model to avoid failures. We may also want to confirm that BAS models can be written to excel |
# Conflicts: # .github/workflows/save-BEA-data.yaml # DESCRIPTION # data-raw/BEAData.R
|
I am finding that we can not build a complete economic model in BAS as there are errors in generating the L matrix. |
I also tried building the BAS model and was unable to due to an error when calculating the L matrix. After further inspection, I was able to trace back the error to the As a reference, the attached image displays the values for several rows in the 4200ID/US column in the Given the above, do we want to proceed with the merge, or should we hold off until we have a better grasp of why these values are been introduced in this column? |
Tau: A dataframe of basic to producer price ratio