From 9b0967b6f3240a9b18ddb31bc651db0627a5c5a6 Mon Sep 17 00:00:00 2001 From: cjyetman Date: Fri, 13 Dec 2024 09:05:57 +0000 Subject: [PATCH] =?UTF-8?q?Remove=20preview=20for=20PR=20358=20?= =?UTF-8?q?=F0=9F=9B=AC?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit --- pr-preview/pr-358/404.html | 135 - pr-preview/pr-358/LICENSE-text.html | 104 - pr-preview/pr-358/LICENSE.html | 108 - .../articles/company_alignment_metric.html | 535 - pr-preview/pr-358/articles/config_yml.html | 695 - .../articles/cookbook_advanced_use_cases.html | 557 - .../articles/cookbook_interpretation.html | 1260 -- .../pr-358/articles/cookbook_overview.html | 244 - .../articles/cookbook_preparatory_steps.html | 706 - .../cookbook_running_the_analysis.html | 592 - .../pr-358/articles/data_dictionary.html | 9435 -------------- .../core-js-2.5.3/LICENSE | 19 - .../core-js-2.5.3/package.json | 79 - .../core-js-2.5.3/shim.min.js | 10 - .../htmlwidgets-1.6.4/htmlwidgets.js | 901 -- .../react-18.2.0/AUTHORS | 696 - .../react-18.2.0/LICENSE.txt | 21 - .../react-18.2.0/react-dom.min.js | 267 - .../react-18.2.0/react.min.js | 31 - .../reactable-0.4.4/reactable.css | 2 - .../reactable-0.4.4/reactable.js | 2 - .../reactable-0.4.4/reactable.js.map | 1 - .../reactable-0.4.4/reactable.server.js | 3 - .../reactable.server.js.LICENSE.txt | 52 - .../reactable-0.4.4/reactable.server.js.map | 1 - .../reactable-0.4.4/reactable.yaml | 5 - .../reactable-binding-0.4.4/reactable.js | 2 - .../reactwidget-2.0.0/react-tools.js | 1 - pr-preview/pr-358/articles/index.html | 135 - .../loanbook_aggregated_alignment_metric.html | 255 - pr-preview/pr-358/articles/sector_split.html | 307 - pr-preview/pr-358/authors.html | 140 - .../pr-358/deps/Overpass-0.4.9/font.css | 45 - ...CmI96Ajtm83upeyoaX6QPnlo6_PPbM5qKhcc.woff2 | Bin 6804 -> 0 bytes ...CmI96Ajtm83upeyoaX6QPnlo6_PPbMJqKhcc.woff2 | Bin 19868 -> 0 bytes ...CmI96Ajtm83upeyoaX6QPnlo6_PPbMZqKhcc.woff2 | Bin 4216 -> 0 bytes ...CmI96Ajtm83upeyoaX6QPnlo6_PPbOpqKhcc.woff2 | Bin 10872 -> 0 bytes ...35WCmI96Ajtm83upeyoaX6QPnlo6_PPbPpqK.woff2 | Bin 16976 -> 0 bytes .../bootstrap-5.3.1/bootstrap.bundle.min.js | 7 - .../bootstrap.bundle.min.js.map | 1 - .../deps/bootstrap-5.3.1/bootstrap.min.css | 5 - .../bootstrap-toc-1.0.1/bootstrap-toc.min.js | 5 - .../deps/clipboard.js-2.0.11/clipboard.min.js | 7 - pr-preview/pr-358/deps/data-deps.txt | 14 - .../deps/font-awesome-6.5.2/css/all.css | 8028 ------------ .../deps/font-awesome-6.5.2/css/all.min.css | 9 - .../deps/font-awesome-6.5.2/css/v4-shims.css | 2194 ---- .../font-awesome-6.5.2/css/v4-shims.min.css | 6 - .../webfonts/fa-brands-400.ttf | Bin 209128 -> 0 bytes .../webfonts/fa-brands-400.woff2 | Bin 117852 -> 0 bytes .../webfonts/fa-regular-400.ttf | Bin 67860 -> 0 bytes .../webfonts/fa-regular-400.woff2 | Bin 25392 -> 0 bytes .../webfonts/fa-solid-900.ttf | Bin 420332 -> 0 bytes .../webfonts/fa-solid-900.woff2 | Bin 156400 -> 0 bytes .../webfonts/fa-v4compatibility.ttf | Bin 10832 -> 0 bytes .../webfonts/fa-v4compatibility.woff2 | Bin 4792 -> 0 bytes .../deps/headroom-0.11.0/headroom.min.js | 7 - .../headroom-0.11.0/jQuery.headroom.min.js | 7 - .../pr-358/deps/jquery-3.6.0/jquery-3.6.0.js | 10881 ---------------- .../deps/jquery-3.6.0/jquery-3.6.0.min.js | 2 - .../deps/jquery-3.6.0/jquery-3.6.0.min.map | 1 - .../search-1.0.0/autocomplete.jquery.min.js | 7 - .../pr-358/deps/search-1.0.0/fuse.min.js | 9 - .../pr-358/deps/search-1.0.0/mark.min.js | 7 - pr-preview/pr-358/headshot_placeholder.png | Bin 11439 -> 0 bytes pr-preview/pr-358/index.html | 212 - pr-preview/pr-358/katex-auto.js | 14 - pr-preview/pr-358/lightswitch.js | 85 - pr-preview/pr-358/link.svg | 12 - pr-preview/pr-358/logo.png | Bin 6508 -> 0 bytes pr-preview/pr-358/pkgdown.js | 162 - pr-preview/pr-358/pkgdown.yml | 18 - pr-preview/pr-358/reference/analyse.html | 155 - pr-preview/pr-358/reference/analyze.html | 8 - .../pr-358/reference/data_dictionary.html | 151 - pr-preview/pr-358/reference/figures/logo.png | Bin 6508 -> 0 bytes .../figures/p4s_workflow_structure.png | Bin 7370 -> 0 bytes .../plot_emission_intensity_cement_meta.png | Bin 28508 -> 0 bytes .../plot_emission_intensity_steel_meta.png | Bin 26713 -> 0 bytes ...lot_match_success_rate_abs_n_bank_type.png | Bin 50682 -> 0 bytes ...atch_success_rate_abs_outstanding_meta.png | Bin 48738 -> 0 bytes ...lot_match_success_rate_rel_n_bank_type.png | Bin 57409 -> 0 bytes ...atch_success_rate_rel_outstanding_meta.png | Bin 50421 -> 0 bytes .../reference/figures/plot_sankey_sector.png | Bin 24211 -> 0 bytes ...t_scatter_alignment_exposure_bank_type.png | Bin 53201 -> 0 bytes .../plot_scatter_automotive_by_bank_type.png | Bin 90609 -> 0 bytes ..._company_by_bank_type_less_significant.png | Bin 96672 -> 0 bytes .../figures/plot_tech_mix_automotive_meta.png | Bin 21108 -> 0 bytes .../figures/plot_tech_mix_power_meta.png | Bin 25305 -> 0 bytes ...ot_trajectory_automotive_electric_meta.png | Bin 35832 -> 0 bytes .../plot_trajectory_coal_coal_meta.png | Bin 36534 -> 0 bytes .../reference/figures/pml_readme_viz.png | Bin 100467 -> 0 bytes pr-preview/pr-358/reference/index.html | 159 - .../reference/initialise_default_project.html | 144 - .../reference/initialize_default_project.html | 8 - .../pr-358/reference/match_loanbooks.html | 159 - pr-preview/pr-358/reference/prepare_abcd.html | 153 - .../reference/prioritise_and_diagnose.html | 156 - .../reference/prioritize_and_diagnose.html | 8 - .../rmi_logo_horitzontal_no_tagline.svg | 1 - .../pr-358/rmi_logo_stacked_tag_white.svg | 1 - pr-preview/pr-358/search.json | 1 - pr-preview/pr-358/sitemap.xml | 26 - 103 files changed, 40176 deletions(-) delete mode 100644 pr-preview/pr-358/404.html delete mode 100644 pr-preview/pr-358/LICENSE-text.html delete mode 100644 pr-preview/pr-358/LICENSE.html delete mode 100644 pr-preview/pr-358/articles/company_alignment_metric.html delete mode 100644 pr-preview/pr-358/articles/config_yml.html delete mode 100644 pr-preview/pr-358/articles/cookbook_advanced_use_cases.html delete mode 100644 pr-preview/pr-358/articles/cookbook_interpretation.html delete mode 100644 pr-preview/pr-358/articles/cookbook_overview.html delete mode 100644 pr-preview/pr-358/articles/cookbook_preparatory_steps.html delete mode 100644 pr-preview/pr-358/articles/cookbook_running_the_analysis.html delete mode 100644 pr-preview/pr-358/articles/data_dictionary.html delete mode 100644 pr-preview/pr-358/articles/data_dictionary_files/core-js-2.5.3/LICENSE delete mode 100644 pr-preview/pr-358/articles/data_dictionary_files/core-js-2.5.3/package.json delete mode 100644 pr-preview/pr-358/articles/data_dictionary_files/core-js-2.5.3/shim.min.js delete mode 100644 pr-preview/pr-358/articles/data_dictionary_files/htmlwidgets-1.6.4/htmlwidgets.js delete mode 100644 pr-preview/pr-358/articles/data_dictionary_files/react-18.2.0/AUTHORS delete mode 100644 pr-preview/pr-358/articles/data_dictionary_files/react-18.2.0/LICENSE.txt delete mode 100644 pr-preview/pr-358/articles/data_dictionary_files/react-18.2.0/react-dom.min.js delete mode 100644 pr-preview/pr-358/articles/data_dictionary_files/react-18.2.0/react.min.js delete mode 100644 pr-preview/pr-358/articles/data_dictionary_files/reactable-0.4.4/reactable.css delete mode 100644 pr-preview/pr-358/articles/data_dictionary_files/reactable-0.4.4/reactable.js delete mode 100644 pr-preview/pr-358/articles/data_dictionary_files/reactable-0.4.4/reactable.js.map delete mode 100644 pr-preview/pr-358/articles/data_dictionary_files/reactable-0.4.4/reactable.server.js delete mode 100644 pr-preview/pr-358/articles/data_dictionary_files/reactable-0.4.4/reactable.server.js.LICENSE.txt delete mode 100644 pr-preview/pr-358/articles/data_dictionary_files/reactable-0.4.4/reactable.server.js.map delete mode 100644 pr-preview/pr-358/articles/data_dictionary_files/reactable-0.4.4/reactable.yaml delete mode 100644 pr-preview/pr-358/articles/data_dictionary_files/reactable-binding-0.4.4/reactable.js delete mode 100644 pr-preview/pr-358/articles/data_dictionary_files/reactwidget-2.0.0/react-tools.js delete mode 100644 pr-preview/pr-358/articles/index.html delete mode 100644 pr-preview/pr-358/articles/loanbook_aggregated_alignment_metric.html delete mode 100644 pr-preview/pr-358/articles/sector_split.html delete mode 100644 pr-preview/pr-358/authors.html delete mode 100644 pr-preview/pr-358/deps/Overpass-0.4.9/font.css delete mode 100644 pr-preview/pr-358/deps/Overpass-0.4.9/qFda35WCmI96Ajtm83upeyoaX6QPnlo6_PPbM5qKhcc.woff2 delete mode 100644 pr-preview/pr-358/deps/Overpass-0.4.9/qFda35WCmI96Ajtm83upeyoaX6QPnlo6_PPbMJqKhcc.woff2 delete mode 100644 pr-preview/pr-358/deps/Overpass-0.4.9/qFda35WCmI96Ajtm83upeyoaX6QPnlo6_PPbMZqKhcc.woff2 delete mode 100644 pr-preview/pr-358/deps/Overpass-0.4.9/qFda35WCmI96Ajtm83upeyoaX6QPnlo6_PPbOpqKhcc.woff2 delete mode 100644 pr-preview/pr-358/deps/Overpass-0.4.9/qFda35WCmI96Ajtm83upeyoaX6QPnlo6_PPbPpqK.woff2 delete mode 100644 pr-preview/pr-358/deps/bootstrap-5.3.1/bootstrap.bundle.min.js delete mode 100644 pr-preview/pr-358/deps/bootstrap-5.3.1/bootstrap.bundle.min.js.map delete mode 100644 pr-preview/pr-358/deps/bootstrap-5.3.1/bootstrap.min.css delete mode 100644 pr-preview/pr-358/deps/bootstrap-toc-1.0.1/bootstrap-toc.min.js delete mode 100644 pr-preview/pr-358/deps/clipboard.js-2.0.11/clipboard.min.js delete mode 100644 pr-preview/pr-358/deps/data-deps.txt delete mode 100644 pr-preview/pr-358/deps/font-awesome-6.5.2/css/all.css delete mode 100644 pr-preview/pr-358/deps/font-awesome-6.5.2/css/all.min.css delete mode 100644 pr-preview/pr-358/deps/font-awesome-6.5.2/css/v4-shims.css delete mode 100644 pr-preview/pr-358/deps/font-awesome-6.5.2/css/v4-shims.min.css delete mode 100644 pr-preview/pr-358/deps/font-awesome-6.5.2/webfonts/fa-brands-400.ttf delete mode 100644 pr-preview/pr-358/deps/font-awesome-6.5.2/webfonts/fa-brands-400.woff2 delete mode 100644 pr-preview/pr-358/deps/font-awesome-6.5.2/webfonts/fa-regular-400.ttf delete mode 100644 pr-preview/pr-358/deps/font-awesome-6.5.2/webfonts/fa-regular-400.woff2 delete mode 100644 pr-preview/pr-358/deps/font-awesome-6.5.2/webfonts/fa-solid-900.ttf delete mode 100644 pr-preview/pr-358/deps/font-awesome-6.5.2/webfonts/fa-solid-900.woff2 delete mode 100644 pr-preview/pr-358/deps/font-awesome-6.5.2/webfonts/fa-v4compatibility.ttf delete mode 100644 pr-preview/pr-358/deps/font-awesome-6.5.2/webfonts/fa-v4compatibility.woff2 delete mode 100644 pr-preview/pr-358/deps/headroom-0.11.0/headroom.min.js delete mode 100644 pr-preview/pr-358/deps/headroom-0.11.0/jQuery.headroom.min.js delete mode 100644 pr-preview/pr-358/deps/jquery-3.6.0/jquery-3.6.0.js delete mode 100644 pr-preview/pr-358/deps/jquery-3.6.0/jquery-3.6.0.min.js delete mode 100644 pr-preview/pr-358/deps/jquery-3.6.0/jquery-3.6.0.min.map delete mode 100644 pr-preview/pr-358/deps/search-1.0.0/autocomplete.jquery.min.js delete mode 100644 pr-preview/pr-358/deps/search-1.0.0/fuse.min.js delete mode 100644 pr-preview/pr-358/deps/search-1.0.0/mark.min.js delete mode 100644 pr-preview/pr-358/headshot_placeholder.png delete mode 100644 pr-preview/pr-358/index.html delete mode 100644 pr-preview/pr-358/katex-auto.js delete mode 100644 pr-preview/pr-358/lightswitch.js delete mode 100644 pr-preview/pr-358/link.svg delete mode 100644 pr-preview/pr-358/logo.png delete mode 100644 pr-preview/pr-358/pkgdown.js delete mode 100644 pr-preview/pr-358/pkgdown.yml delete mode 100644 pr-preview/pr-358/reference/analyse.html delete mode 100644 pr-preview/pr-358/reference/analyze.html delete mode 100644 pr-preview/pr-358/reference/data_dictionary.html delete mode 100644 pr-preview/pr-358/reference/figures/logo.png delete mode 100644 pr-preview/pr-358/reference/figures/p4s_workflow_structure.png delete mode 100644 pr-preview/pr-358/reference/figures/plot_emission_intensity_cement_meta.png delete mode 100644 pr-preview/pr-358/reference/figures/plot_emission_intensity_steel_meta.png delete mode 100644 pr-preview/pr-358/reference/figures/plot_match_success_rate_abs_n_bank_type.png delete mode 100644 pr-preview/pr-358/reference/figures/plot_match_success_rate_abs_outstanding_meta.png delete mode 100644 pr-preview/pr-358/reference/figures/plot_match_success_rate_rel_n_bank_type.png delete mode 100644 pr-preview/pr-358/reference/figures/plot_match_success_rate_rel_outstanding_meta.png delete mode 100644 pr-preview/pr-358/reference/figures/plot_sankey_sector.png delete mode 100644 pr-preview/pr-358/reference/figures/plot_scatter_alignment_exposure_bank_type.png delete mode 100644 pr-preview/pr-358/reference/figures/plot_scatter_automotive_by_bank_type.png delete mode 100644 pr-preview/pr-358/reference/figures/plot_scatter_automotive_company_by_bank_type_less_significant.png delete mode 100644 pr-preview/pr-358/reference/figures/plot_tech_mix_automotive_meta.png delete mode 100644 pr-preview/pr-358/reference/figures/plot_tech_mix_power_meta.png delete mode 100644 pr-preview/pr-358/reference/figures/plot_trajectory_automotive_electric_meta.png delete mode 100644 pr-preview/pr-358/reference/figures/plot_trajectory_coal_coal_meta.png delete mode 100644 pr-preview/pr-358/reference/figures/pml_readme_viz.png delete mode 100644 pr-preview/pr-358/reference/index.html delete mode 100644 pr-preview/pr-358/reference/initialise_default_project.html delete mode 100644 pr-preview/pr-358/reference/initialize_default_project.html delete mode 100644 pr-preview/pr-358/reference/match_loanbooks.html delete mode 100644 pr-preview/pr-358/reference/prepare_abcd.html delete mode 100644 pr-preview/pr-358/reference/prioritise_and_diagnose.html delete mode 100644 pr-preview/pr-358/reference/prioritize_and_diagnose.html delete mode 100644 pr-preview/pr-358/rmi_logo_horitzontal_no_tagline.svg delete mode 100644 pr-preview/pr-358/rmi_logo_stacked_tag_white.svg delete mode 100644 pr-preview/pr-358/search.json delete mode 100644 pr-preview/pr-358/sitemap.xml diff --git a/pr-preview/pr-358/404.html b/pr-preview/pr-358/404.html deleted file mode 100644 index 147a6b4c..00000000 --- a/pr-preview/pr-358/404.html +++ /dev/null @@ -1,135 +0,0 @@ - - - - - - - -Page not found (404) • pacta.multi.loanbook - - - - - - - - - - - - - - - - Skip to contents - - -
-
-
-

Page not found (404)

- -
- -Content not found. Please use links in the navbar. - -
-
- - -
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
- -

© RMI

- -
-
-
-
-
-
-
- - - - - - - - - - - diff --git a/pr-preview/pr-358/LICENSE-text.html b/pr-preview/pr-358/LICENSE-text.html deleted file mode 100644 index c1d63482..00000000 --- a/pr-preview/pr-358/LICENSE-text.html +++ /dev/null @@ -1,104 +0,0 @@ - -License • pacta.multi.loanbook - Skip to contents - - -
-
-
-

License

- -
- -
YEAR: 2024
-COPYRIGHT HOLDER: RMI
-
- -
- - -
-
-
-
-
-
-
-
-
-
-
-
-
-
-
- -

© RMI

- -
-
-
-
-
-
- - - - - - - - - - - diff --git a/pr-preview/pr-358/LICENSE.html b/pr-preview/pr-358/LICENSE.html deleted file mode 100644 index 3d06d546..00000000 --- a/pr-preview/pr-358/LICENSE.html +++ /dev/null @@ -1,108 +0,0 @@ - -MIT License • pacta.multi.loanbook - Skip to contents - - -
-
-
-

MIT License

- Source: LICENSE.md -
- -
- -

Copyright (c) 2024 RMI-PACTA

-

Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated documentation files (the “Software”), to deal in the Software without restriction, including without limitation the rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the Software, and to permit persons to whom the Software is furnished to do so, subject to the following conditions:

-

The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software.

-

THE SOFTWARE IS PROVIDED “AS IS”, WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.

-
- -
- - -
-
-
-
-
-
-
-
-
-
-
-
-
-
-
- -

© RMI

- -
-
-
-
-
-
- - - - - - - - - - - diff --git a/pr-preview/pr-358/articles/company_alignment_metric.html b/pr-preview/pr-358/articles/company_alignment_metric.html deleted file mode 100644 index bb760adc..00000000 --- a/pr-preview/pr-358/articles/company_alignment_metric.html +++ /dev/null @@ -1,535 +0,0 @@ - - - - - - - -Calculation of a company alignment metric • pacta.multi.loanbook - - - - - - - - - - - - - - - Skip to contents - - -
- - - - -
-
-

Calculation of a company alignment metric

- - - Source: vignettes/company_alignment_metric.Rmd -
company_alignment_metric.Rmd
-
- - - -

PACTA methodology note
Calculation of a company alignment metric

-

Prepared by Jacob Kastl

-
-

1. Background -

-
-

1.1 The use case for aggregated alignment metrics -

-

The company alignment metric described below is intended to help make -sense of alignment patterns in large analyses, e.g. in the case of a -supervisory analysis of the banking system, where many loan books are -compared. In such situations, high level results are helpful in -highlighting the most important patterns that warrant an in-depth -analysis of the more granular standard PACTA metrics.

-

Identifying such patterns means that we need to reduce the -information to a more manageable quantity. While this inevitably leads -to a loss of granularity, this is justifiable for summarizing main -findings, as long as the outcomes are consistent with the main PACTA -metrics.

-

We choose an approach that first aggregates company alignment to a -relative metric at the company/sector level for each of the PACTA -sectors the company operates in. A methodology to calculating this -metric is provided both for the market share approach and the sectoral -decarbonization approach.

-
-
-
-

2. The company alignment metric -

-
-

2.1 Basic concepts of the company alignment metric -

-

In this section, we derive the company alignment metric -mathematically and provide interpretations of the relevant pieces. While -in practice, this metric will most often be calculate at time -t=5t = 5, -it can be calculated for any point in time, which is why we -generalise.

-

For companies operating in sectors where clear technology transitions -should take place, certain technologies need to be built out -(BOBO) -whilst others need to be phased out -(POPO). -We define the direction -dd -of technology -aa -in sector -bb -as:

-

da,b={BOif a is a low-carbon technologyPOif a is a high-carbon technology, d_{a,b} = - \begin{cases} - BO & \quad \text{if } a \text{ is a low-carbon technology}\\ - PO & \quad \text{if } a \text{ is a high-carbon technology} - \end{cases}, -

-

where low-carbon technology and high-carbon technology are mutually -exclusive categories.

-

The forward-looking production plan -pp -of company -cc -for technology -aa -in sector -bb -at time -tt -is:

-

pa,b,c,d,tp_{a,b,c,d,t}

-

Which means that at the sector level, we get a net -production plan of:

-

pb,c,t=∑∀a∈bpa,b,c,d,tp_{b,c,t} = \sum_{\forall a \in b} p_{a,b,c,d,t} -Correspondingly, the scenario-based production value -ss -of company -cc -for technology -aa -in sector -bb -at time -tt -is:

-

sa,b,c,d,ts_{a,b,c,d,t}

-

and at the sector level, we therefore get a net -scenario-based production value of:

-

sb,c,t=∑∀a∈bsa,b,c,d,ts_{b,c,t} = \sum_{\forall a \in b} s_{a,b,c,d,t} -We define a directional dummy variable -DD -for technology -aa, -given its direction -dd -in sector -bb -as:

-

Da,b,d={1if da,b=BO−1if da,b=PO D_{a,b,d} = - \begin{cases} - 1 & \quad \text{if } d_{a,b} = BO\\ - -1 & \quad \text{if } d_{a,b} = PO - \end{cases} -

-

With these definitions, we calculate the total technology deviation -(Δtotal\Delta total) -of company -cc -for technology -aa -in sector -bb -at time -tt -as:

-

Δtotala,b,c,d,t=(pa,b,c,d,t−sa,b,c,d,t)×Da,b,d\Delta total_{a,b,c,d,t} = (p_{a,b,c,d,t} - s_{a,b,c,d,t}) \times D_{a,b,d} -Note that the total technology deviation will be considered aligned when ->= 0 and misaligned when < 0. The Directional dummy ensures this -is the case both for build out and phase out technologies.

-
-

2.1.1 Addressing scenarios with bridge technologies -

-

In case a technology trajectory in a transition scenario cannot be -clearly classified as a build out or phase out technology over the near -to medium term, we treat such a technology as a bridge technology. More -specifically, this is the case, when the production trajectory for a -technology remains stagnant or the changes vary in direction over a time -frame needed to carry out new investments. Usually, a bridge technology -will be a high-carbon technology that is less emissions intensive than -other high-carbon technologies which need to be phased out first. -Whether or not a technology is considered a bridge technology therefore -depends largely on scenario assumptions and will sometimes differ -between regions even within a scenario.

-

As a bridge technology is considered high-carbon in principle, but -should not yet be phased out, we need to apply a calculation that -incentivises production planning as close to the scenario-based value as -possible. This ensures that both an overshoot and an undershoot will -lead to deteriorating alignment metrics.

-

We therefore use a two-sided misalignment logic, which adjusts the -total technology deviation for bridge technology -aa -at time -tt -as:

-

Δtotala,b,c,d,tbridge=−|pa,b,c,d,t−sa,b,c,d,t|\Delta total_{a,b,c,d,t}^{bridge} = -|p_{a,b,c,d,t} - s_{a,b,c,d,t}| -Contrary to the standard formulation of the technology alignment -deviation, the technology deviation for a bridge technology has a -maximum at 0, on the basis that the production forecast exactly meets -the scenario-based value at time -tt. -Any deviation from that is considered misalignment. The remainder of the -calculation remains unchanged.

-
-
-
-

2.2 Net aggregate company alignment metric -

-

Based on the total technology deviations calculated above, we can now -derive the net aggregate company alignment metric -yy. -To derive the net aggregate company alignment metric, we first define -calculate the total deviation of company -cc -for sector -bb -at time -tt -as:

-

Δtotalb,c,t=∑∀a∈bΔtotala,b,c,d,t\Delta total_{b,c,t} = \sum_{\forall a \in b} \Delta total_{a,b,c,d,t} -We then note that the total scenario-based value for company -cc -in sector -bb -at time -tt -is:

-

totalb,c,tscen=sb,c,t=∑∀a∈bsa,b,c,d,ttotal_{b,c,t}^{scen} = s_{b,c,t} = \sum_{\forall a \in b} s_{a,b,c,d,t} -With these definitions, we derive the net aggregate company alignment -metric -yy -for company -cc -in sector -bb -at time -tt -as:

-

yb,c,t=Δtotalb,c,ttotalb,c,tsceny_{b,c,t} = \dfrac{\Delta total_{b,c,t}}{total_{b,c,t}^{scen}}

-
-

Interpretation: -

-

The Net Aggregate Company Alignment Metric is a summary of the -alignment of a company in a sector across all relevant technologies -within that sector. It is intended as an overall summary metric that -shows if a company is aligned with a climate scenario on aggregate. As -such, the metric is meant to be a starting point for further analysis. -It can be used as a basis to aggregate alignments of individual -companies in a loan book to get a high level overview of the alignment -in that loan book. It can also be used to further disaggregate the -company alignment metric to obtain more granular insights about its -underlying drivers.

-

In general, -yb,c,t>=0y_{b,c,t} >= 0 -means that a company is - on aggregate - aligned with a climate -scenario, whereas -yb,c,t<0y_{b,c,t} < 0 -means that it is misaligned. For each of the technologies in the sector -that a company operates in, we measure the directional deviation from -its corresponding scenario-based value at time -tt. -A positive value of this deviation indicates alignment and a negative -value indicates misalignment, regardless of the direction of the -technology in the given scenario. The sum of those deviations across all -technologies is then divided by the company’s sector level scenario -value at time -tt. -This returns a percent deviation of the company production from its -scenario value at -tt, -where -y=0y = 0 -means that there is no deviation, -y=1y = 1 -means that the company is doing one hundred percent more in terms of -buildout and phaseout than it needs to and -y=−0.5y = -0.5 -means that it is doing fifty percent less than it needs to according to -the scenario values. Note that this metric does not show exactly where a -(mis)alignment comes from. Hence, following up this analysis on a more -granular level is always a good idea.

-
-
-
-

2.3 Build out and phase out company alignment metric -

-

One particular strength of the PACTA metrics for sectors with -technology pathways is that it will surface misalignment on the -technology level, which matters particularly in sectors that include -both build out and phase out technologies. Transition scenarios often -assume that particular technologies must be phased out in order to -remain within a carbon budget. Therefore, alignment metrics should not -obscure the need to phase out or build out technologies by simply adding -up bidirectional technology deviations. To account for this, we define a -disaggregation of the net aggregate company alignment metric into its -build out and phase out drivers. While this falls short of the maximum -granularity by design, it ensures that opposite trends in build out and -phase out are not obscured by the analysis.

-

The disaggregation of the net aggregate company alignment metric into -its -BOBO -and -POPO -drivers is designed such that the resulting sum of the disaggregated -metrics equals the net metric, because build out and phase out -technologies are mutually exclusive sets. To calculate the -BOBO -and -POPO -company alignment metrics, we need to derive the total deviation of -company -cc -by technology direction -dd -in sector -bb -at time -tt -as:

-

Δtotalb,c,d,t=∑∀a∈b,dΔtotala,b,c,d,t\Delta total_{b,c,d,t} = \sum_{\forall a \in b,d} \Delta total_{a,b,c,d,t} -The -BOBO(POPO) -company alignment metric -yy -of company -cc -by technology direction -dd -in sector -bb -at time -tt -is then defined as:

-

yb,c,d,t=Δtotalb,c,d,ttotalb,c,tsceny_{b,c,d,t} = \dfrac{\Delta total_{b,c,d,t}}{total_{b,c,t}^{scen}} -Note that the denominator remains at the net level so that the sum of -the disaggregated metrics is the net metric:

-

yb,c,d=BO,t+yb,c,d=PO,t=Δtotalb,c,d=BO,t+Δtotalb,c,d=PO,ttotalb,c,tscen=Δtotalb,c,ttotalb,c,tscen=yb,c,ty_{b,c,d=BO,t} + y_{b,c,d=PO,t} = \dfrac{\Delta total_{b,c,d=BO,t} + \Delta total_{b,c,d=PO,t}}{total_{b,c,t}^{scen}} = \dfrac{\Delta total_{b,c,t}}{total_{b,c,t}^{scen}} = y_{b,c,t} -This must be true because every technology -aa -must have one and only one direction -d∈{BO,PO}d \in \left\{BO,PO\right\}.

-
-

Interpretation: -

-

Previously, it was mentioned that the aggregated value of -yb,c,ty_{b,c,t} -does not indicate where the sources of (mis)alignment can be found. The -disaggregation into -BOBO -and -POPO -drivers of the company aggregate alignment metric aims to provide a high -level overview of just that. In essence, -yb,c,d,ty_{b,c,d,t} -only adds up the technology deviations for either buildout or phaseout -technologies, while still dividing by the sector level scenario value of -the company (including all technologies). This means that we get a -simple disaggregation of the overall alignment metric into its sum -parts. Hence, it should not be read as an indicator in isolation. -However, the disaggregation can be very helpful in determining if the -overall alignment is driven by a lack of buildout or by slow phaseout. -Additionally, what may look like overall alignment near the target with -yb,c,ty_{b,c,t} -close to zero may in theory be composed of significantly overaligned -buildout and significantly misaligned phaseout or vice versa. This goes -to show that, companies active in sectors with both buidlout and -phaseout technologies, it is important to understand the drivers behind -that overall alignment metric.

-
-
-
-

2.4 Net aggregate company alignment metric in emissions intensity -sectors -

-

For sectors where alignment is calculated using emissions intensity -metrics there is no distinction between build out and phase out -technologies. This means there is only a net aggregate company alignment -metric in emissions intensity sectors -y*y^* -and the calculation of that metric is much more straight forward.

-

Let emissions intensity based on forward-looking production plan -p*p^* -of company -cc -for sector -bb -at time -tt:

-

pb,c,t*p_{b,c,t}^* -We also define scenario-based emissions intensity value -s*s^* -of company -cc -for sector -bb -at time -tt -as:

-

sb,c,t*s_{b,c,t}^* -We then derive the total emissions intensity deviation -(Δtotal*\Delta total^*) -of company -cc -in sector -bb -at time -tt:

-

Δtotalb,c,t*=pb,c,t*−sb,c,t*\Delta total_{b,c,t}^* = p_{b,c,t}^* - s_{b,c,t}^* -It follows that the alignment measure -y*y^* -of company -cc -based on emissions intensities in sector -bb -at time -tt -is:

-

yb,c,t*=Δtotalb,c,t*sb,c,ty_{b,c,t}^* = \dfrac{\Delta total_{b,c,t}^*}{s_{b,c,t}}

-
-

Interpretation: -

-

The company alignment metric for emissions intensity sectors -yb,c,t*y_{b,c,t}^* -follows a similar logic as the one for sectors with technology pathways, -in that it measures the percent deviation of the emissions intensity in -time -tt -for a company from its scenario-based emissions intensity at time -tt. -Again, this means that -yb,c,t*=0y_{b,c,t}^* = 0 -describes a company that is right on track with with its emissions -intensity relative to the scenario-based value, whereas -yb,c,t*=1y_{b,c,t}^* = 1 -means the emissions intensity is one hundred percent better (lower) than -required by the scenario value and -yb,c,t*=−0.5y_{b,c,t}^* = -0.5 -means that the emissions intensity is fifty percent worse (higher) than -implied by the scenario value. There is no disaggregation of emissions -intensity based metrics, as these are calculated on the sector level to -begin with.

-
-
-
-
-
- - - -
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
- -

© RMI

- -
-
-
-
-
-
-
- - - - - - - - - - - diff --git a/pr-preview/pr-358/articles/config_yml.html b/pr-preview/pr-358/articles/config_yml.html deleted file mode 100644 index b7c7a619..00000000 --- a/pr-preview/pr-358/articles/config_yml.html +++ /dev/null @@ -1,695 +0,0 @@ - - - - - - - -Configuring the application • pacta.multi.loanbook - - - - - - - - - - - - - - - Skip to contents - - -
- - - - -
-
-

Configuring the application

- - - Source: vignettes/config_yml.Rmd -
config_yml.Rmd
-
- - - -
-

Intro -

-

Most of the functions in this package require a path to a -config.yml file as input. This structure allows for an -easily reviewed file that contains all relevant parameters that should -be / were used for a given multi-loanbook analysis. Below is a full -documentation of each option.

-
-
-

Preface -

-

The config file is separated into a few top-level “sections” that -contain contextually similar options. The top-level sections will be -documented as well below, but note that the top-level sections -themselves never have a value directly associated with them.

-

Also note that the config file must have the top-level section -default. This is related to a feature of the -yaml package which facilitates having and targeting -different config sets for different purposes. Technically, one could -leverage this for use with pacta.multi.loanbook, but it is not -recommended.

-
-
-

Options -

-
-

directories: -

-

The directories -section contains options to define locally accessible paths where input -and output data should be found or saved. A full example directories -section might look like:

-
  directories:
-    dir_input: "~/Desktop/test/input"
-    dir_prepared_abcd: "~/Desktop/test/prepared_abcd"
-    dir_matched_loanbooks: "~/Desktop/test/matched_loanbooks"
-    dir_prioritized_loanbooks_and_diagnostics: "~/Desktop/test/prioritized_loanbooks_and_diagnostics"
-    dir_analysis: "~/Desktop/test/analysis"
-
-
dir_input -
-

dir_input is a -path to a directory that contains all input data to be used. Input data -is any data set that must be produced or obtained externally by the user -and that is not the output of any of the functions in this package. This -includes files only needed optionally. It must be a single -string/character value, and it must refer to a valid, accessible, local -directory. As an example:

-
    dir_input: "~/Desktop/test/input"
-
-
-
dir_prepared_abcd -
-

dir_prepared_abcd -is a path to a directory where the outputs of the function -prepare_abcd() should be saved. It must be a single -string/character value, and it must refer to a valid, accessible, local -directory. As an example:

-
    dir_prepared_abcd: "~/Desktop/test/prepared_abcd"
-
-
-
dir_matched_loanbooks -
-

dir_matched_loanbooks -is a path to a directory where the outputs of the function -match_loanbooks() should be saved. It must be a single -string/character value, and it must refer to a valid, accessible, local -directory. As an example:

-
    dir_matched_loanbooks: "~/Desktop/test/matched_loanbooks"
-
-
-
dir_prioritized_loanbooks_and_diagnostics -
-

dir_prioritized_loanbooks_and_diagnostics -is a path to a directory where the outputs of the function -prioritise_and_diagnose() should be saved. It must be a -single string/character value, and it must refer to a valid, accessible, -local directory. As an example:

-
    dir_prioritized_loanbooks_and_diagnostics: "~/Desktop/test/prioritized_loanbooks_and_diagnostics"
-
-
-
dir_analysis -
-

dir_analysis is a -path to a directory where the outputs of the function -analyse() should be saved. It must be a single -string/character value, and it must refer to a valid, accessible, local -directory. As an example:

-
    dir_analysis: "~/Desktop/test/analysis"
-
-
-
-

file_names: -

-

The file_names -section contains options to define the file names of locally accessible -files found in the directories defined in the directories -section. The directories and file names are defined separately to allow -for flexibility in where and how your input and output files are stored. -A full example file_names -section might look like:

-
  file_names:
-    filename_scenario_tms: "scenarios_2022_p4b.csv"
-    filename_scenario_sda: "scenarios_2022_ei_p4b.csv"
-    filename_abcd: "2023-02-17_AI_RMI_PACTA for Banks Free dataset_EO_2022Q4.xlsx"
-    sheet_abcd: "Company Indicators - PACTA Comp"
-
-
filename_scenario_tms -
-

filename_scenario_tms -is the filename of the file that contains production based scenario -data. The file specified by filename_scenario_tms -must exist in the directory specified by the dir_input -parameter. It must be a single string/character value, and it must refer -to a valid, accessible, local file. As an example:

-
    filename_scenario_tms: "scenarios_2022_p4b.csv
-
-
-
filename_scenario_sda -
-

filename_scenario_sda -is the filename of the file that contains emission intensity based -scenario data. The file specified by filename_scenario_sda -must exist in the directory specified by the dir_input -parameter. It must be a single string/character value, and it must refer -to a valid, accessible, local file. As an example:

-
    filename_scenario_sda: "scenarios_2022_ei_p4b.csv"
-
-
-
filename_abcd -
-

filename_abcd is -the filename of the file in the directory defined by dir_input that -contains asset based company data, including production values and -physical emission intensity values. It must be a single string/character -value, and it must refer to a valid, accessible, local file. As an -example:

-
    filename_abcd: "2023-02-17_AI_RMI_PACTA for Banks Free dataset_EO_2022Q4.xlsx"
-
-
-
sheet_abcd -
-

sheet_abcd is the -name of the sheet that contains asset based company data in the file -defined by filename_abcd and -stored in the directory defined by dir_input. It -must be a single string/character value, and it must refer to a valid, -accessible, sheet name in the appropriate file. As an example:

-
    sheet_abcd: "Company Indicators - PACTA Comp"
-
-
-
-

project_parameters: -

-

A full example project_parameters -section might look like:

-
  project_parameters:
-    scenario_source: "weo_2022"
-    scenario_select: "nze_2050"
-    region_select: "global"
-    start_year: 2022
-    time_frame: 5
-    by_group: "group_id"
-
-
scenario_source -
-

scenario_source -is an identifier of the scenario source to be used. It must be a single -string/character value, and it must refer to a valid, accessible, -scenario source identifier contained in the scenario data file/s defined -by filename_scenario_tms -and filename_scenario_sda. -Valid values typically look like "weo_2023" -or "geco_2022". -As an example:

-
    scenario_source: "weo_2022"
-
-
-
scenario_select -
-

scenario_select -is an identifier of the scenario to be used. It must be a single -string/character value, and it must refer to a valid, accessible, -scenario identifier corresponding to the scenario_source -and contained in the scenario data file/s defined by filename_scenario_tms -and filename_scenario_sda. -Valid values typically look like "nze_2050", -"aps" -or "steps". -As an example:

-
    scenario_select: "nze_2050"
-
-
-
region_select -
-

region_select is -an identifier of the region to be used. It must be a single -string/character value, and it must refer to a valid, accessible, region -identifier contained in the r2dii.data::region_isos -dataset where it must be listed as a region available for the -scenario_source. Valid values typically look like "global" -or "advanced economies". -As an example:

-
    region_select: "global"
-
-
-
start_year -
-

start_year is the -start year of the analysis. Normally, the start year should correspond -with year of the publication of the scenario in use. It must be a single -numeric value, and it must refer to a valid, accessible, year contained -in the scenario data file/s defined by filename_scenario_tms -and filename_scenario_sda. -Valid values typically look like 2022 or 2023 (note that -this value should not be wrapped in quotes). As an example:

-
    start_year: 2022
-
-
-
time_frame -
-

time_frame is the -number of years (starting from the start_year) that -the analysis covers, defining the time frame. It must be a single -numeric value, and it must define a valid, accessible, time frame -covered by the scenario data file/s defined by filename_scenario_tms -and filename_scenario_sda. -Valid values typically look like 5 or 6 (note that this -value should not be wrapped in quotes). As an example:

-
    time_frame: 5
-
-
-
by_group -
-

by_group -allows specifying the level of disaggregation to be used in the -analysis. It determines the variable along which the loan books are -grouped and thus the dimension by which to compare the PACTA -calculations. For example, one may want to calculate system-wide results -without disaggregation, using NULL or one may -want to analyse alignment along bank specific traits, such as "group_id" -or "bank_type". -It can be NULL or a -character vector of length 1. If it is not NULL, the -indicated name must be a variable that is provided in the input loan -books and it must be complete ("group_id" is automatically -created when reading in the loan books, so the user does not have to add -it to the raw loan books). If the provided character string is "NULL", -it will be treated as NULL. As an -example:

-
    by_group: "group_id"
-
-
-
-

sector_split: -

-

A full example sector_split -section might look like:

-
  sector_split:
-    apply_sector_split: TRUE
-    filename_split_company_id: "split_company_ids.csv"
-    filename_advanced_company_indicators: "2024-02-14_AI_2023Q4_RMI-Company-Indicators.xlsx"
-    sheet_advanced_company_indicators: "Company Activities"
-
-
apply_sector_split -
-

apply_sector_split -It must be a single logical value (either TRUE or FALSE). As an -example:

-
    apply_sector_split: TRUE
-
-
-
filename_split_company_id -
-

filename_split_company_id -is the filename of the CSV file that contains the split company ID data. -The file specified by filename_split_company_id -must exist in the directory specified by the dir_input -parameter. It must be a single string/character value, and it must refer -to a valid, accessible, local file. As an example:

-
    filename_split_company_id: "split_company_ids.csv"
-
-
-
filename_advanced_company_indicators -
-

filename_advanced_company_indicators -is the filename of the XLSX file that contains the Advanced Company -Indicators. The file specified by filename_advanced_company_indicators -must exist in the directory specified by the dir_input -parameter. It must be a single string/character value, and it must refer -to a valid, accessible, local file. As an example:

-
    filename_advanced_company_indicators: "2024-02-14_AI_2023Q4_RMI-Company-Indicators.xlsx"
-
-
-
sheet_advanced_company_indicators -
-

sheet_advanced_company_indicators -is the name of the sheet that contains asset based company production -data in the file defined by filename_advanced_company_indicators -and stored in the directory defined by dir_input. It -must be a single string/character value, and it must refer to a valid, -accessible, sheet name in the appropriate file. As an example:

-
    sheet_advanced_company_indicators: "Company Activities"
-
-
-
-

matching: -

-

A full example matching section -might look like:

-
  matching:
-    params_match_name:
-      by_sector: TRUE
-      min_score: 0.9
-      method: "jw"
-      p: 0.1
-      overwrite: NULL
-      join_id: NULL
-    manual_sector_classification:
-      use_manual_sector_classification: FALSE
-      filename_manual_sector_classification: "manual_sector_classification.csv"
-
-

params_match_name: -

-

A full example params_match_name -section might look like:

-
    params_match_name:
-      by_sector: TRUE
-      min_score: 0.9
-      method: "jw"
-      p: 0.1
-      overwrite: NULL
-      join_id: NULL
-
-
by_sector -
-

by_sector. It -must be a single logical value (either TRUE or FALSE). Further -explanation of this argument can be found in the documentation for r2dii.match::match_name(). -As an example:

-
      by_sector: TRUE
-
-
-
min_score -
-

min_score is a -number between 0-1, to set the minimum score threshold. A score of 1 is -a perfect match. It must be a single numeric value. Valid values -typically look like 0.7 or 0.9 (note that -this value should not be wrapped in quotes). Further -explanation of this argument can be found in the documentation for r2dii.match::match_name(). -As an example:

-
      min_score: 0.9
-
-
-
method -
-

method -is the method for distance calculation. It must be a single -string/character value, and it must refer to a valid method identifier, -one of "osa", -"lv", -"dl", -"hamming", -"lcs", -"qgram", -"cosine", -"jaccard", -"jw", -"soundex". -Further explanation of this argument can be found in the documentation -for r2dii.match::match_name() -and stringdist::stringdist-metrics. -As an example:

-
      method: "jw"
-
-
-
p -
-

p is the -prefix factor for Jaro-Winkler distance. The valid range for p is 0 -<= p <= 0.25. If p=0 (default), the Jaro-distance is returned. -Applies only to method=‘jw’. It must be a single numeric value. Valid -values typically look like 0.1 or 0.2 (note that -this value should not be wrapped in quotes). Further -explanation of this argument can be found in the documentation for r2dii.match::match_name(). -As an example:

-
      p: 0.1
-
-
-
overwrite -
-

overwrite. -Further explanation of this argument can be found in the documentation -for r2dii.match::match_name(). -As an example:

-
      overwrite: NULL
-
-
-
join_id -
-

join_id -is an optional parameter that allows defining by which variable to match -the loans to the the companies in the abcd. Its intended -use case is join based on unambiguous identifiers, such as the -lei, where such data is available. It can be NULL to use -standard name matching when no common identifiers are given. Must be a -join specification which is internally passed to -dplyr::inner_join. If it is an unnamed character/string -vector, the values are assumed to refer to identically named join -columns. If it is a named character vector, the names are used as the -join columns in the loanbook and the values are used as the -join columns in the abcd. Further explanation of this -argument can be found in the documentation for r2dii.match::match_name(). -As an example:

-
      join_id: c(lei_direct_loantaker = "lei")
-
-
-
-

manual_sector_classification: -

-

A full example manual_sector_classification -section might look like:

-
    manual_sector_classification:
-      use_manual_sector_classification: FALSE
-      filename_manual_sector_classification: "manual_sector_classification.csv"
-
-
use_manual_sector_classification -
-

use_manual_sector_classification -determines if the matching should use an internally provided sector -classification system or if it should use one provided by the user -instead. Internal sector classification systems are given in -r2dii.data::sector_classifications - see also additional documentation -in r2dii.data. The function will automatically attempt -to use one of the sector classification systems, based on the inputs in -the raw loan book files. If an externally prepared sector classification -system is to be used, for example because the loans are classified using -a system that is not provided in r2dii.data out of the box, the data -must be prepared following the same structure as found in -r2dii.data::sector_classifications. It must be a single -logical value (either TRUE or FALSE). As an -example:

-
      use_manual_sector_classification: FALSE
-
-
-
filename_manual_sector_classification -
-

filename_manual_sector_classification -is the filename of the CSV that contains the manual sector -classification data. The file specified by filename_manual_sector_classification -must exist in the directory specified by the dir_input -parameter. It must be a single string/character value, and it must refer -to a valid, accessible, local file. As an example:

-
      filename_manual_sector_classification: "manual_sector_classification.csv"
-
-
-
-
-

match_prioritize: -

-

A full example match_prioritize -section might look like:

-
  match_prioritize:
-    priority: NULL
-
-
priority -
-

priority -indicates the level of matching that should be prioritized when a loan -can be matched at multiple levels. It must be a single string/character -value or NULL, and it must -refer to a valid, accessible, local file. Further explanation of this -argument can be found in the documentation for r2dii.match::priortize(). -As an example:

-
    priority: NULL
-
-
-
-

prepare_abcd: -

-

A full example prepare_abcd -section might look like:

-
  prepare_abcd:
-    remove_inactive_companies: TRUE
-
-
remove_inactive_companies -
-

remove_inactive_companies -determines if inactive companies should be removed from the abcd dataset -or not. “Companies” here refers to company-sector combinations and -“inactive” characterizes such company-sector combinations that are -inactive at the end of the time frame analysed. When focusing forward -looking analysis on exposures in the end year, such inactive companies -may not produce meaningful results. It must be a single logical value -(either TRUE or FALSE). As an -example:

-
    remove_inactive_companies: TRUE
-
-
-
-

match_success_rate: -

-

A full example match_success_rate -section might look like:

-
  match_success_rate:
-    plot_width: 12
-    plot_height: 8
-    plot_units: "in"
-    plot_resolution: 300
-
-
plot_width -
-

plot_width is the -desired width of the XXX output plot in units defined by plot_units. It -must be a single numeric value. Valid values typically look like 10 or 12 (note that -this value should not be wrapped in quotes). As an example:

-
    plot_width: 12
-
-
-
plot_height -
-

plot_height is -the desired height of the XXX output plot in units defined by plot_units. It -must be a single numeric value. Valid values typically look like 6 or 8 (note that this -value should not be wrapped in quotes). As an example:

-
    plot_height: 8
-
-
-
plot_units -
-

plot_units is the -desired units to express the dimensions of the XXX output plot in plot_width and -plot_height. It -must be a single string/character value, and it must refer to a valid -unit identifier. Valid values typically look like "in" or -"px". -As an example:

-
    plot_units: "in"
-
-
-
plot_resolution -
-

plot_resolution -is the desired resolution of the XXX output plot in dpi. It must be a -single numeric value. Valid values typically look like 72 or 300 (note that -this value should not be wrapped in quotes). As an example:

-
    plot_resolution: 300
-
-
-
-
-
- - - -
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
- -

© RMI

- -
-
-
-
-
-
-
- - - - - - - - - - - diff --git a/pr-preview/pr-358/articles/cookbook_advanced_use_cases.html b/pr-preview/pr-358/articles/cookbook_advanced_use_cases.html deleted file mode 100644 index 77fac5fb..00000000 --- a/pr-preview/pr-358/articles/cookbook_advanced_use_cases.html +++ /dev/null @@ -1,557 +0,0 @@ - - - - - - - -Advanced Use Cases • pacta.multi.loanbook - - - - - - - - - - - - - - - Skip to contents - - -
- - - - -
-
-

Advanced Use Cases

- - - Source: vignettes/cookbook_advanced_use_cases.Rmd -
cookbook_advanced_use_cases.Rmd
-
- - - -
-

Advanced Use Cases -

-

This section provides a more detailed look at some of the more -advanced use cases of the pacta.multi.loanbook package for -PACTA for Supervisors analysis. First, we will touch on the technical -side of adjusting the analysis to your needs. Then, we will look at some -research questions that may occur in the field of banking supervision -with regard to climate transition risk and how the -pacta.multi.loanbook package can help answer them.

-
-

Tailoring the P4S Analysis to Your Needs -

-

Any adjustment to the analysis that you may want to make and that is -supported by the pacta.multi.loanbook package can be done -by adjusting the config.yml file. For information on each -of the parameters and the values they accept, please refer to -vignette("config_yml"). Here, we will provide some examples -of how you can adjust the analysis to your needs.

-
-
-

Use Case: Identify Transition Risks at the System Level -

-

Rationale: Supervisors need a systemic overview of -transition risks across the financial sector to understand -vulnerabilities that could affect financial stability.

-

Method: By analyzing different types of banks (e.g., -systemically important banks, credit unions, specialized banks - lending -to specific sectors) or banks with public commitments (e.g., targets, -transition plans), supervisors can determine if transition risks are -concentrated within particular bank categories. For instance, -specialized banks focusing on fossil fuel sectors may face a higher -transition risk if these exposures are significant across the sector. -Identifying these patterns helps pinpoint specific areas of the -financial system that could destabilize the broader economy.

-

The pacta.multi.loanbook package can help supervisors -check if certain bank types show significant patterns of misalignment -and exposure that could warrant additional focus. For example, if we -know that certain specialized banks are focused on fossil fuel sectors, -we can check if these banks are more misaligned than others and if they -have a higher exposure to misaligned companies. This can be done by -comparing the net aggregate alignment metrics of different bank types -and also comparing this to the system-wide misalignment.

-

In terms of implementation, suppose we want to run the analysis at -the aggregate system level as a reference and then determine how the -different bank types compare to this. We can obtain the required -results, by running the functions prioritise_and_diagnose() -and analyse() twice, with different parameter settings, -using the following steps:

-
    -
  • We need to group the underlying loan books once by bank type and -once aggregated across all banks. The parameter for that is the -by_group parameter. The aggregate result can be obtained by -setting by_group = "NULL" (this always works) and the bank -type results can be obtained by setting -by_group = "bank_type" (this assumes that the raw and -matched loan books contain a variable called bank_type with -the relevant classification). The results can then be compared to see if -there are any significant differences in the net aggregate alignment -metrics between the different bank types and the aggregate system -level.
    • -
  • We also need to update the output directories for each of the runs -to ensure the results of one configuration are not overwritten with the -results of the other when rerunning the functions. -
      -
    • For prioritise_and_diagnose(), we first set the output -to something like: -dir_prioritized_loanbooks_and_diagnostics: "path/to/prioritized_loanbooks_and_diagnostics_aggregate" -and in the second run to -dir_prioritized_loanbooks_and_diagnostics: "path/to/prioritized_loanbooks_and_diagnostics_bank_type".
      • -
    • For analyse(), we set the output to something like: -dir_analysis: "path/to/analysis_aggregate" and in the -second run to dir_analysis: "path/to/analysis_bank_type". -We also need to make sure that when we run analyse(), the -config.yml file points to the correct output directories for both the -prioritized_loanbooks_and_diagnostics and -analyse functions, so the correct input files can be -accessed.
      • -
    -
    • -
  • After successfully running the functions for both sets of -parameters, we have results both at the aggregate system level and for -the different bank types, based on the exact same input loan books and -keeping all other model parameters constant. We can then compare the -results to see if there are any significant differences in the net -aggregate alignment metrics between the different bank types and the -aggregate system level.
    • -
-

Assuming you have followed the naming convention described here, your -project folder should look something like this:

-
your_project_folder
-├── config.yml
-├── input
-│   ├── ABCD.xlsx
-│   ├── loanbooks
-│   │   ├── raw_loanbook_1.csv
-│   │   ├── raw_loanbook_2.csv
-│   │   └── ...
-│   ├── scenario_data_tms.csv
-│   ├── scenario_data_sda.csv
-│   └── ...
-├── prepared_abcd
-├── matched_loanbooks
-├── prioritized_loanbooks_and_diagnostics_aggregate
-├── prioritized_loanbooks_and_diagnostics_bank_type
-├── analysis_aggregate
-└── analysis_bank_type
-

Some important things to analyse when making such a comparison -are:

-
    -
  • Do we have any groups (aggregate or bank type level) that have -significantly lower match success rates than other groups? If so, it may -be difficult to draw conclusions about that group and it may be a good -idea to review the options for increasing the match success rate. You -can use the charts in -../prioritized_loanbooks_and_diagnostics_*/plot_match_success_rate_rel_*.png -to identify groups with low match success rates. Alternatively you can -use the file -../prioritized_loanbooks_and_diagnostics_*/lbk_match_success_rate_*.csv -for the precise numbers.
    • -
  • What is the distribution of financial exposure between groups and -sectors? Are there any groups that have an especially high exposure to a -sector and that may therefore be candidates for concentration risk? E.g. -is there any group that is mostly exposed to only one sector? Is there -any sector whose exposure is mostly to one group? You can use the charts -in -../prioritized_loanbooks_and_diagnostics_*/plot_match_success_rate_abs_*.png -to identify the financial exposures (matched and total) of each group to -each of the sectors. Alternatively you can use the file -../prioritized_loanbooks_and_diagnostics_*/lbk_match_success_rate_*.csv -for the precise numbers.
    • -
  • After identifying potentially interesting groups, you can use the -charts in -../analysis_*/plot_scatter_alignment_exposure_*.png to see -the distribution of the net alignment metric by financial exposure for -each of the sectors and each group. This will help you identify if there -are any groups that are especially misaligned in a sector (y-axis) and -if this value corresponds to high financial exposure (x-axis). Things to -look out for are: any dot that is far away from the 0 intercept of the -y-axis indicates a strong deviation from the scenario. The values below -zero are groups that are misaligned. On the system level, any dot with a -high exposure and significant misalignment is a potential candidate for -further analysis.
    • -
  • Also, within each sector, any relatively high exposure group that is -misaligned may be of concern, as this could indicate concentration -risk.
    • -
  • For example, if specialized banks that focus on the fossil fuel -sector were heavily misaligned and dominate the lending to the fossil -fuel sector, any materializing risks from the fossil fuel industry would -hit these banks especially hard.
    • -
-
-
-

Use Case: Assess Individual Financial Institutions’ Alignment and -Transition Risk -

-

Rationale: Understanding the transition alignment of -individual institutions supports targeted oversight and informed -dialogue with entities facing significant transition exposures by -tailoring their engagement and expectations based on each institution’s -specific risk profile and capabilities.

-

Method: Comparing institutions against benchmarks -(e.g., industry benchmarks -corporate economy-; financial benchmarks --rest of banks-.) also highlights those needing improvement or with best -practices. This enables a more precise understanding of each -institution’s potential for transition risk and informs supervisory -assessments and actions.

-

The pacta.multi.loanbook package can help supervisors -assess individual financial institutions’ alignment and transition risk -by providing detailed insights into the exposure and alignment of each -institution. For example, supervisors can compare the net aggregate -alignment metrics by financial exposure split by each of the banks and -the sectors they operate in. This helps identify which banks have -material exposures that are especially misaligned. Once identified, the -standard PACTA for banks results can be used for a deep dive into the -source of the misalignment of the identified institutions. For some -sectors, this will be especially helpful, when PACTA can be used to -identify misalignment at the technology level. If any particularly -material sources of misalignment can be found for a bank, the supervisor -may want to consider using this insight as part of their supervisory -review and urge the bank to clarify if and how this exposure is -accounted for in their risk management.

-

The implementation of this use case is relatively -straight-forward:

-
    -
  • We simply need to run the full sequence of functions once, with the -results grouped at the bank level. Recall that each loan book is -automatically assigned a variable "group_id", which can be -used here. We thus set by_group: "group_id" in the -config.yml.
    • -
  • We set output paths to something like: -dir_analysis: "path/to/analysis_group_id" and -dir_prioritized_loanbooks_and_diagnostics: "path/to/prioritized_loanbooks_and_diagnostics_group_id" -to ensure that the results are not overwritten when rerunning the -functions, in case any other calculations have been made before.
    • -
  • After running the functions, we have detailed results for each of -the banks, which can be used to identify any material sources of -misalignment and transition risk. The results can be used to inform -supervisory assessments and actions.
    • -
-

Assuming you have followed the naming convention described here, your -project folder should look something like this:

-
your_project_folder
-├── config.yml
-├── input
-│   ├── ABCD.xlsx
-│   ├── loanbooks
-│   │   ├── raw_loanbook_1.csv
-│   │   ├── raw_loanbook_2.csv
-│   │   └── ...
-│   ├── scenario_data_tms.csv
-│   ├── scenario_data_sda.csv
-│   └── ...
-├── prepared_abcd
-├── matched_loanbooks
-├── prioritized_loanbooks_and_diagnostics_group_id
-└── analysis_group_id
-

Some steps in identifying financial institutions that may warrant a -deeper individual analysis are:

-
    -
  • Check the match success rates of the different banks. If any bank -has a significantly lower match success rate than others, it may be -difficult to draw conclusions about that bank and it may be a good idea -to review the options for increasing the match success rate. You can use -the charts in -../prioritized_loanbooks_and_diagnostics_group_id/plot_match_success_rate_rel_*.png -to identify banks with low match success rates. Alternatively you can -use the file -../prioritized_loanbooks_and_diagnostics_group_id/lbk_match_success_rate_*.csv -for the precise numbers.
    • -
  • Check the distribution of financial exposure between banks and -sectors. Are there any banks that have an especially high exposure to a -sector and that may therefore be candidates for concentration risk? E.g. -is there any bank that is mostly exposed to only one sector? Is there -any sector whose exposure is mostly to one bank? You can use the charts -in -../prioritized_loanbooks_and_diagnostics_group_id/plot_match_success_rate_abs_*.png -to identify the financial exposures (matched and total) of each bank to -each of the sectors. Alternatively you can use the file -../prioritized_loanbooks_and_diagnostics_group_id/lbk_match_success_rate_*.csv -for the precise numbers.
    • -
  • After identifying potentially interesting banks, you can use the -charts in -../analysis_group_id/aggregate/plot_scatter_alignment_exposure_*.png -to see the distribution of the net alignment metric by financial -exposure for each of the sectors and each bank. This will help you -identify if there are any banks that are especially misaligned in a -sector (y-axis) and if this value corresponds to high financial exposure -(x-axis).
    • -
  • Once a bank has been identified that needs further inspection (very -positively aligned cases could also warrant additional analysis), you -can use the standard PACTA for banks results to identify the underlying -drivers of misalignment more clearly. This is especially important for -sectors, that have technology level pathways, as this will allow you to -identify if the misalignment is driven by the misalignment of any one of -the underlying technologies in particular, or if the misalignment comes -from all technologies across the board. To analyse this, you can use the -volume trajectory plots in -../analysis_group_id/standard/<bank name>/plot_trajectory_<sector>_<technology>.png -to see how far the projected pathway of production capacity deviates -from technology pathways. The further the line is in the red at time t5, -the higher the potential for this technology to drive misalignment. -However, you should also check the technology mix of the sector for the -identified bank, using the plots in -../analysis_group_id/standard/<bank name>/plot_tech_mix_<sector>.png. -You can check if the technologies that are strongly misaligned in t5 -make up a relevant share of the portfolio technology mix. If for -example, you have a bank that is misaligned in the power sector and you -identify that both coal-fired power and gas-fired power seem to be far -off their scenario values in t5, you still need to check if these -technologies make up a relevant share of the power capacity financed by -this bank. If the tech mix shows that the majority of the underlying -power capacity for this bank is concentrated in gas-fired power, whereas -the share of coal-fired power is minimal, then the misalignment from -gas-fired power has a greater impact on the overall alginment of the -bank and is therefore more important for its risk profile.
    • -
-
-
-

Use Case: Identify Hotspots and Interlinkages of Risk Exposure -

-

Rationale: Supervisors need to identify -concentrations of transition risks within certain sectors or -interlinkages across institutions to prevent risk contagion.

-

Method: Pinpointing sectors with heightened risk -exposures and identifying companies with high exposure across -institutions. This could be a proxy to identify concentrated risk -exposures.

-

The pacta.multi.loanbook package can help supervisors -identify hotspots and interlinkages of risk exposure by providing -detailed insights into the exposure and alignment of each institution. -For example, supervisors can compare the net aggregate alignment metrics -by financial exposure split by each of the sectors and the banks that -operate in them. This helps identify which sectors have material -exposures that are especially misaligned. Once identified, the company -level net aggregate alignment results can be used to analyze, if the -banks have similar exposures to misaligned sectors and companies.

-

This use case can use the same implementation as the previous one, -using results grouped by "group_id". We can again identify -banks and sectors with high exposure and misalignment using the plot in -../analysis_group_id/aggregate/plot_scatter_alignment_exposure_*.png. -Any sectors that have multiple significantly misaligned banks are of -particular interest here. We now use the file -../analysis_group_id/aggregate/company_exposure_net_aggregate_alignment_by_group_id.csv. -We sort by "alignment_metric" and filter by the final year -of the analysis. This will show the companies with the highest -misalignment at the top, including the exposure each bank has to the -companies. Companies with strong misalignment and large exposures across -banks can be considered a particularly important source of potential -transition risk and the exposure across banks implies some contagion -risk.

-
-
-

Use Case: Identify Potential Reputation Risks from Transition -Misalignment -

-

Rationale: Many banks have made public commitments -to align their portfolios with the Paris Agreement and signed up to -initiatives that proclaim this target. Not following up on such -commitments could lead to reputational risks for the banks, which should -be managed.

-

Method: Depending on the type of commitment made, it -may be relevant to check if future alignment is broadly aligned across -sectors for a bank, or alternatively, if the relevant sectors are -aligned with the bank’s commitments. The caveat to this exercise is that -forward looking alignment does not capture past efforts the bank may -already have made to align its portfolio. However, it can be a useful -complementary tool to check if the bank is on track to meet its -commitments in the future.

-

The following steps should be followed to implement this use -case:

-
    -
  • We need to group the underlying loan books once by -group_id (that is by bank) and once by -net_zero_pledge. The bank level result can be obtained by -setting by_group = "group_id" (this always works) and the -results by net zero pledge can be obtained by setting -by_group = "net_zero_pledge" (this assumes that the raw and -matched loan books contain a variable called -net_zero_pledge with the relevant classification).
    • -
  • We also need to update the output directories for each of the runs -to ensure the results of one configuration are not overwritten with the -results of the other when rerunning the functions. -
      -
    • For prioritise_and_diagnose(), we first set the output -to something like: -dir_prioritized_loanbooks_and_diagnostics: "path/to/prioritized_loanbooks_and_diagnostics_group_id" -and in the second run to -dir_prioritized_loanbooks_and_diagnostics: "path/to/prioritized_loanbooks_and_diagnostics_net_zero_pledge".
      • -
    • For analyse(), we set the output to something like: -dir_analysis: "path/to/analysis_group_id" and in the second -run to dir_analysis: "path/to/analysis_net_zero_pledge". We -also need to make sure that when we run analyse(), the -config.yml file points to the correct output directories for both the -prioritized_loanbooks_and_diagnostics and -analyse functions, so the correct input files can be -accessed.
      • -
    -
    • -
-

Assuming you have followed the naming convention described here, your -project folder should look something like this:

-
your_project_folder
-├── config.yml
-├── input
-│   ├── ABCD.xlsx
-│   ├── loanbooks
-│   │   ├── raw_loanbook_1.csv
-│   │   ├── raw_loanbook_2.csv
-│   │   └── ...
-│   ├── scenario_data_tms.csv
-│   ├── scenario_data_sda.csv
-│   └── ...
-├── prepared_abcd
-├── matched_loanbooks
-├── prioritized_loanbooks_and_diagnostics_group_id
-├── prioritized_loanbooks_and_diagnostics_net_zero_pledge
-├── analysis_group_id
-└── analysis_net_zero_pledge
-

We can now check if:

-
    -
  • We see any significant differences in net alignment in any of the -PACTA sectors between banks that have made a net zero pledge and those -that have not. We inspect the charts in -../analysis_net_zero_pledge/aggregate/plot_scatter_alignment_exposure_*.png -to see the distribution of the net alignment metric by financial -exposure for each of the sectors and each group. This will help us -identify if there are any sectors that are especially misaligned for -banks that have made a net zero pledge.
    • -
  • If we see any patterns that warrant a deeper analysis, we can use -the bank level analysis to identify which banks seem to be the driver of -the difference in net alignment between banks that have made a net zero -pledge and those that have not. We will need to check in the raw data, -which banks have signed up, as the results for banks do not indicate -this information automatically, since you can only group results by one -variable at a time.
    • -
  • One way to circumvent this slighlty cumbersome process would be to -create a combined variable in the loan books, that includes information -on both the bank and the net zero pledge. This would allow getting the -required information in one run.
    • -
  • Any bank that we identify that has made a net zero pledge but is -strongly misaligned may be at risk of losing reputation and/or being -sued over noncompliance with its pledge. Of course, misalignment is -rarely ever a sufficient criterion to judge if reputational damage or -legal risk is likely to materialize. Other factors, such as progress -made in past efforts, implementation of transition plans, lending -strategy with regard to transition finance, etc. should be considered -too. But strong misalignment should be considered a warning signal, that -warrants further investigation into these other aspects and possibly a -dialogue with the affected bank.
    • -
-

PREVIOUS CHAPTER: Interpretation of Results

-
-
-
-
- - - -
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
- -

© RMI

- -
-
-
-
-
-
-
- - - - - - - - - - - diff --git a/pr-preview/pr-358/articles/cookbook_interpretation.html b/pr-preview/pr-358/articles/cookbook_interpretation.html deleted file mode 100644 index 9de37866..00000000 --- a/pr-preview/pr-358/articles/cookbook_interpretation.html +++ /dev/null @@ -1,1260 +0,0 @@ - - - - - - - -Interpretation of Results • pacta.multi.loanbook - - - - - - - - - - - - - - - Skip to contents - - -
- - - - -
-
-

Interpretation of Results

- - - Source: vignettes/cookbook_interpretation.Rmd -
cookbook_interpretation.Rmd
-
- - - -
-

Interpretation of Results -

-

Running the analysis will produce a number of outputs that can be -used to gain insights into the alignment of financial institutions with -climate transition scenarios and to approximate transition risk. The two -main pieces of the analysis are the PACTA for Banks analysis and the net -aggregate alignment metric. The PACTA for Banks analysis will provide -insights into the alignment of the financial institution with the -climate transition scenarios for each of the sectors covered by PACTA. -The net aggregate alignment metric is intended be used as a high level -overview alignment metric for the financial sector. The analyses thus -complement each other where the net aggregate alignment metric can serve -as a starting point to identify sectors or groups of financial -institutions that seem to require particular attention. The PACTA for -Banks analysis can then be used to drill down into the details of the -alignment of the financial institution with the climate transition -scenarios.

-

The following sections will provide an overview of results that are -generated using this analysis and how to interpret them. It will briefly -explain each of the relevant metrics, it will mention the plots that -correspond to the metrics, and it will explain how the output data sets -map to the values shown in the plots. The same will be provided for the -coverage statistics that are generated for the analysis.

-
-

Coverage Diagnostics -

-

The coverage diagnostics include both a comparison of the number and -value of matched loan books with the raw loan books and a comparison of -the production capacity of companies in the matched loan books with the -production capacity of companies in the wider economy. The coverage -diagnostics are intended to provide insights into the quality of the -matching process and the coverage of the loan books in the analysis.

-
-

Match Success Rate -

-

The match success rate is calculated per sector and can be calculated -based on either of the number of loans, the outstanding value of the -loans, or the credit limit of the loans. In either case, the sum value -of the matched loans is compared with that of the raw loan books.

-

The output data set contains all three versions of the metric and can -be found in the -../prioritized_loanbooks_and_diagnostics/lbk_match_success_rate<...>.csv -file, where <…> will be replaced with the name of the variable set -in the by_group parameter.

-
-
Example Plots Match Success Rate -
-

An example plot of the match success rate for the number of loans, in -this case grouped by banks types (credit unions, less significant -institutions and significant institutions), can look as follows:

-
-Fig. 2: Relative match success rate in number of loans by different bank types. Data is based on simulated test loan books.

-Fig. 2: Relative match success rate in number of loans by different bank -types. Data is based on simulated test loan books. -

-
-
-Fig. 3: Absolute match success rate in number of loans by different bank types. Data is based on simulated test loan books.

-Fig. 3: Absolute match success rate in number of loans by different bank -types. Data is based on simulated test loan books. -

-
-

Another example plot of the match success rate for the loan size -outstanding, in this case an ungrouped meta view on the entire set of -analyzed loan books, might look like this:

-
-Fig. 4: Relative match success rate in number of loans aggregated over all loan books. Data is based on simulated test loan books.

-Fig. 4: Relative match success rate in number of loans aggregated over -all loan books. Data is based on simulated test loan books. -

-
-
-Fig. 5: Absolute match success rate in number of loans aggregated over all loan books. Data is based on simulated test loan books.

-Fig. 5: Absolute match success rate in number of loans aggregated over -all loan books. Data is based on simulated test loan books. -

-
-
-
-
Interpretation of the Match Success Rate -
-

The match success rate is a coverage metric of properly identified -loans relative to the raw input loan books. It is always provided by -sector, because a company in the loan book can only be expected to be -matched to the ABCD if it operates in the same sector. Since PACTA only -covers a subset of economic sectors, judging the success of the matching -process should only take into account the loans that fall within the -scope of the PACTA analysis. Of course, the extent of exposure to these -sectors may vary significantly between input loan books. But this has -more to do with the strategy of the bank than with the quality of the -matching process.

-

Generally, it is desirable to reach as high a match success rate as -possible for each sector. It was mentioned before that the time spent to -maximize the match success rate is at the discretion of the user. -However, it is recommended to aim for a match success rate of more than -80% of the loan value within each sector that you are interested in. The -steps to achieve this are described in the section -on the matching process.

-

If after following and concluding the matching procedure the match -success rate is high for a given sector or the entire loan book, this -indicates that you can draw conclusions from the PACTA analysis for the -loan books with higher confidence. If it remains low for some sectors, -this can point to one of several issues:

-
    -
  • There may be data quality issues in the raw loan book. For example, -the company names may have been entered wrongly, or the sector -classification may be incorrect. Problems with the sector classification -may be corrected to some degree through desk research. However, there -are limits to inferring sector codes like that and it is a time -consuming process.
    • -
  • There may be coverage issues in the ABCD. It is possible that all -entries in the raw loan book are correct and the match success rate -remains low, because the companies the loan book is exposed to are not -covered in the ABCD. Since the ABCD is an externally sourced data set, -there are two main approaches to tackling this. One is to reach out to -the data provider and try to understand/add the missing data points. The -other is to try and add the relevant data points manually based on your -own data or research. This is a very involved process and not standard -procedure and will therefore not be covered in this cookbook. Beyond -those options, it is recommended to highlight coverage issues, if they -cannot be fixed.
    • -
-
-
-
Mapping the Data Dictionary to the Match Success Rate Plots -
-

For detailed descriptions of the columns in the corresponding output -files, please refer to the relevant -section on the match success rate in the data dictionary.

-

The variables in the table map to the figures as follows:

-
    -
  • -<by_group>: The variable that the loan books are -split by. This determines the number of panes in the plot. E.g. in -figures 2 and 3, the loan books are split by bank type, generating one -pane per type. In figures 4 and 5, the loan books are not split by any -variable, generating a single pane for the entire set of loan -books.
    • -
  • -sector: The match success rate is analysed by sector, -with the sectors shown in separate columns. This is because a loan in -the raw loan book can only be matched to the ABCD if the company -operates in the sector covered by the ABCD. This highlights the -importance of good data quality in the sector classification of the raw -loan book. The target should be to have a sufficiently high match -success rate for any sector that you want to make robust statements -about.
    • -
  • -match_n: When showing the absolute number of loans -matched (figure 3), this determines the size of the matched part of each -column.
    • -
  • -total_n: When showing the absolute number of loans -matched (figure 3), this determines the total size (matched + unmatched) -of each column.
    • -
  • -match_success_rate_rel: When showing the relative -number of loans matched (figure 2), this determines the size of the -matched part of each column.
    • -
  • -match_outstanding: When showing the absolute matched -value of loans outstanding (figure 5), this determines the size of the -matched part of each column.
    • -
  • -total_outstanding: When showing the absolute matched -value of loans outstanding (figure 5), this determines the total size -(matched + unmatched) of each column.
    • -
  • -match_success_outstanding_rel: When showing the -relative matched value of loans outstanding (figure 4), this determines -the size of the matched part of each column.
    • -
  • -match_credit_limit: When showing the absolute matched -credit limit of loans (not shown in figure), this determines the size of -the matched part of each column.
    • -
  • -total_credit_limit: When showing the absolute matched -credit limit of loans (not shown in figure), this determines the total -size (matched + unmatched) of each column.
    • -
  • -match_success_credit_limit_rel: When showing the -relative matched credit limit of loans (not shown in figure), this -determines the size of the matched part of each column.
    • -
-
-
-
-

Loan Book Production Coverage -

-

The loan book production coverage is calculated per sector and region -(for all regions available in the given scenario_source). -For a given combination of sector and region, it provides the total -number of companies with operations in the sector and region in the -wider economy. It then provides the number of matched companies in the -loan book with operations in that sector and region. A ratio of the two -values tells you the share of companies in the sector and region that -you have identified in the matched loan book. Similarly, the data set -provides the total production capacity of a sector in a region in the -wider economy and the production by companies in the matched loan book -in that sector and region. Notice that it only matters THAT the company -was matched in the loan book, NOT how large the granted loan is. The -ratio of the two values then tells us what percentage of the production -capacity of a sector in a region the financial institution is involved -in. Again, being involved in that production capacity is decidedly not a -full responsibility, because many matched companies will likely have -additional sources of funding. Lastly, the output provides the sum of -the loan size outstanding to the matched companies in each of the -sectors and regions.

-

The output data set can be found in the -../prioritized_loanbooks_and_diagnostics/summary_statistics_loanbook_coverage<...>.csv -file, where <…> will be replaced with the name of the variable set -in the by_group parameter.

-
-
Interpretation of the Loan Book Production Coverage -
-

The loan book production coverage is a coverage metric of the -production capacity of companies in the loan book relative to the -production capacity of companies in the wider economy. It is always -provided by sector and region. Comparisons across sectors need to be -separate, because of differing output units. And the coverage by region -allows highlighting the regional focus of a bank for the given sector. -The production coverage compares matched companies only, hence it -depends on the quality of the matching process and any statements about -the share of economic activity covered by the matched loan book should -take this relationship into account.

-

Assuming a solid match success rate, the loan book production -coverage tells you if the loan book is exposed to a large share of -production capacity within a certain sector and region. This information -can be relevant when assessing the impact of regional economic trends -and policies that may affect the sector. For example, the loan book more -susceptible to transition risk in one region than in another even when -the introduced policies are very similar, because companies financed may -operate a larger share of the production capacity in the first -region.

-
-
-
Data Dictionary Loan Book Production Coverage -
-

For detailed descriptions of the columns in the output files, please -refer to the relevant -section on the loan book coverage in the data dictionary.

-

There is currently no standard plot that this package provides for -visualizing the loan book production coverage.

-
-
-
-
-

PACTA for Banks Outputs and Graphs -

-

Below you will find a description of the standard PACTA for Banks -data outputs and graphs. Some of the data outputs are intermediate files -that do not directly map to a plot. These are only mentioned briefly. A -detailed description can be found in the -vignette("data_dicationary"). The plots are discussed in -more detail, including the relevant table from the data dictionary and -how the variables map to the plots.

-
-

Target Market Share Results -

-

The target market share results provide the intermediate format -output required to generate the technology mix and volume trajectory -plots. The output data set can be found in the -../analysis/standard/tms_results<...>.csv file, where -<…> will be replaced with the name of the variable set in the -by_group parameter.

-

More information on the target market share results data set can be -found in the data -dictionary.

-
-
-

Technology Mix -

-

The technology mix metric compares the technology mix of the -production capacity of companies in the loan book with that of the -production capacity of companies in the wider economy and the scenario -technology mix five years into the future. The output data set can be -found in the -../analysis/standard/<...>/data_tech_mix_<sector>.csv -file, where <…> will be replaced with the names of each of the -groups in the variable set in the by_group parameter. This -means that the technology mix results always only show results for one -group at a time.

-

The technology mix can only be calculated for sectors that have -technology level scenario pathways. Generally, those tend to be sectors -for which scalable low carbon alternatives exist. The technology mix can -also be calculated for sectors in which all technologies are projected -to phase down or out, but the results are less meaningful in those -cases, as the technology mix cannot show the absolute requirements for a -phasedown.

-

For a general explanation of the technology mix, see also the PACTA for Investors -website under the “Metrics” tab.

-
-
Example Plots Technology Mix -
-

This plot shows the technology mix for the automotive sector of a -loan book. We can see that the exposure to automotive production of -different engine types in the loan book shifts from 2022 to 2027. The -exposure to electric vehicle production increases, while the exposure to -internal combustion engine production decreases. A similar shift can be -observed in the wider economy, although the shift starts from a smaller -share in 2022, which implies the companies that are being financed have -a relatively strong focus on electric vehicle production compared to the -overall economy. We can also see what the technology mix looks like for -the scenario in 2027. In this case, the shift of automotive production -from internal combustion engines to electric vehicles in the portfolio -exposure is not as strong as it ought to be to be in line with the -scenario.

-
-Fig. 6: Technology mix for the automotive sector of a loan book. Data is based on simulated test loan books.

-Fig. 6: Technology mix for the automotive sector of a loan book. Data is -based on simulated test loan books. -

-
-

In another example of the technology mix plot for the power sector, -we can again see a loan book that is exposed to a much higher share of -low carbon technologies than the wider economy, mainly due to the large -exposure to companies operating renewable energy power. The plot shows -only a marginal shift for the loan book between 2022 and 2027, which -means that the share of technologies does not quite align with the -scenario values in 2027. However, we can again see that the loan book as -far ahead of the wider economy in terms of low carbon technology -exposure in the power sector, with nuclear power being the only notable -exception of smaller exposure in the loan book.

-
-Fig. 7: Technology mix for the power generation sector of a loan book. Data is based on simulated test loan books.

-Fig. 7: Technology mix for the power generation sector of a loan book. -Data is based on simulated test loan books. -

-
-
-
-
Interpretation of the Technology Mix Plots -
-

The technology mix plots show the exposure to underlying technologies -by sector, where the technology mix of the financed companies is -combined using the portfolio weight of each loan to generate the -aggregate technology mix at the loan book level. This means that a -technology mix at the company level reflects the underlying production -of the company in terms of real economic output units, whereas the -technology mix at the loan book level reflects the financial exposure of -the bank to these technologies through its lending activities. As such, -the overall size of the production activities of the underlying -companies does not impact the technology mix of the loan book. It is a -weighted average of relative production numbers. The technology mix at -the loan book level therefore works better as a risk indicator than as a -measure of impact.

-

For the corporate economy bars, the technology mix is based on the -unweighted sum of underlying physical production capacity and for the -scenario bar, the technology mix is based on the initial technology mix -of the portfolio, extrapolated with required changes based on the market -share approach that assumes all companies maintain their overall -production shares in the sector.

-
-
-
Mapping the Data Dictionary to the Technology Mix Plots -
-

For detailed descriptions of the columns in the output files, please -refer to the relevant -section on the technology mix in the data dictionary.

-

The variables in the table map to the figures as follows:

-
    -
  • -<by_group>: The variable that the loan books are -split by. This determines the group for which the tech mix is shown. -E.g. in case the aggregate loan book is displayed as in figures 6 and 7, -the variable and value will be “meta”. If the calculation had been -grouped by bank_type, the resulting plots would have been -returned for groups, such as credit unions, less significant -institutions and significant institutions.
    • -
  • -sector: The PACTA sector that the technology mix is -shown for.
    • -
  • -technology/label_tech: The technology -represents the differences in product or fuel type (depending on the -sector). Generally, some of the technologies within a sector are -considered low carbon technologies and others are considered high carbon -technologies. The technology mix shows the current distribution across -these technologies and how that distribution may change. The -label_tech is the same as the technology, but -with a more human readable name to be displayed in the plot.
    • -
  • -year: The technology mix chart uses values from the -start year of the analysis and contrasts them with values from the end -year of the analysis, usually five years into the future.
    • -
  • -metric/label: The metric differentiates -the types of bars shown in the technology mix plot. -projected refers to the technology mix of the exposures in -the loan book, corporate_economy represents the production -technology mix of the real economy for the selected region and -target_<scenario> refers to the technology mix the -loan book would need to achieve five years into the future in order to -be aligned with the scenario based on the market share approach. -<scenario> stands for the selected target scenario as -set in the config.yml file. The label is the -same as the metric, but with a more human readable name to -be displayed in the plot.
    • -
  • -technology_share/value: The actual value -that determines the size of each of the technologies in the bars of the -plot. The technology_share is the share of the technology -in the total production capacity of the sector in the region. The -value is the same as the technology_share, but -formatted for display in the plot.
    • -
-
-
-
-

Production Volume Trajectory -

-

The production volume trajectory metric compares the future -production capacity in a given technology of the companies in the loan -book with that of the companies in the wider economy and the scenario -trajectories for the loan book five years into the future, based on the -market share approach. The output data set can be found in the -../analysis/standard/<...>/data_trajectory_<sector>_<technology>.csv -file, where <…> will be replaced with the names of each of the -groups in the variable set in the by_group parameter. This -means that the production volume trajectory results always only show -results for one group at a time.

-

The production volume trajectory metric can only be calculated for -sectors that have technology level scenario pathways. Generally, those -tend to be sectors for which scalable low carbon alternatives exist, or -sectors in which all technologies are projected to phase down or -out.

-

For a general explanation of the production volume trajectory, see -also the PACTA for -Investors website under the “Metrics” tab.

-
-
Example Plots Production Volume Trajectory -
-

In this example of the volume trajectory plot for electric vehicle -production in the automotive sector, we can see that the exposure to -electric vehicle production in the loan book is projected to increase -from 2022 to 2027. Electric vehicle production in the real economy is -projected to increase as well, but at a slower pace. The scenario -trajectories for the IEA NZE by 2050 and IEA APS for the portfolio are -also shown, based on the market share approach. The projection of the -portfolio falls between the APS and the NZE by 2050 trajectories.

-
-Fig. 8: Volume trajectory plot for electric vehicle production in the automotive sector of a loan book. Data is based on simulated test loan books.

-Fig. 8: Volume trajectory plot for electric vehicle production in the -automotive sector of a loan book. Data is based on simulated test loan -books. -

-
-

In another example of the production volume trajectory plot for the -coal mining sector, we can see a loan book that reduces its exposed to -coal mining activity over the time frame of the analysis. The real -economy does so too, but again a t a slower pace. The scenario -trajectories for the loan book based on the market share approach are -plotted for the IEA STEPS, the IEA APS, and the IEA NZE by 2050 -scenarios. The trend of the loan book projection follows the APS -trajectory relatively closely over the examined time frame.

-
-Fig. 9: Volume trajectory plot for for coal mining (technology and sector) of a loan book. Data is based on simulated test loan books.

-Fig. 9: Volume trajectory plot for for coal mining (technology and -sector) of a loan book. Data is based on simulated test loan books. -

-
-
-
-
Interpretation of the Production Volume Trajectory Plots -
-

The production volume trajectory plots show the exposure of the loan -book to production capacity trends of the financed companies for a given -technology over the next five years, showing changes in percent relative -to the start year. It contrasts this trend with the production trend of -the real economy and with the trajectories that the loan book would have -to finance in order to be aligned with scenarios based on the market -share approach. The shading of the graph represents the direction of the -required changes based on the scenario. If the green area is at the top -of the graph, the technology needs to increase over time to align with -the scenario. If the red area is at the top of the graph, the technology -needs to decrease over time to align with the scenario. The required -rates of change that apply for the individual loan book are determined -using the market share approach, using the target market share ratio -(TMSR) for high-carbon technologies and the sector market share -percentage (SMSP) for low-carbon technologies. If the projected -production trend of the loan book is equal or greater than the highest -scenario line for an increasing technology, the loan book is aligned -with the most ambitious scenario for that technology.

-

If it is below that scenario line, the loan book is misalgined with -the most ambitious scenario for that technology. It may still be aligned -with a less ambitious scenario. Likewise, if the projected production -trend of the loan book is equal or lower than the lowest scenario line -for a decreasing technology, the loan book is aligned with the most -ambitious scenario for that technology. If it is above that scenario -line, the loan book is misaligned with the most ambitious scenario for -that technology. It may still be aligned with a less ambitious -scenario.

-

For more information on how to calculate the TMSR and the SMSP, see -the PACTA -for Banks documentation.

-

Also notice that alignment for one technology of a sector does not -imply alignment of the entire sector. For example, building out electric -vehicle production capacity in line with the IEA NZE by 2050 scenario -does not say anything about the alignment of internal combustion engine -production capacity. If ICE production does not decrease sufficiently -fast, the sector as a whole will not be aligned. This would show both in -the technology mix chart, where the slow decrease in ICE production -would depress the share of EV production and in the production volume -trajectory for the ICE production capacity.

-
-
-
Mapping the Data Dictionary to the Production Volume Trajectory -Plots -
-

For detailed descriptions of the columns in the output files, please -refer to the relevant -section on the production volume trajectory in the data -dictionary.

-

The variables in the table map to the figures as follows:

-
    -
  • -<by_group>: The variable that the loan books are -split by. This determines the group for which the production volume -trajectory is shown. E.g. in case the aggregate loan book is displayed -as in figures 8 and 9, the variable and value will be “meta”. If the -calculation had been grouped by bank_type, the resulting -plots would have been returned for groups, such as credit unions, less -significant institutions and significant institutions.
    • -
  • -sector: The PACTA sector that the production volume -trajectory is shown for.
    • -
  • -technology: The technology within the -sector that the production volume trajectory is shown -for.
    • -
  • -year: The production volume trajectory displays annual -rates of change of production volume relative to the start year, with -the x-axis showing the years of the analysis.
    • -
  • -scenario_source: The scenario source that the -production volume trajectory is shown for. This is the source set in the -config.yml file. The scenario source determines the -scenarios that are shown in the plot. Generally all scenarios available -for the sector and technology are shown and -they are represented by the lines that delineate the colored areas in -the plot.
    • -
  • -metric/label: The metric differentiates -the types of lines shown in the production volume trajectory plot. -projected refers to the production volume trajectory of the -exposures in the loan book, corporate_economy represents -the production volume trajectory of the real economy for the selected -region and target_<scenario> refers to the production -volume trajectory the loan book would need to achieve five years into -the future in order to be aligned with the scenario based on the market -share approach. <scenario> will take all values of -scenarios that are available for the sector and -technology in the scenario_ _source. The -label is the same as the metric, but with a -more human readable name to be displayed in the plot.
    • -
  • -percentage_of_initial_production_by_scope/value: -The actual value that determines the direction of the lines. The -percentage_of_initial_production_by_scope is the percentage -of the initial production volume that the production volume in the -future represents. Hence, a positive value implies a build out of the -underlying production capacity and a negative value stands for a -decrease of production capacity. The value is the same as -the percentage_of_initial_production_by_scope, but -formatted for display in the plot.
    • -
-
-
-
-

Sectoral Decarbonization Approach Results -

-

The sectoral decarbonization approach (SDA) results provide the -intermediate format output required to generate the emission intensity -plot. The output data set can be found in the -../analysis/standard/sda_results<...>.csv file, where -<…> will be replaced with the name of the variable set in the -by_group parameter.

-

More information on the SDA results data set can be found in the data -dictionary.

-
-
-

Emission Intensity Pathway -

-

The emission intensity metric compares the future emission intensity -per real economic output unit in a given sector of the companies in the -loan book with that of the companies in the wider economy and the -scenario trajectories for the loan book five years into the future, -based on the SDA approach. The output data set can be found in the -../analysis/standard/<...>/data_emission_intensity_<sector>.csv -file, where <…> will be replaced with the names of each of the -groups in the variable set in the by_group parameter. This -means that the emission intensity results always only show results for -one group at a time.

-

The emission intensity metric can be calculated for any sector that -has sector level physical emission intensity pathways, defined as -absolute emissions divided by absolute real economic output. This is -usually available for a broader range of sectors than technology level -pathways, including for the so called hard-to-abate sectors, where low -carbon alternatives to the most commonly used production technologies -are often not available yet, or at least not market ready.

-

As the emission intensity metric is compared to scenario values based -on the SDA approach, the calculation of the scenario values for each -portfolio follows different rules than the market share approach used in -the technology mix and the production volume trajectory. The SDA -approach is a convergence approach and does not necessarily require -stable market share for all companies and/or loan books. Rather, it -requires that all participants in a sector approach the same emission -intensity target at the end year of the scenario. Notice that the end -year of the scenario is usually much farther in the future than the five -year forward looking horizon of the analysis, which is why the loan book -value is not expected to have converged with the scenario value after -five years.

-

For a general explanation of the emission intensity metric, see also -the PACTA for -Investors website under the “Metrics” tab.

-
-
Example Plots Emission Intensity Pathway -
-

This example of the emission intensity pathway plot for cement -production shows that the emission intensity of the companies the loan -book is exposed to remain relatively stable at a higher level than that -of the wider economy over the next five years. It also shows that both -the target for the loan book based on the IEA NZE by 2050 scenario and -the adjusted target for the wider economy based on the same scenario -decrease over that time frame. The specific pathways of both these -scenario trajectories converge in the end year of the scenario -calculation - in this case 2050 - because they were calculated using a -convergence approach, the SDA approach.

-
-Fig. 10: Emission intensity pathway plot for cement production of companies in the loan book. Data is based on simulated test loan books.

-Fig. 10: Emission intensity pathway plot for cement production of -companies in the loan book. Data is based on simulated test loan books. -

-
-

In another example of the emission intensity pathway plot for the -steel sector, we can see a loan book with an emission intensity based on -its steel company exposure that is below the emission intensity of the -real economy. Again, the trend of the emission intensity for both the -companies in the loan book as well as the wider economy is rather stable -and both would need to decrease over the next five years in order to be -aligned with their respective scenario pathways, based on the SDA -approach. This also again implies that the target scenario pathway of -the loan book and the corporate economy converge in the end year of the -scenario calculation.

-
-Fig. 11: Emission intensity pathway plot for steel production of companies in the loan book. Data is based on simulated test loan books.

-Fig. 11: Emission intensity pathway plot for steel production of -companies in the loan book. Data is based on simulated test loan books. -

-
-
-
-
Interpretation of the Emission Intensity Pathway Plots -
-

The emission intensity pathway plots show the physical emission -intensity trajectory of the portfolio weighted companies that the loan -book is exposed to and contrast this with the physical emission -intensity pathway of all companies in the relevant region of the real -economy. Physical emission intensity in this case refers to the amount -of CO2(eq) emissions per unit of real economic output from the sector at -hand. Since the units of output are interchangeable per sector, but not -across sectors, the physical emission intensity is a useful sector level -metric. Since the emission intensity metric does not require technology -level production pathways to be available, it can be used for sectors -that do now have market-ready low carbon alternatives to replace -high-carbon technologies yet. For the PACTA sectors, this is the case -for the hard-to-abate sectors, such as cement, steel, and aviation. It -can be applied to all other PACTA sectors as well though, although it -may not be equally meaningful in all cases (for example, for a phaseout -of coal mining, the emission intensity of coal mining may not be the -most actionable metric).

-

The emission intensity of different loan books will vary within the -same sector, depending on the companies that the loan books are exposed -to. Accordingly, the effort required by each of the banks to align their -loan books with the target scenario in that sector will differ as well. -With the SDA approach being a convergence approach, any loan book with a -higher than average emission intensity will be expected to follow a -steeper decline in emission intensity than a loan book with a lower than -average emission intensity. This is a necessary requirement of the -convergence approach to scenario allocation. However, the initial level -of the physical emission intensity of the loan book does not impact the -alignment of the loan book. Whether or not alignment is achieved, -depends solely on the rate of change of the emission intensity relative -to the loan book specific decarbonization pathway.

-

For more information on how to calculate the SDA, see the PACTA -for Banks documentation.

-
-
-
Mapping the Data Dictionary to the Emission Intensity Pathway -Plots -
-

For detailed descriptions of the columns in the output files, please -refer to the relevant -section on the emission intensity pathway in the data -dictionary.

-

The variables in the table map to the figures as follows:

-
    -
  • -<by_group>: The variable that the loan books are -split by. This determines the group for which the emission intensity -pathway is shown. E.g. in case the aggregate loan book is displayed as -in figures 10 and 11, the variable and value will be “meta”. If the -calculation had been grouped by bank_type, the resulting -plots would have been returned for groups, such as credit unions, less -significant institutions and significant institutions.
    • -
  • -sector: The PACTA sector that the emission intensity -pathway is shown for.
    • -
  • -year: The emission intensity pathway displays annual -physical emission intensities, with the x-axis showing the years of the -analysis.
    • -
  • -scenario_source: The scenario source that the emission -intensity pathway is shown for. This is the source set in the -config.yml file.
    • -
  • -emission_factor_metric/label: The metric -differentiates the types of lines shown in the emission intensity -pathway plot. projected refers to the emission intensity of -the loan book based on its exposures to the underlying companies, -corporate_economy represents the emission intensity of the -companies in the real economy, target_<scenario> -refers to the emission intensity pathway the loan book would need to -follow to remain aligned with the scenario based on the SDA approach, -and adjusted_scenario_<scenario> is the emission -intensity pathway the corporate economy in the sector would need to -follow to remain aligned. <scenario> stands for the -selected target scenario as set in the config.yml file. The -label is the same as the -emission_factor_metric, but with a more human readable name -to be displayed in the plot.
    • -
  • -emission_factor_value: The actual value that determines -the points that the emission intensity lines follow in the plot. The -emission_factor_value is the ratio of emissions per real -economic output unit.
    • -
-
-
-
-
-

Net Aggregate Alignment Metric Outputs and Graphs -

-

This section provides a description of the data outputs and graphs -related to the Net Aggregate Alignment Metrics. Some of the data outputs -are intermediate files that do not directly map to a plot. Such outputs -are explained in detail in the vignette("data_dictionary"). -The plots are discussed in more detail, including the relevant table -from the data dictionary and how the variables map to the plots.

-

Please note that all plots in this section build on the Net Aggregate -Alignment Metric, which is an aggregation of PACTA results for every -sector that allows for a high level overview of sector alignment at the -loan book level or higher. An intended use case is to use this metric -first at the aggregate financial system level across all loan books and -then drill down along different dimensions of interest. The idea behind -this approach is to facilitate the comparison of many different banks -and loan books using forward-looking production based alignment metrics -without producing an excessive amount of plots and results that becomes -hard to navigate and that may not reveal higher level patterns easily. -The Net Aggregate Alignment Metric was first developed in the ECB -Banking Supervision paper “Risks -from misalignment of banks’ financing with the EU climate objectives - -Assessment of the alignment of the European banking sector”. For a -detailed description of the methodology used in this implementation of -the Net Aggregate Alignment Metric, see the two-part documentation of -the metric, focusing on the starting with the company -level calculation of the net alignment metric and proceeding with -the approach to aggregating -the net alignment metric to the loan book level.

-
-

Net Aggregate Alignment Metric - Sankey Plot -

-

The net aggregate alignment sankey plot summarizes the financial -exposure of a (grouped or ungrouped) loan book (left node) by financial -exposure to PACTA sectors (middle node) and finally by whether or not -the exposures are aligned based on the net aggregate alignment metric -(right node). Alignment is defined as a binary variable, where any -underlying exposure with an alignment metric greater or equal to 0 is -considered aligned and any exposure with an alignment metric less than 0 -is considered misaligned. The main purpose of this type of visualization -is to provide an overview of system level alignment at one quick glance, -at the expense of some detail that can be obtained from other plots. The -output data set can be found in the -../analysis/aggregated/data_sankey_sector<...>.csv -file, where <…> will be replaced with the names of each of the -groups in the variable set in the by_group parameter.

-
-
Example Plots Net Aggregate Alignment Metric - Sankey Plot -
-

This example of the sankey plot looks at the aggregate financial -exposure of all analyzed loan books (figure 12, left node). The middle -node shows that a large share of the financial exposure can be found the -in the power sector, with the automotive and oil & gas sectors also -contributing significant chunks. Cement, coal and steel contribute minor -parts to the overall financial exposure. The right node, in turn, shows -how the sector exposure is distributed with regard to a binary alignment -metric, based on the net aggregate alignment metric. Overall, green -ribbons indicate the size of the aligned exposure, while red ribbons -indicate the size of the misaligned exposure. We can see that aligned -exposures make up a much smaller share of the overall exposure than -misaligned exposures. The distribution of alignment/misalignment -furthermore varies significantly between sectors, with half the exposure -value in the oil & gas sector aligned, a much higher share than in -any other of the sectors. The nature of this plot as a high level -overview means that it does not show all the details. For example, the -underlying companies are classified as aligned or misaligned in a binary -manner. The net aggregate alignment metric is a continuous variable -though, so the binary representation may skew the extent of alignment to -some degree and should always be complemented with additional analyses -from the following plots.

-
-Fig. 12: Sankey plot of the aggregated loan books by sector and by net aggregate alignment metric. Data is based on simulated test loan books.

-Fig. 12: Sankey plot of the aggregated loan books by sector and by net -aggregate alignment metric. Data is based on simulated test loan books. -

-
-
-
-
Interpretation of the Sankey Plot -
-

The sankey plot emphasizes the distribution of the financial exposure -of the analyzed loan books across sectors and aligned or misaligned -counterparties. The plot necessitate categorical variables for the types -of nodes, which means that the net aggregate alignment metric is -transformed into a binary variable. The size of each group in a node -along the y axis is the financial exposure to that group and that is the -only continuous variable in this plot. In effect, the statements you can -make based on this plot are along the lines of “XY USD of the financial -exposure of the loan books is concentrated in the power sector. Among -the exposure to power companies, the largest share goes to companies -that are misaligned with the selected scenario”. As we can see, this -reveals more about how much money is lent to how many companies that are -misaligned in some form. It says nothing about how misaligned these -companies are. They might all be very close to, but just behind, the -scenario target. Or they might all be grossly off target. The reason why -this is still a useful plot is because you get a very quick over view, -in which sectors are the largest shares of your misaligned companies. -This makes it easier to prioritize which company analytics to look at -first. Additionally, you can validate the severity of the misalignment -in a given sector, by inspecting the alignment-by-exposure plots, which -will be explained next.

-
-
-
Mapping the Data Dictionary to the Sankey Plot -
-

For detailed descriptions of the columns in the output files, please -refer to the relevant -section on the sankey plot in the data dictionary.

-

The variables in the table map to the figures as follows:

-
    -
  • -<by_group>: The variable that the loan books are -split by. This corresponds to the leftmost node in the sankey plot and -the values can either be all the same for the aggregate view on all -analysed loan books or the values corresponding to each of the -groups.
    • -
  • -middle_node: The PACTA sectors for which there is some -financial exposure in the analyzed loan books.
    • -
  • -is_aligned: Binary variable that can have values -“aligned” or “not aligned”. All exposures that are aligned are -represented as green ribbons, all those that are not aligned are red -ribbons. The underlying net alignment metric refers to the five year -forward-looking values in the final year of the analysis.
    • -
  • -loan_size_outstanding: The financial exposure of the -loan books to the individual sectors and grouped by -ìs_aligned. This is the continuous variable that determines -the size of the ribbons in the plot along the y-axis.
    • -
-
-
-
-

Net Aggregate Alignment by Financial Exposure -

-

The net aggregate alignment by financial exposure plot summarizes the -net aggregate alignment metric (y-axis) of a (grouped or ungrouped) loan -book (dot color) by financial exposure to PACTA sectors (x-axis). Every -sector is shown in a separate pane with equal scales, which allows -comparing the significance of exposures across sectors. In this plot, -the net aggregate alignment metric is presented as a continuous variable -along the y axis, which allows for more nuance compared with the sankey -plot. Exposures to very misaligned companies will influence the loan -book level alignment more negatively here, because the loan book level -net aggregate alignment metric is a weighted mean of the underlying -continuous company level net aggregate alignments weighted by the -financial exposure. However, this additional detail makes the plot -slightly slower to read than the sankey plot. Generally, this plot -emphasizes the scale of the net aggregate alignment more than the -exposure and is therefore a good complementary plot to the sankey plot. -The output data set can be found in the -../analysis/aggregated/data_scatter_alignment_exposure<...>.csv -file, where <…> will be replaced with the names of each of the -groups in the variable set in the by_group parameter.

-
-
Example Plots Alignment by Exposure -
-

In this example plot, we analyse the net aggregate alignment by -different bank types across six of the PACTA sectors. We can see that -the exposures of credit unions in the oil & gas sector (misaligned) -and in the power sector (aligned), as well as the exposures of less -significant institutions in the coal sector (misaligned) have very -pronounced net aggregate alignment metrics. This can be a further avenue -for research into which specific companies seem to drive these results. -It is also evident, that this plot does not make it very easy to compare -the financial exposures across sectors, which highlights again one of -the strengths of the sankey plot. Within sector however, financial -exposure between groups can easily be differentiated.

-
-Fig. 13: Alignment by exposure plot of loan books grouped by bank type. Data is based on simulated test loan books.

-Fig. 13: Alignment by exposure plot of loan books grouped by bank type. -Data is based on simulated test loan books. -

-
-
-
-
Interpretation of the Alignment by Exposure Plots -
-

Generally, the alignment by exposure sector is very useful for -interpretations of net alignment within sectors. Groups (e.g. bank -types, but possibly other types of groups) further to the right of the -x-axis have a larger financial exposure to companies in this sector than -other groups. Dots higher on the y-axis indicate groups for which the -loan book level net aggregate alignment is further ahead of the scenario -than for groups with a dot lower on the y-axis. The 0 intercept on the -y-axis means the weighted average net aggregate alignment of the group -is right on target.

-

Of course, since the net aggregate alignment at loan book level is a -weighted average of the underlying company level net aggregate -alignments, a positive y-value does not mean that there are no -misaligned companies to be found in the loan book for this sector. If -individual company level alignment is of concern for your use case, you -will have to check company level results to validate that. The most -comprehensive output data set to inspect company level net alignment -metrics is the -../analysis/aggregated/company_exposure_net_aggregate_alignment<...>.csv -file. Documentation for its contents can be found in the -relevant section of the data dictionary.

-
-
-
Mapping the Data Dictionary to the Alignment by Exposure Plots -
-

For detailed descriptions of the columns in the output files, please -refer to the relevant -section on the alignment-by-exposure scatter plot in the data -dictionary.

-

The variables in the table map to the figures as follows:

-
    -
  • -<by_group>: The variable that the loan books are -split by. This corresponds to differently colored dots in each of the -panes.
    • -
  • -scenario: The name of the scenario against which the -net aggregate alignment is calculated. This is the scenario set in the -config.yml file.
    • -
  • -sector: Each PACTA sector for which there is some -exposure in the analysed loan books is shown in a separate pane.
    • -
  • -year: The net aggregate alignment metric is calculated -for the end year of the analysis, that is, five year -forward-looking.
    • -
  • -exposure_weighted_net_alignment: The y-axis value of -the plot. This is the net aggregate alignment metric for the loan book, -calculated as a weighted average of the underlying company level net -aggregate alignment metrics. The weight is the financial exposure of the -loan book to the companies in the sector.
    • -
  • -sum_loan_size_outstanding: The x-axis value of the -plot. This is the financial exposure of the loan book to the companies -in the sector.
    • -
-
-
-
-

Buildout-Phaseout Scatter Plot for Aggregate Alignment Metric -

-

The net aggregate alignment metric can be disaggregated into build -out and phase out components for some sectors. Specifically those -sectors, that have technology level pathways and both high carbon and -low carbon technologies, can be disaggregated in this way. It may be -insightful to analyze these components to understand better if any -deviations from the scenario value are driven by too much or too little -effort on either of the two sides. For example, in the automotive -sector, this may reveal that almost all of the misalignment is due to a -lack of phasing out high carbon technologies, while low carbon ones may -be aligned in their build out. Similar patterns could be detected in the -power sector. Such patterns can be understood as a prompt, which of the -standard PACTA analyses may be most relevant to inspect for further -drill down. The output data set is available both at the loan book level -to compare the disaggregation by groups and at the company level to -identify individual companies with strong drivers. The loan book level -files can be found in the -../analysis/aggregated/data_scatter_sector<...>.csv -file, where <…> will be replaced with the names of each of the -groups in the variable set in the by_group parameter. The -company level files can be found in the -../analysis/aggregated/<...>/data_scatter_<sector>_company<...>.csv -file.

-
-
Example Plots Buildout-Phaseout Aggregate Alignment -
-

This example plot shows the loan book level build out and phaseout -disaggregation for three bank types. The y-axis shows that all three -bank types have loan books with exposures to misalgined companies in -terms of phaseout technologies. This means that high carbon technology -production capacity is not decreasing fast enough in the loan books to -align with the selected scenario. The build out side (x-axis) of the -plot is more varied, with two of the bank types being aligned in terms -of exposure to build out technologies and one being misaligned. The -color of the dots indicates net alignment (the sum of the build out and -phase out values). Only one of the three bank types has a positive net -aggregate alignment value, which is indicated by the green hue and its -position above the diagonal line. This is a case where the alignment in -build out technologies outweighs the misalignment in phase out -technologies.

-
-Fig. 14: Scatter plot showing the buildout/phaseout disaggregation of the net aggregate alignment metric in the automotive sector by bank type at the loan book level. Data is based on simulated test loan books.

-Fig. 14: Scatter plot showing the buildout/phaseout disaggregation of -the net aggregate alignment metric in the automotive sector by bank type -at the loan book level. Data is based on simulated test loan books. -

-
-

For a deeper dive into the company level disaggregation of the build -out and phase out components, the following plot shows the same -disaggregation for less significant financial institutions at the -company level. The less significant institutions are the most misaligned -dot in the previous loan book level chart. The plot shows that most of -the companies the less significant institutions are exposed to in the -automotive sector are firmly in the area of both misaligned build out -and phase out technologies with only a few company exposures being -closer to any positive alignment components. This means that the -misalignment of the automotive sector for less significant financial -institutions does not appear to be driven by few outliers, but seems to -be rather consistent across exposures.

-
-Fig. 15: Scatter plot showing the buildout/phaseout disaggregation of the net aggregate alignment metric in the automotive sector for less significant fiancial institutions at the company level. Data is based on simulated test loan books.

-Fig. 15: Scatter plot showing the buildout/phaseout disaggregation of -the net aggregate alignment metric in the automotive sector for less -significant fiancial institutions at the company level. Data is based on -simulated test loan books. -

-
-
-
-
Interpretation of the Buildout-Phaseout Scatter Plots for the -Aggregate Alignment Metric -
-

The buildout-phaseout scatter plots show the disaggregation of the -net aggregate alignment metric into build out and phase out components. -The x-axis shows the alignment of the loan book with the build out -technologies of the sector, while the y-axis shows the alignment with -the phase out technologies of the sector. The diagonal line from the top -left to the bottom right of the plot indicates the threshold above which -the sum of the build out and phase out components correspond to a -positive net aggregate alignment value. The color of the dots indicates -the net aggregate alignment of the loan book. Green dots indicate a -positive net aggregate alignment, while red dots indicate a negative net -aggregate alignment. The plot is also available at company level. If -generated for loan books, one dot corresponds to one group of loan -books, e.g. if there are three bank types, the aggregate loan books by -bank types will be represented by three dots. It generated for -companies, one dot corresponds to one company, where only companies are -shown that have any exposure for the given by_group, -e.g. if results are generated for by_group = "bank_type" -and there are three bank types, then we will get three company level -plots, each one containing only dots for companies that the -corresponding bank type has an exposure to. The plot can be used to -identify which of the two components of the net aggregate alignment -metric is driving the alignment or misalignment of the loan book.

-
-
-
Mapping the Data Dictionary to the Buildout-Phaseout Scatter Plot -for the Aggregate Alignment Metric -
-

For detailed descriptions of the columns in the output files, please -refer to the relevant -section on the buildout/phaseout scatter plot in the data -dictionary.

-

The variables in the table map to the figures as follows:

-
    -
  • -name: For loan book level plots: The names of the -groups corresponding to the by_group value. For company -level plots: The names of the companies that have exposures for the -given group result.
    • -
  • -buildout: Net aggregate alignment metric for the build -out component of the loan book or company. Maps to the x-axis. Aligned -loan books or companies have a positive value, misaligned ones have a -negative value.
    • -
  • -phaseout: Net aggregate alignment metric for the phase -out component of the loan book or company. Maps to the y-axis. Aligned -loan books or companies have a positive value, misaligned ones have a -negative value.
    • -
  • -net: The net aggregate alignment metric of the loan -book or company. Maps to the hue of the dot. Aligned loan books or -companies have a positive value (green hue), misaligned ones have a -negative value (red hue).
    • -
  • -datapoint: Indicates if the results are calculated at -loan book or company level.
    • -
-

PREVIOUS CHAPTER: Running the Analysis

-

NEXT CHAPTER: Advanced Use Cases

-
-
-
-
-
-
- - - -
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
- -

© RMI

- -
-
-
-
-
-
-
- - - - - - - - - - - diff --git a/pr-preview/pr-358/articles/cookbook_overview.html b/pr-preview/pr-358/articles/cookbook_overview.html deleted file mode 100644 index 08c9ac61..00000000 --- a/pr-preview/pr-358/articles/cookbook_overview.html +++ /dev/null @@ -1,244 +0,0 @@ - - - - - - - -Overview • pacta.multi.loanbook - - - - - - - - - - - - - - - Skip to contents - - -
- - - - -
-
-

Overview

- - - Source: vignettes/cookbook_overview.Rmd -
cookbook_overview.Rmd
-
- - - -
-

Overview -

-

This cookbook provides a step-by-step guide to running the PACTA for -Supervisors analysis using the pacta.multi.loanbook -package. The analysis is designed to help financial supervisors assess -the alignment of banks’ loan books with the Paris Agreement goals.

-

The sections of the cookbook are as follows:

-
    -
  1. -Overview: This section provides an overview of the -PACTA for Supervisors analysis and its main steps.
    2. -
  2. -Preparatory -Steps: Prepare the ABCD data and optionally a custom sector -split.
    3. -
  3. -Running the -Analysis: Match the raw loan books to the ABCD data and run -the PACTA for Supervisors analysis.
    4. -
  4. -Interpretation of -Results: Interpret the results of the analysis and -understand the outputs.
    5. -
  5. -Advanced -Topics: Learn about advanced topics such as custom grouping -of results and how to adjust the analysis parameters for best results on -advanced research questions.
    6. -
-
-

What is the PACTA for Supervisors analysis? -

-

PACTA for Supervisors is based on the PACTA methodology, which -assesses the alignment of financial portfolios with climate goals -utilizing forward-looking asset-based company data (ABCD) that is linked -to financial assets and compares the production profiles of those -companies with technology and emissions pathways from climate transition -scenarios at the sector and/or technology level.

-
-
-

Who is this tool built for? -

-

The PACTA for Supervisors analysis is primarily designed to be run by -financial supervisors on their own, with minimal additional guidance. -However, it can also be a useful tool for any other user, in case they -would like to run a PACTA analysis on multiple loan books.

-

The main difference between this tool and the individual PACTA for -Banks software packages is that this tool aims to facilitate the -analysis of multiple loan books at once, streamlining the process as -much as possible, to keep the burden for the user to a minimum. As such -it is a helpful tool for anyone who would like to run a PACTA analysis -on multiple loan books.

-
-
-

What can the results of the PACTA for Supervisors analysis be used -for? -

-

Financial supervisors or regulators can use the results of the -analysis to assess the alignment of banks’ loan books with the Paris -Agreement goals, to identify sectors where banks may need to take action -to improve alignment, and to screen the financial system for potential -climate-related transition risks. The analysis can be parameterised in -different ways to explore patterns across the analysed loan books. If -run by private institutions, the results may additionally be used to -identify opportunities for climate-aligned investments, as well as for -detecting individual counterparties that may be exposed to -climate-related transition risks and may therefore require dedicated -focus in the risk management process.

-

Users will be able to obtain both tabular outputs and plots that can -be used for any of the above use cases. The tabular output further -enables processing of the alignment results in other models or tools, -for example as an input into financial risk models, or as a recurring -input into internal monitoring systems.

-

The level of granularity of the outputs allows for a systematic -analysis of climate alignment starting at the financial system level -(across all analyzed loan books together), down to the individual -counterparty level, and across sectors and technologies. Grouping of the -results at any of these levels by additional dimensions can easily be -achieved using the configuration file.

-
-
-

What are the main steps of the analysis? -

-

The main steps of the analysis are as follows:

-
    -
  1. Data preparation: Prepare the ABCD data and optionally a custom -sector split.
    2. -
  2. Matching process: Match the raw loan books to the ABCD data.
    3. -
  3. Prioritization of loan books; Match success and coverage -diagnostics: Prioritize the matched loan books and analyze their -coverage.
    4. -
  4. Run PACTA for Supervisors analysis: Run the analysis based on the -parameters set in the config.yml file.
    5. -
-

This cookbook will guide you through each of the steps of the -analysis in detail, explain the required input data sets and software, -and provide guidance on how to interpret the results.

-

NEXT CHAPTER: Preparatory Steps

-
-
-
-
- - - -
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
- -

© RMI

- -
-
-
-
-
-
-
- - - - - - - - - - - diff --git a/pr-preview/pr-358/articles/cookbook_preparatory_steps.html b/pr-preview/pr-358/articles/cookbook_preparatory_steps.html deleted file mode 100644 index 6ba56cfb..00000000 --- a/pr-preview/pr-358/articles/cookbook_preparatory_steps.html +++ /dev/null @@ -1,706 +0,0 @@ - - - - - - - -Preparatory Steps • pacta.multi.loanbook - - - - - - - - - - - - - - - Skip to contents - - -
- - - - -
-
-

Preparatory Steps

- - - Source: vignettes/cookbook_preparatory_steps.Rmd -
cookbook_preparatory_steps.Rmd
-
- - - -
-

Preparatory Steps -

-

This section provides an overview of the preparatory steps that need -to be taken before running the PACTA for Supervisors analysis. It -includes information on the required input data sets, the required -software, and how to setup the project folder and file structure. -Finally, it provides a checklist of the steps that need to be taken -before running the analysis, summarizing in brief the steps explained in -more detail before.

-
-

Required Input Data Sets -

-

The PACTA for Supervisors analysis requires a number of input data -sets to run. Some of these can be obtained from external sources, while -others need to be prepared by the user. Furthermore, some of the input -data sets are optional and their inclusion will depend on the settings -provided in the config.yml file.

-

The main input data sets required for the analysis are the -following:

-
-

Asset-based Company Data (ABCD) -

-
    -
  • required input
    • -
  • external source
    • -
  • XLSX file
    • -
-

This data set provides information on the production profiles and -emission intensities of companies active in the following real economy -sectors: Automotive (light-duty vehicles) manufacturing, aviation, -cement production, coal mining, upstream oil & gas extraction, power -generation, and steel production. The ABCD is typically obtained from -third party data providers. However, it is possible to prepare the ABCD -yourself or complement an external data set with entries that may not be -covered out of the box.

-

The ABCD data set must be an XLSX file and contains the following -columns:

-
    -
  • company_id
    • -
  • name_company
    • -
  • lei
    • -
  • is_ultimate_owner
    • -
  • sector
    • -
  • technology
    • -
  • plant_location
    • -
  • year
    • -
  • production
    • -
  • production_unit
    • -
  • emission_factor
    • -
  • emission_factor_unit
    • -
-

While PACTA is data agnostic and allows using data from any provider -that offers the appropriate format, one option to obtain ABCD for this -analysis is to buy the data from the data provider Asset Impact. Further -information on how to obtain ABCD for PACTA and documentation of the -individual sectors and data points can be found on the Asset Impact website.

-
-
-

Scenario Data -

-
    -
  • required input(s)
    • -
  • external source
    • -
  • CSV file(s)
    • -
-

The scenario data set provides information on the trajectories of -technologies/fuel types and of emission intensity pathways for each of -(or a subset of) the sectors covered in PACTA.

-

For sectors with technology level trajectories, the data set provides -the TMSR and SMSP pathways based on the Market Share Approach, an -allocation rule that implies all companies active in a sector have to -adjust their production in a way that keeps market shares constant and -solves for the aggregate climate transition scenario. For more -information on how to calculate the TMSR and the SMSP, see the PACTA -for Banks documentation.

-

The target market share scenario data set must be a CSV file and -contains the following columns:

-
    -
  • scenario_source
    • -
  • region
    • -
  • scenario
    • -
  • sector
    • -
  • technology
    • -
  • year
    • -
  • smsp
    • -
  • tmsr
    • -
-

For sectors that do not have technology level pathways, PACTA uses -the Sectoral Decarbonization Approach (SDA), an allocation rule that -implies that all companies in a sector have to converge their physical -emission intensity at a future scenario value - e.g. in the year 2050. -This implies that more polluting companies have to reduce their physical -emissions intensity more drastically than companies using cleaner -technology. It does not have any direct implications on the amount of -units produced by any company. For further information on calculating -the SDA in PACTA, please see the PACTA -for Banks documentation.

-

The SDA scenario data set must be a CSV file and contains the -following columns:

-
    -
  • scenario_source
    • -
  • region
    • -
  • scenario
    • -
  • sector
    • -
  • year
    • -
  • emission_factor
    • -
  • emission_factor_unit
    • -
-

While the raw input values of the scenarios are based on models from -external third party organisations - such as the World -Energy Outlook by the International -Energy Agency (IEA), the Global -Energy and Climate Outlook by the Joint Research Center of the European -Commission (JRC), or the One -Earth Climate Model by the Institute for Sustainable Futures (ISF) - -the input data set for PACTA must be prepared using additional steps, -which are documented publicly on the following GitHub repositories:

- -

Since RMI has taken over stewardship of PACTA, the prepared scenario -files can also be accessed as CSV downloads on the PACTA website -under the “Methodology and Documents” tab of the “PACTA for Banks” -section. The files are usually updated annually based on the latest -scenario publications and as a general rule, the year of the publication -defines the initial year of the scenario data set. This is commonly also -used as the start year of the analysis, which is specified in the -config.yml file.

-
-
-

Raw Loan Books -

-
    -
  • required input
    • -
  • self-prepared
    • -
  • CSV file(s)
    • -
-

The raw loan books are the financial data sets that you would like to -analyze. They contain information on the loans that banks have provided -to companies. As a supervisor, the data required to construct these data -sets will typically be available to you through regulatory filings that -are accessed via internal data bases or similar. As a bank, the data -required will be available in your internal systems.

-

The raw loan books must be prepared as CSV files and contain at a -minimum the following columns:

-
    -
  • id_loan
    • -
  • id_direct_loantaker
    • -
  • name_direct_loantaker
    • -
  • id_ultimate_parent
    • -
  • name_ultimate_parent
    • -
  • loan_size_outstanding
    • -
  • loan_size_outstanding_currency
    • -
  • loan_size_credit_limit
    • -
  • loan_size_credit_limit_currency
    • -
  • sector_classification_system
    • -
  • sector_classification_direct_loantaker
    • -
  • lei_direct_loantaker
    • -
  • isin_direct_loantaker
    • -
-

NOTE: The tool will automatically add a column -group_id to each of the loan books, which uses the file -name as a value. This allows you to group the results of the analysis by -loan book, using the by_group parameter in the -config.yml file. For any other variable that you may want -to group the results by, you need to add a column to the raw loan book -files that you then provide as the by_group parameter in -the config.yml file.

-

For detailed descriptions of how to prepare raw loan books, see the -PACTA for Banks -documentation and navigate to the “Training Materials” tab of the -“PACTA for Banks” section. The “User Guide 2”, the -“Data Dictionary”, and the “Loan Book -Template” files can all be helpful in preparing your data.

-
-
-

Misclassified Loans -

-
    -
  • optional input
    • -
  • self-prepared
    • -
  • CSV file
    • -
-

The user can provide a list of loans that have been misclassified in -the raw loan books. The aim here is specifically to remove false -positives, that is, loans that are classified in scope of one of the -PACTA sectors, but where manual research shows that the companies do not -actually operate within the PACTA scope. Such a false positive may be -due to erroneous data entry in the raw loan book, for example. Removing -these loans from the falsely indicated sector in the calculation of the -match success rate will give a more accurate picture of what match -success rate can really be reached.

-
-
-

Asset-Based Company Data (ABCD) for company sector split -

-
    -
  • optional input
    • -
  • external source
    • -
  • XLSX file
    • -
-

In case the user wants to split company exposures across sectors of -in scope activity, the user must provide a version of the ABCD data set -that follows the format of the Advanced Company Indicators data set by -Asset Impact. This data set includes power generation values which are -required for the primary energy based sector split. Again, more -information on data from Asset Impact can be found on the Asset Impact website.

-
-
-

Companies to apply primary energy split on -

-
    -
  • optional input
    • -
  • self-prepared
    • -
  • CSV file
    • -
-

When applying the sector split on company exposures, the user can -provide a list of companies for which the sector split should be based -on primary energy content. For all other companies, a simple equal -weights split will be applied. For more information on the sector split, -see the documentation in vignette("sector_split").

-
-
-

Manual Sector Classification -

-
    -
  • optional input
    • -
  • self-prepared
    • -
  • CSV file
    • -
-

In case the user cannot obtain sector classification codes of any of -the classification systems featured in -r2dii.data::sector_classifications (currently the following -classification systems are featured: GICS, ISIC, NACE, NAICS, PSIC, -SIC), the user can provide a manually created sector classification file -for matching the loan book to the ABCD instead. Generally, any such -manually prepared sector classification file must follow the format of -r2dii.data::sector_classifications. More information on the -appropriate settings needed in the configuration file can be found in -the documentation -of the config.yml file. It is recommended to use the -built in sector classifications if possible, as mapping your own sector -classification to the PACTA sectors can be complex and time -consuming.

-
-
-
-

Required Software -

-

Using the pacta.multi.loanbook package for the PACTA for -Supervisors analysis requires the following software to be installed on -your system:

-
-

R (version 4.1.0 or higher) -

-

R is the programming language that the -pacta.multi.loanbook package is written in. You can -download R from the Comprehensive -R Archive Network (CRAN).

-
-
-

RStudio (optional) -

-

RStudio is an integrated development environment (IDE) for R -developed by Posit. It is not strictly required to run the analysis, but -it can be helpful for managing your project and running the analysis. -Generally, RStudio is very widely used among the R community and -probably the easiest way to interact with most R tools, such as -pacta.multi.loanbook. RStudio Desktop is an open source -tool and free of charge. You can download RStudio from the Posit RStudio website.

-
-
-

-pacta.multi.loanbook R package -

-

The pacta.multi.loanbook package is the main software -tool that you will use to run the PACTA for Supervisors analysis.

- -
-

You can install the development version of -pacta.multi.loanbook from GitHub with:

-
-# install.packages("pak")
-pak::pak("RMI-PACTA/pacta.multi.loanbook")
-
-

We use the pak package as -a simple tool to -install packages from GitHub.

-
-
Connecting to GitHub from RStudio -
-

Note that if you choose to install pacta.multi.loanbook -from GitHub, you will need to have:

-
    -
  1. registered a GitHub account,
    2. -
  2. -git installed locally,
    3. -
  3. set up credentials so that RStudio can communicate with GitHub.
    4. -
-

You can find more information on how to do this using the following -resources:

-
    -
  • -Happy Git and GitHub for the -useR is a great and comprehensive resource that takes you through -the process of setting up git and GitHub with RStudio, including -registering a GitHub account, installing git, and connecting RStudio to -GitHub.
    • -
  • Additional information on managing your GitHub connection from -within RStudio can be found in the usethis package documentation, for -example on managing -git credentials.
    • -
-

If you only plan to use GitHub to install this package or other -packages as shown above, you will not have to have a deep understanding -of all the git commands, so there is no need to be overwhelmed by the -complexity of git.

-
-
-
-

Required R packages -

-

The pacta.multi.loanbook package depends on a number of -other R packages. These dependencies will be installed automatically -when you install the pacta.multi.loanbook package. The -required packages are:

-

cli (>= 3.2.0), config, -dplyr, ggplot2, glue, -networkD3, r2dii.analysis (>= 0.3.0), -r2dii.data (>= 0.5.0), -r2dii.match (>= 0.3.0), -r2dii.plot (>= 0.4.0), readr (>= 2.0.0), -readxl, rlang, scales, -tidyr, webshot, yaml, -yesno

-
-
-

Suggested R packages -

-

The suggested packages are not required to run the analysis, but they -are used in the examples and vignettes provided with the package:

-

gt, knitr, pkgdown, -rmarkdown, usethis, -testthat (>= 3.1.9), tibble, -withr, writexl

-
-
-

FAQ -

-
-
How do I install the pacta.multi.loanbook package? -
-

The most common ways to install R packages are via CRAN or GitHub. Public -institutions often have restrictions on the installation of packages -from GitHub, so you may need to install the package from CRAN. In some -cases, your institution may mirror CRAN in their internal application -registry, so you may need to install the package from there. Should you -have any issues with the installation from the internal application -registry, it is best to reach out to your IT department. If you cannot -obtain the package in any of these ways, please reach out to the package -maintainers directly for exploring other options.

-
-
-
How do I install the required R packages? -
-

In principle, all dependencies required to run the -pacta.multi.loanbook package will be installed -automatically when you install the package. However, if you encounter -any issues with the installation of the required packages, you can -install them manually by running the following command in R, where … -should be replaced with the package names from the list above, separated -by commas:

- -
-
-
-
-

Project Setup -

-
-

Config -

-

All of the functions needed to run a PACTA for Supervisors analysis -take a config argument, which can either be a path to a -config.yml file (see vignette("config_yml")) -or a config list object containing previously imported settings from a -config.yml file. All of the settings/options are configured -with this config.yml file.

-
-
-

Input/Output folder structure -

-

The config.yml file then points to an input directory -and to four output directories, one for each user-facing function, that -the user can choose anywhere on their system, as long as R has read and -write access to these directories. A recommendable choice to structure -an analysis project would be to place all these folders and the -config.yml file in a project folder. The input folder must -contain all input files as described above, with the raw loan books -being placed in a sub-directory that must be named -"loanbooks". The output folders will automatically be -created at the locations indicated in the config.yml file. -They will be populated by running the analysis. NOTE: -Re-running a step of the analysis will replace the entire corresponding -output directory, if the directory already exists.

-

An example of how the project folder could be structured:

-
your_project_folder
-├── config.yml
-├── input
-│   ├── ABCD.xlsx
-│   ├── loanbooks
-│   │   ├── raw_loanbook_1.csv
-│   │   ├── raw_loanbook_2.csv
-│   │   └── ...
-│   ├── scenario_data_tms.csv
-│   ├── scenario_data_sda.csv
-│   └── ...
-├── prepared_abcd
-├── matched_loanbooks
-├── prioritized_loanbooks_and_diagnostics
-└── analysis
-

Notice that the names of the directories can be changed to something -the user may prefer. The names were chosen for illustrative purposes to -reflect the corresponding user-facing functions that create the -outputs.

-
-
-

Initialise a Project -

-

You can use the following code to initialise a project folder -structure:

-
-library(pacta.multi.loanbook)
-initialise_default_project(path = "path/to/your_project_folder")
-

This will create a minimal project folder structure similar to the -one shown above.

-
    -
  • Note that the target path that you pass to -initialise_default_project() must be a path that does not -exist yet, as it will be newly set up and cannot overwrite any existing -files.
    • -
  • Within this path, an input sub-directory and a -config.yml file will be created. The ìnput -sub-directory will contain another sub-directory loanbooks. -Neither input nor input/loanbooks will contain -any files at this stage and you will have to populate them with the -files described above and following the structure as outlined.
    • -
  • The config.yml file will be created with default -settings. Output paths in the config.yml file will point to sub -directories of the path you pass to -initialise_default_project(), so that running the remaining -steps of the analysis will keep all inputs and outputs in one common -project folder. You can then edit the config.yml file to -adjust the settings to your needs, as described in the corresponding -documentation (see vignette("config_yml")).
    • -
-

It is not strictly necessary to use the -initialise_default_project() function to set up your -project folder. If you prefer setting up another folder structure -manually and creating the config.yml from scratch, you can -do that. But it can be helpful to ensure that you have all the necessary -files and folders in place.

-
-
-
-

Checklist of Preparatory Steps -

-

Before running the PACTA for Supervisors analysis, you should make -sure that you have completed the following preparatory steps:

-
    -
  • - -
      -
      • -
      • -
    -
    • -
  • - -
      -
      • -
    -
    • -
  • - -
      -
      • -
    -
    • -
  • - -
      -
      • -
      • -
      • -
    -
    • -
  • - -
      -
      • -
      • -
      • -
      • -
    -
    • -
  • - -
      -
      • -
    -
    • -
  • - -
      -
      • -
    -
    • -
  • - -
      -
      • -
      • -
      • -
      • -
      • -
      • -
    -
    • -
-

PREVIOUS CHAPTER: Overview

-

NEXT CHAPTER: Running the Analysis

-
-
-
-
- - - -
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
- -

© RMI

- -
-
-
-
-
-
-
- - - - - - - - - - - diff --git a/pr-preview/pr-358/articles/cookbook_running_the_analysis.html b/pr-preview/pr-358/articles/cookbook_running_the_analysis.html deleted file mode 100644 index ff4837a0..00000000 --- a/pr-preview/pr-358/articles/cookbook_running_the_analysis.html +++ /dev/null @@ -1,592 +0,0 @@ - - - - - - - -Running the Analysis • pacta.multi.loanbook - - - - - - - - - - - - - - - Skip to contents - - -
- - - - -
-
-

Running the Analysis

- - - Source: vignettes/cookbook_running_the_analysis.Rmd -
cookbook_running_the_analysis.Rmd
-
- - - -
-

Running the Analysis -

-

This section provides a step-by-step guide to running the PACTA for -Supervisors analysis using the pacta.multi.loanbook -package. It includes information on the structure of the workflow, the -required functions, and the interpretation of the results.

-
-

Structure of the Workflow -

-

The PACTA for Supervisors analysis consists of four main steps:

-
    -
  • Data preparation: Preparing the input data sets for the requirements -of the analysis.
    • -
  • Matching process: Matching the raw loan books to the ABCD data and -validating the matches manually.
    • -
  • Prioritization of loan books: Selecting the correct matches for -further analysis and diagnosing match success and coverage -statistics
    • -
  • Run PACTA for Supervisors analysis: Running the analysis based on -the parameters set in the config.yml file to generate the -production-based alignment analysis.
    • -
-

The following diagram illustrates the structure of the workflow:

-
-Fig. 1: Structure of the Workflow

-Fig. 1: Structure of the Workflow -

-
-

As the diagram shows, there is a logical sequence to how to run the -functions. For any of the functions to work, the previous functions must -have been run already and their outputs must be accessible as inputs to -the next functions. If you want to keep different versions of the -calculations, i.e. you want to avoid overwriting past outputs, you will -have to (1) ensure that each run is done with a new value for the -corresponding output directory set in the config.yml and -(2) that the relevant function refers to the appropriate directories of -upstream outputs. For example, if you want to run the analysis twice and -keep both results, all dir_* entries of the -config.yml should remain identical for both runs, except -for the dir_analysis entry, which should be different for -each run.

-

The following sub sections will provide detailed information on each -of the steps of the analysis, starting with a brief explanation of the -setup, as each of the functions will require the path to the -config.yml file as an input argument.

-
-
-

Setup -

-

If you run PACTA for Supervisors interactively or from a script you -may have prepared, you will likely want to load the -pacta.multi.loanbook package and save the path to the -config.yml file in a variable first:

-
-library(pacta.multi.loanbook)
-config_path <- "path/to/config.yml"
-

This allows you passing the relevant config information easily to -each of the four main functions.

-
-
-

Data preparation -

-

The first step of the analysis is to prepare your input data sets for -the requirements of the analysis. Your ABCD data will need to be -prepared and you can optionally use a custom sector split, that will -also need to be prepared. The relevant function is -prepare_abcd(), which takes configurations from the -config.yml that you have prepared. The function will store -intermediary files in the directory that you have indicated as the value -corresponding to the key dir_prepared_abcd in the -config.yml. This step only has to be run once for an -analysis. You can run this function as follows:

-
-pacta.multi.loanbook::prepare_abcd(config_path)
-
-

Options for the prepare_abcd() function -

-

The prepare_abcd() function has a number of options that -can be set in the config.yml file. These options -include:

- -
-
-

Sector split -

-

If you want to use the sector split, you can specify which company -identifiers the split should be applied on by providing a CSV file with -the company identifiers in the split_company_ids.csv file -in the input directory. The file should contain the columns -company_id and name_company to identify the -relevant companies. Before deciding to apply the sector split, it is -strongly recommended to read the documentation on the sector split in -vignette("sector_split") first.

-
-
-
-

Matching process -

-

The next step in the analysis is to run the matching process. -Assuming you have prepared the raw loan books as explained in the -section on preparing the input data sets, you can now use the -match_loanbooks() function. This will read the raw loan -books from your inputs and attempt to match them to the prepared ABCD -data from the previous step. The function will store matched loan book -files in a directory that you have indicated as the value corresponding -to the key dir_matched_loanbooks in the -config.yml. You can run this function as follows:

-
-pacta.multi.loanbook::match_loanbooks(config_path)
-

After the matching process is complete, you will need to do some -manual matching. This means that you will need to manually inspect the -suggested matches that the tool has found and decide which ones to keep -or to remove. This is especially important when using text based -matching, as there is no guarantee that similar company names as -identified by the algorithms will actually refer to the same companies -in the raw loan books and the ABCD. Thus, a manual validation step is -crucial in the analysis, as the quality of the matches will determine -the quality of the results of any further calculations.

-

The manual matching process is not automated and will require some -time and effort on your part. You can find the matched loan books in the -directory that you have specified as the -dir_matched_loanbooks parameter in the -config.yml file. The matched loan books will be stored -in CSV files, one for each raw loan book. You can open these files in a -spreadsheet program to verify the matches. Importantly, you will need to -make a copy for each of the matched loan book files in the same -directory and rename that copy by adding the suffix _manual -to the file name. The following steps of the analysis expect this -pattern, so it is important to follow this naming convention.

-

You can find more detailed information about the matching process in -the training -material on the PACTA for Banks website in the section “PACTA for -Banks Training Webinar 2” and in the corresponding -slide deck.

-
-

Some expectations for the matching process -

-
    -
  • It is unlikely that you will be able to match all of the loans from -your raw loan books to the ABCD data set. This is expected and has the -following reasons: -
      -
    • Raw loan books often include companies that are not in scope of the -PACTA analysis, for example there may be companies active in the -financial sector or in manufacturing of IT products. Both these sectors -are fully out of scope. There may also be companies that are active in -upstream or downstream activities of the sectors covered by PACTA. This -means that the company activities are not at the part of the value chain -that is covered by PACTA and accordingly the companies are not matched. -Examples for this are power distribution companies or companies that -manufacture aircrafts.
      • -
    • The ABCD data set may not cover all companies that are in scope of -the PACTA analysis. While coverage of the real economy sectors is -usually rather high in the data sets that are commonly used for PACTA, -there are gaps. This implies that some in-scope companies cannot be -matched because the ABCD data set does not include them. Advanced users -may research the production profiles of such companies by themselves and -add them to the ABCD data manually, however this is a very involved -process and not standard procedure and will therefore not be covered in -this cookbook.
      • -
    • If you are using sector classifications for the matching process -(which is recommended whenever possible), some matches may not be -identified in case the companies in the raw loan book are misclassified. -For example, if a utility that is focused on coal-fired power generation -is classified as a coal mining company, the matching function will not -suggest a match.
      • -
    -
    • -
  • Given that it is unlikely to match all loans, it is recommended to -try and match the companies with the largest financial exposures first, -as this ensures the best possible financial coverage of the loan book in -the analysis.
    • -
  • It is also recommended to run multiple iterations of the matching -process, potentially adjusting the matching parameters in the -config.yml file, to see if you can improve the match -success rate. The match success rate can be obtained based on the -manually validated matched loan books and the raw loan books as -described in the -next section on prioritization and diagnostics.
    • -
-
-
-

Options for the match_loanbooks() function -

-

The match_loanbooks() function has a number of options -that can be set in the config.yml file. These options -include:

-
    -
  • -params_match_name: -multiple options to specify the approach to matching the raw loan book -with the ABCD relevant -section on matching in the vignette("config_yml")). -Note that these parameters are all based on the -r2dii.match::match_name function and pass the parameters -directly to that function. For more information on the options -available, see the documentation -of the r2dii.match package. This also covers matching based on -unique identifiers, which is the most reliable way to match companies, -but requires that both the raw loan books and the ABCD contain such -identifiers.
    • -
  • -manual_sector_classification: -whether to use a manually prepared sector classification system for -matching the loan books to in-scope PACTA sectors, see the relevant -section on matching in the vignette("config_yml")), or -not. If there is no need to use a manually prepared sector -classification file, the sector classification systems provided in -r2dii.data::sector_classifications can be used, which -currently cover the following sector classifications: GICS, ISIC, NACE, -NAICS, PSIC, SIC. If it is not possible to map the loans in your loan -books to any of these systems, you can prepare your own mapping file -that follows the same structure as the sector classification files in -r2dii.data::sector_classifications and use the config file -to instruct the code to use this file for matching. Note that this will -only be a promising approach if the classifications you are using are -sufficiently granular to map to PACTA sectors without excessive -ambiguity.
    • -
-
-
-

Addressing misclassfied loans -

-

There are two ways to appropriately handle misclassified loans that -are identified as in-scope in the raw data set but are then not -matched.

-
    -
  1. Correct the classification in the raw loan book and re-run the -matching process. If the loan was clearly mis-classified, this may be -the most appropriate way to handle the issue. It may be a good idea to -record any such changes made in the input data though. The upside of -this approach is that the loan will now either be matched correctly, as -it will be assigned the sector that the company should have and -therefore find an entry in the ABCD data set to match against. Or, if -there is still no match to be found in the ABCD, the loan will correctly -be missing in the appropriate sector and therefore indicate a lower -match success rate where it should.
    2. -
  2. If a manual re-classification of the raw loan book is not possible -or desired, the calculation of the match success rate can be corrected -by adding a file loans_to_remove.csv to the input -directory. This file should include the columns id_loan and -group_id to indicate the precise mis-classified loan and -the loan book in which it was found. This combination of loan and loan -book will then be excluded from the match success calculation.
    3. -
-

The reason why it is a good idea to either correct mis-classified -loans or disregard them in the calculation of the match success rate is -that a mis-classified loan cannot possibly be matched in a given sector. -Therefore, no amount of work would be sufficient to improve the sector -match success rate, because it is calculated against an incorrect -baseline. Technically, the user is not forced to correct -misclassifications, and there may be a limit to how much time should be -spent on this, but it is recommended to at least correct large -mis-classified loans.

-
-
-

Sector split -

-

If you want to apply the sector split to the loan books, you should -keep all relevant sectors in the matched loan book, instead of only one -sector. This is because the sector split will be applied to the matched -loan books, and the sector split will be based on the sectors in the -matched loan books. If you only keep one sector in the matched loan -books, the sector split will not be applied correctly and may wrongly -appear to reduce overall matched financial exposure. The sector split -will be applied to the matched loan books in the next step of the -analysis.

-
-
-
-

Prioritization of loan books; Match success and coverage -diagnostics -

-

The next step is to prioritize the manually verified matched loan -books and analyze their coverage, both relative to the raw loan book -inputs (the “match success rate”) and to the production capacity in the -wider economy (the “loan book production coverage”). Prioritizing the -loan books means that you will only keep the best identified match for -each loan and use that in the following steps of the analysis.

-

You will probably want to check the status of your loan book and -production coverage several times, as it is rare to get to the desired -level of matching in one iteration (see the corresponding “Coverage -Diagnostics” section in the next chapter for more details on how to -interpret the coverage values). This means you may want to repeat the -previous step (matching the loan books, -likely using different parameters for different iterations) and this -step (prioritizing the matched loan books and analyzing their match -success rate) a number of times to reach the best possible outcome. To -prioritize your matched loan books and calculate the coverage -diagnostics, you will use the prioritise_and_diagnose() -function. This call will store matched prioritized loan book files and -coverage diagnostics in a directory that you have indicated as the value -corresponding to the key -dir_prioritized_loanbooks_and_diagnostics in the -config.yml. You can run the function as follows:

-
-pacta.multi.loanbook::prioritise_and_diagnose(config_path)
-
-

Options for the prioritise_and_diagnose() function -

-

The prioritise_and_diagnose() function has a number of -options that can be set in the config.yml file. These -options include:

-
    -
  • -priority: the -option to set a specific order for prioritizing the matches. This is an -option that is passed directly to the -r2dii.match::prioritize function. NULL is a -valid default value and is usually a setting that works well, at least -as a starting point. For more information, see the relevant -section on the prioritization of matched loan books in the -vignette("config_yml") or the documentation -of the r2dii.match::prioritize() function here.
    • -
  • -by_group: by -which variables to group the loan books to produce grouped results of -the analysis. This parameter is used across multiple steps of the -analysis, both in the diagnostics and in the analysis. This is because -it slices and/or aggregates the loan books such that the analysis will -produce results along the indicated dimension. If no by_group -parameter is passed (i.e. NULL), all loan -books will be aggregated. Otherwise, loan books can either be kept -separate (group_id) or -grouped by any other variable that is provided in each of the raw loan -books. Although by_group is -considered a project parameter mainly relevant to the main section of -the analysis it does affect the split of the prioritzed loan books and -how their coverage metrics are returned, so it is good to be aware of -this parameter at this point. See the relevant -section on the by_group parameter in the documentation of -the config.yml file.
    • -
-
-
-
-

Run PACTA for Supervisors analysis -

-

The final step is running the analysis based on the parameters you -have set in the config.yml file. This entails both a -standard PACTA for Banks analysis and the calculation of the net -aggregate alignment metric. For both parts of the analysis, outputs will -be stored in the sub-directories ../standard/ (for standard -PACTA for Banks results) and ../aggregated/ for the net -aggregate alignment metric directory - below the directory that you have -indicated as the value corresponding to the key -dir_analysis in the config.yml. Outputs in -these sub directories will comprise tabular outputs and plots. To run -the analysis on all of your previously matched and prioritized loan -books, you will use the analyse() function as follows:

-
-pacta.multi.loanbook::analyse(config_path)
-
-

Options for the analysis() function and the overall -analysis -

-

The analysis() function has a number of options that can -be set in the config.yml file. These options include:

-
    -
  • -scenario_source: -which source should be used for allocating climate transition scenario -pathways to the companies and loan books. This refers to the relevant -scenario publication and usually contains the name and the year of the -publication, e.g.: "weo_2023" -or "geco_2023".
    • -
  • -scenario_select: -which scenario should be used for reference in the net aggregate -alignment metric. This must be a scenario that is included in the scenario_source -indicated above.
    • -
  • -region_select: -which region to use as a reference for the analysis. This will filter -the underlying production capacity to assets in the relevant region and -will measure alignment against the scenario trajectory for the relevant -region. It must therefore be a region, for which scenario data is -available in the source selected above. Note that usually, "global" -is also a valid region.
    • -
  • -start_year: the -start year of the analysis. This must be a year that is available both -in the ABCD data and for which the scenario data has been prepared. The -loan book data is assumed to be a snapshot of the end of the same -year.
    • -
  • -time_frame: the -time frame of the analysis, which refers to the number of forward -looking years after the start year that are to be considered in the -alignment analysis. Usually this time frame is set to 5 years. -Specifically, it must be a time frame for which scenario data values and -ABCD data values are available for all sectors that are to be analyzed. -There are not many cases, in which it is expected to change the time -frame to something else than its default value of 5 years.
    • -
  • -by_group: by -which variables to group the loan books to produce grouped results of -the analysis. This parameter is used across multiple steps of the -analysis, both in the diagnostics and in the analysis. This is because -it slices and/or aggregates the loan books such that the analysis will -produce results along the indicated dimension. If no by_group -parameter is passed (i.e. NULL), all loan -books will be aggregated. Otherwise, loan books can either be kept -separate (group_id) or -grouped by any other variable that is provided in each of the raw loan -books.
    • -
-

All these options are documented in more detail the section -on project parameters in the -vignette("config_yml").

-

Usually, it will be interesting to run the analysis for more than one -by_group -value, possibly also for multiple combinations of the other -parameters. You will therefore have to run the analysis as many times as -there are combinations of interest that you wish to generate results -for. If you do this, you should take into account that running the same -pacta.multi.loanbooks function multiple times with -different parameters will overwrite the results of the previous run if -you do not use new output directories for each run. This is why it is -recommended to set -up a new output directory in the config.yml file for -each run of the analysis, if you want to keep the results of multiple -runs so that you can compare the outcomes based on different parameters. -The last chapter “Advanced -Use Cases” describes how you could go about that process in more -detail. However, it is recommended going through the standard process of -the analysis completely once, before approaching more advanced use -cases.

-

PREVIOUS CHAPTER: Preparatory Steps

-

NEXT CHAPTER: Interpretation of Results

-
-
-
-
-
- - - -
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
- -

© RMI

- -
-
-
-
-
-
-
- - - - - - - - - - - diff --git a/pr-preview/pr-358/articles/data_dictionary.html b/pr-preview/pr-358/articles/data_dictionary.html deleted file mode 100644 index 09cf8f22..00000000 --- a/pr-preview/pr-358/articles/data_dictionary.html +++ /dev/null @@ -1,9435 +0,0 @@ - - - - - - - -Understanding the data • pacta.multi.loanbook - - - - - - - - - - - - - - - Skip to contents - - -
- - - - -
-
-

Understanding the data

- - - Source: vignettes/data_dictionary.Rmd -
data_dictionary.Rmd
-
- - - -
-

Intro -

-

In many cases, users of this package will want to use the outputs of -the analyses for further processing, such as additional analyses or -making visualizations based on the design guide of their own -organisation. To facilitate such additional use cases, but also simplify -interpretation of the outputs generated with this package, this data -dictionary documents each type of output table in detail, focusing on -data types and definitions.

-

This article is structured based on the output tables generated by -pacta.multi.loanbook and follows the standard flow of the -user experience as much as possible, so it can be read in the same -sequence as the analysis is run.

-
-
-

Tables -

-

The main steps that generate output tables are:

-
    -
  • Diagnostics and coverage
    • -
  • Standard PACTA analysis
    • -
  • Aggregated PACTA metrics
    • -
-
-

Diagnostics -

-

The diagnostics section is split into determining the match success -rate of the loan books analysed and inspecting the real economy activity -related to the financing made by the banks through the matched loan -books. The former is influenced by the quality of the input loan book -data and the completeness of the reference production data against which -the loan books are matched. The latter, while it depends on a solid -match success rate, is mainly driven by the financing decisions and the -portfolio allocation made by the banks. If a sector split is applied to -the loan book, any companies that are lost in the process are documented -for every loan book.

-
-

Match success rate -

-
-dplyr::filter(data_dictionary, .data[["dataset"]] == "lbk_match_success_rate")
-
- -
- -
-
-
-

Loan book coverage -

-
-dplyr::filter(data_dictionary, .data[["dataset"]] == "summary_statistics_loanbook_coverage")
-
- -
- -
-
-
-

Companies lost in sector split -

-
-dplyr::filter(data_dictionary, .data[["dataset"]] == "lost_companies_sector_split")
-
- -
- -
-
-
-
-

Standard PACTA analysis -

-

The standard PACTA analysis is run across all input banking books, -but produces the same output metrics as known from the -r2dii.* packages. Results are given at portfolio level -grouped by banking book. Beyond the standard output format, tables are -provided that can be used as input for visualizations, for each of the -standard sectors and technologies.

-
-

Target Market Share results (all groups) -

-

Target market share results at the portfolio level for each included -banking book

-
-dplyr::filter(data_dictionary, .data[["dataset"]] == "tms_results")
-
- -
- -
-
-
-

Sectoral Decarbonization Approach results (all groups) -

-

SDA results at the portfolio level for each included banking book

-
-dplyr::filter(data_dictionary, .data[["dataset"]] == "sda_results")
-
- -
- -
-
-
-

Data tech mix -

-

Results for a given portfolio and sector, tailored to be used in the -tech mix chart

-
-dplyr::filter(data_dictionary, .data[["dataset"]] == "data_tech_mix")
-
- -
- -
-
-
-

Data trajectory -

-

Results for a given portfolio, sector and technology, tailored to be -used in the volume trajectory chart

-
-dplyr::filter(data_dictionary, .data[["dataset"]] == "data_trajectory")
-
- -
- -
-
-
-

Data emission intensity -

-

Results for a given portfolio and sector, tailored to be used in the -emission intensity chart

-
-dplyr::filter(data_dictionary, .data[["dataset"]] == "data_emission_intensity")
-
- -
- -
-
-
-

Companies included -

-

Lists all companies including exposures, that were analysed for the -given loan book and that are therefore included in the data to be -visualized.

-
-dplyr::filter(data_dictionary, .data[["dataset"]] == "companies_included")
-
- -
- -
-
-
-
-

Aggregated PACTA metrics -

-

The aggregated PACTA metrics are also run across all input banking -books. The calculations produce the net aggregate alignment metric, -which is defined in the vignettes “Calculation of a company alignment -metric” and “Calculation of -exposure-weighted aggregated alignment metric” and allows producing -the corresponding plots. Results are grouped at the level defined by the -by_group parameter.

-
-

Company technology deviation -

-

For each company in the analyzed banking books, shows the deviation -of the technology build-out in the final year of the analysis from the -corresponding allocated scenario value. This is an intermediate result -that is further processed in the calculation of the net aggregate -alignment metric. Only available for sectors, which have technology -level calculations using the target market share, namely -automotive, coal, oil and gas, power.

-
-dplyr::filter(data_dictionary, .data[["dataset"]] == "company_technology_deviation_tms")
-
- -
- -
-
-
-

Company net alignment metric for TMS sectors -

-

For each company in the analyzed banking books, shows the net -aggregate alignment metric for sectors, which have technology level -calculations using the target market share, namely -automotive, coal, oil and gas, power. See -vignette("company_alignment_metric") for methodological -documentation.

-
-dplyr::filter(data_dictionary, .data[["dataset"]] == "company_alignment_net_tms")
-
- -
- -
-
-
-

Disaggregated company buildout/phaseout alignment metric for TMS -sectors -

-

For each company in the analyzed banking books, shows the aggregate -alignment metric - disaggregated into its buildout and phaseout -components - for sectors, which have technology level calculations using -the target market share, namely -automotive, coal, oil and gas, power. See -vignette("company_alignment_metric") for methodological -documentation.

-
-dplyr::filter(data_dictionary, .data[["dataset"]] == "company_alignment_bo_po_tms")
-
- -
- -
-
-
-

Company net alignment metric for SDA sectors -

-

For each company in the analyzed banking books, shows the net -aggregate alignment metric for sectors, which have sector level -calculations using the sectoral decarbonization approach (SDA), namely -aviation, cement, steel. See -vignette("company_alignment_metric") for methodological -documentation.

-
-dplyr::filter(data_dictionary, .data[["dataset"]] == "company_alignment_net_sda")
-
- -
- -
-
-
-

Company net aggregate alignment metric with financial exposures -

-

For each company in the analyzed banking books, shows the net -aggregate alignment metric for all available sectors. This table -includes the financial exposure to each of the analyzed parts of the -banking books, split as defined in by_group.

-
-dplyr::filter(data_dictionary, .data[["dataset"]] == "company_exposure_net_aggregate_alignment")
-
- -
- -
-
-
-

Disaggregated company buildout/phaseout alignment metric with -financial exposures -

-

For each company in the analyzed banking books, shows the net -aggregate alignment metric - disaggregated by its buildout and phaseout -components - for all sectors that use technology level TMS calculations, -namely automotive, coal, oil and gas, power. This table -includes the financial exposure to each of the analyzed parts of the -banking books, split as defined in by_group. Note that the -financial exposure is not disaggregated, the alignment metric is.

-
-dplyr::filter(data_dictionary, .data[["dataset"]] == "company_exposure_bo_po_aggregate_alignment")
-
- -
- -
-
-
-

Loan book net aggregate alignment metric with financial -exposures -

-

For each loan book level group (split as defined in -by_group), shows the net aggregate alignment metric for all -available sectors. This table includes the financial exposure to each of -the analyzed parts of the banking books. Company level results are -aggregated to the loan book level, using their relative financial -exposure as weights.

-
-dplyr::filter(data_dictionary, .data[["dataset"]] == "loanbook_exposure_net_aggregate_alignment")
-
- -
- -
-
-
-

Disaggregated loan book buildout/phaseout alignment metric with -financial exposures -

-

For each loan book level group (split as defined in -by_group), shows the net aggregate alignment metric - -disaggregated by its buildout and phaseout components - for all sectors -using technology level TMS calculations, namely -automotive, coal, oil and gas, power. Company level results -are aggregated to the loan book level, using their relative financial -exposure as weights.

-
-dplyr::filter(data_dictionary, .data[["dataset"]] == "loanbook_exposure_bo_po_aggregate_alignment")
-
- -
- -
-
-
-

Input data for Sankey plot -

-

Data set meant to be used as input into -plot_sankey().

-
-dplyr::filter(data_dictionary, .data[["dataset"]] == "data_sankey")
-
- -
- -
-
-
-

Input data for alignment-by-exposure scatter plot -

-

Data set meant to be used as input into -plot_scatter_alignment_exposure().

-
-dplyr::filter(data_dictionary, .data[["dataset"]] == "data_scatter_alignment_exposure")
-
- -
- -
-
-
-

Input data for buildout/phaseout scatter plot -

-

Data set meant to be used as input into -plot_scatter().

-
-dplyr::filter(data_dictionary, .data[["dataset"]] == "data_scatter_sector")
-
- -
- -
-
-
-
-
-
- - - -
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
- -

© RMI

- -
-
-
-
-
-
-
- - - - - - - - - - - diff --git a/pr-preview/pr-358/articles/data_dictionary_files/core-js-2.5.3/LICENSE b/pr-preview/pr-358/articles/data_dictionary_files/core-js-2.5.3/LICENSE deleted file mode 100644 index d12a3a36..00000000 --- a/pr-preview/pr-358/articles/data_dictionary_files/core-js-2.5.3/LICENSE +++ /dev/null @@ -1,19 +0,0 @@ -Copyright (c) 2014-2017 Denis Pushkarev - -Permission is hereby granted, free of charge, to any person obtaining a copy -of this software and associated documentation files (the "Software"), to deal -in the Software without restriction, including without limitation the rights -to use, copy, modify, merge, publish, distribute, sublicense, and/or sell -copies of the Software, and to permit persons to whom the Software is -furnished to do so, subject to the following conditions: - -The above copyright notice and this permission notice shall be included in -all copies or substantial portions of the Software. - -THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR -IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, -FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE -AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER -LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, -OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN -THE SOFTWARE. diff --git a/pr-preview/pr-358/articles/data_dictionary_files/core-js-2.5.3/package.json b/pr-preview/pr-358/articles/data_dictionary_files/core-js-2.5.3/package.json deleted file mode 100644 index da897f39..00000000 --- a/pr-preview/pr-358/articles/data_dictionary_files/core-js-2.5.3/package.json +++ /dev/null @@ -1,79 +0,0 @@ -{ - "devDependencies": { - "@babel/cli": "^7.7.7", - "@babel/core": "^7.7.7", - "@babel/plugin-proposal-nullish-coalescing-operator": "^7.7.4", - "@babel/plugin-proposal-optional-catch-binding": "^7.7.4", - "@babel/plugin-proposal-optional-chaining": "^7.7.5", - "@babel/plugin-transform-arrow-functions": "^7.7.4", - "@babel/plugin-transform-block-scoped-functions": "^7.7.4", - "@babel/plugin-transform-block-scoping": "^7.7.4", - "@babel/plugin-transform-classes": "^7.7.4", - "@babel/plugin-transform-computed-properties": "^7.7.4", - "@babel/plugin-transform-destructuring": "^7.7.4", - "@babel/plugin-transform-exponentiation-operator": "^7.7.4", - "@babel/plugin-transform-literals": "^7.7.4", - "@babel/plugin-transform-member-expression-literals": "^7.7.4", - "@babel/plugin-transform-parameters": "^7.7.7", - "@babel/plugin-transform-property-literals": "^7.7.4", - "@babel/plugin-transform-shorthand-properties": "^7.7.4", - "@babel/plugin-transform-spread": "^7.7.4", - "@babel/plugin-transform-template-literals": "^7.7.4", - "babel-loader": "^8.0.6", - "babel-plugin-transform-es2015-modules-simple-commonjs": "~0.3.0", - "babel-plugin-transform-for-of-as-array": "^1.1.1", - "es-observable": "git+https://github.com/tc39/proposal-observable.git#bf4d87144b6189e793593868e3c022eb51a7d292", - "eslint": "^6.8.0", - "eslint-import-resolver-webpack": "^0.12.0", - "eslint-plugin-import": "^2.19.1", - "eslint-plugin-node": "^10.0.0", - "eslint-plugin-optimize-regex": "^1.1.7", - "eslint-plugin-qunit": "^4.0.0", - "eslint-plugin-sonarjs": "^0.5.0", - "eslint-plugin-unicorn": "^15.0.0", - "grunt": "^1.0.4", - "grunt-cli": "^1.3.2", - "grunt-contrib-clean": "^2.0.0", - "grunt-contrib-copy": "^1.0.0", - "grunt-contrib-uglify": "^4.0.1", - "grunt-karma": "^3.0.2", - "grunt-webpack": "^3.1.3", - "karma": "^4.4.1", - "karma-chrome-launcher": "^3.1.0", - "karma-phantomjs-launcher": "~1.0.4", - "karma-qunit": "^4.0.0", - "lerna": "^3.19.0", - "moon-unit": "^0.2.2", - "phantomjs-prebuilt": "~2.1.16", - "promises-aplus-tests": "^2.1.2", - "puppeteer": "~2.0.0", - "qunit": "~2.9.3", - "webpack": "^4.41.4" - }, - "license": "MIT", - "repository": { - "type": "git", - "url": "https://github.com/zloirock/core-js.git" - }, - "scripts": { - "bootstrap": "lerna bootstrap --no-ci", - "build": "grunt clean copy && npm run bootstrap && npm run build-compat && grunt bundle uglify", - "build-compat": "npm run build-compat-data && npm run build-compat-entries && npm run build-compat-modules-by-versions", - "build-compat-data": "node packages/core-js-compat/src/build-data", - "build-compat-entries": "node packages/core-js-compat/src/build-entries", - "build-compat-modules-by-versions": "node packages/core-js-compat/src/build-modules-by-versions", - "lint": "grunt clean copy && npm run bootstrap && npm run build-compat && eslint ./", - "unit-tests": "grunt clean copy && npm run bootstrap && npm run build-compat && grunt bundle webpack:helpers webpack:tests karma:tests", - "unit-tests-pure": "grunt clean copy && npm run build-compat && grunt webpack:helpers webpack:pure karma:pure", - "bundle-promises-tests": "grunt webpack:promises-aplus-tests", - "promises-tests": "promises-aplus-tests tests/promises-aplus/adapter --timeout 1000", - "observables-tests": "babel node_modules/es-observable/test/ -d tests/bundles/observables-tests/ && node tests/observables/adapter && node tests/observables/adapter-pure", - "commonjs-tests": "node tests/commonjs", - "commonjs-entries-content": "node tests/commonjs-entries-content", - "targets-parser-tests": "node tests/targets-parser", - "test": "grunt clean copy && npm run bootstrap && npm run build-compat && eslint ./ && grunt webpack:helpers webpack:tests bundle uglify karma:tests webpack:helpers webpack:pure karma:pure && npm run promises-tests && npm run observables-tests && npm run commonjs-tests && npm run commonjs-entries-content && npm run targets-parser-tests" - }, - "engines": { - "node": ">=8.9.0" - } -} diff --git a/pr-preview/pr-358/articles/data_dictionary_files/core-js-2.5.3/shim.min.js b/pr-preview/pr-358/articles/data_dictionary_files/core-js-2.5.3/shim.min.js deleted file mode 100644 index dcc9a160..00000000 --- a/pr-preview/pr-358/articles/data_dictionary_files/core-js-2.5.3/shim.min.js +++ /dev/null @@ -1,10 +0,0 @@ -/** - * core-js 2.6.11 - * https://github.com/zloirock/core-js - * License: http://rock.mit-license.org - * © 2019 Denis Pushkarev - */ -!function(e,i,Jt){"use strict";!function(r){var e={};function __webpack_require__(t){if(e[t])return e[t].exports;var n=e[t]={i:t,l:!1,exports:{}};return r[t].call(n.exports,n,n.exports,__webpack_require__),n.l=!0,n.exports}__webpack_require__.m=r,__webpack_require__.c=e,__webpack_require__.d=function(t,n,r){__webpack_require__.o(t,n)||Object.defineProperty(t,n,{configurable:!1,enumerable:!0,get:r})},__webpack_require__.n=function(t){var n=t&&t.__esModule?function getDefault(){return t["default"]}:function getModuleExports(){return t};return __webpack_require__.d(n,"a",n),n},__webpack_require__.o=function(t,n){return Object.prototype.hasOwnProperty.call(t,n)},__webpack_require__.p="",__webpack_require__(__webpack_require__.s=129)}([function(t,n,r){var v=r(2),g=r(26),y=r(11),d=r(12),b=r(18),S="prototype",_=function(t,n,r){var e,i,o,u,c=t&_.F,a=t&_.G,f=t&_.P,s=t&_.B,l=a?v:t&_.S?v[n]||(v[n]={}):(v[n]||{})[S],h=a?g:g[n]||(g[n]={}),p=h[S]||(h[S]={});for(e in a&&(r=n),r)o=((i=!c&&l&&l[e]!==Jt)?l:r)[e],u=s&&i?b(o,v):f&&"function"==typeof o?b(Function.call,o):o,l&&d(l,e,o,t&_.U),h[e]!=o&&y(h,e,u),f&&p[e]!=o&&(p[e]=o)};v.core=g,_.F=1,_.G=2,_.S=4,_.P=8,_.B=16,_.W=32,_.U=64,_.R=128,t.exports=_},function(t,n,r){var e=r(4);t.exports=function(t){if(!e(t))throw TypeError(t+" is not an object!");return t}},function(t,n){var r=t.exports="undefined"!=typeof window&&window.Math==Math?window:"undefined"!=typeof self&&self.Math==Math?self:Function("return this")();"number"==typeof i&&(i=r)},function(t,n){t.exports=function(t){try{return!!t()}catch(n){return!0}}},function(t,n){t.exports=function(t){return"object"==typeof t?null!==t:"function"==typeof t}},function(t,n,r){var e=r(47)("wks"),i=r(33),o=r(2).Symbol,u="function"==typeof o;(t.exports=function(t){return e[t]||(e[t]=u&&o[t]||(u?o:i)("Symbol."+t))}).store=e},function(t,n,r){var e=r(20),i=Math.min;t.exports=function(t){return 0"+i+""};t.exports=function(n,t){var r={};r[n]=t(o),e(e.P+e.F*i(function(){var t=""[n]('"');return t!==t.toLowerCase()||3document.F=Object<\/script>"),t.close(),s=t.F;r--;)delete s[f][u[r]];return s()};t.exports=Object.create||function create(t,n){var r;return null!==t?(a[f]=i(t),r=new a,a[f]=null,r[c]=t):r=s(),n===Jt?r:o(r,n)}},function(t,n,r){var e=r(95),i=r(69).concat("length","prototype");n.f=Object.getOwnPropertyNames||function getOwnPropertyNames(t){return e(t,i)}},function(t,n,r){var e=r(2),i=r(8),o=r(7),u=r(5)("species");t.exports=function(t){var n=e[t];o&&n&&!n[u]&&i.f(n,u,{configurable:!0,get:function(){return this}})}},function(t,n){t.exports=function(t,n,r,e){if(!(t instanceof n)||e!==Jt&&e in t)throw TypeError(r+": incorrect invocation!");return t}},function(t,n,r){var h=r(18),p=r(108),v=r(81),g=r(1),y=r(6),d=r(83),b={},S={};(n=t.exports=function(t,n,r,e,i){var o,u,c,a,f=i?function(){return t}:d(t),s=h(r,e,n?2:1),l=0;if("function"!=typeof f)throw TypeError(t+" is not iterable!");if(v(f)){for(o=y(t.length);l")}),d=function(){var t=/(?:)/,n=t.exec;t.exec=function(){return n.apply(this,arguments)};var r="ab".split(t);return 2===r.length&&"a"===r[0]&&"b"===r[1]}();t.exports=function(r,t,n){var e=p(r),o=!l(function(){var t={};return t[e]=function(){return 7},7!=""[r](t)}),i=o?!l(function(){var t=!1,n=/a/;return n.exec=function(){return t=!0,null},"split"===r&&(n.constructor={},n.constructor[g]=function(){return n}),n[e](""),!t}):Jt;if(!o||!i||"replace"===r&&!y||"split"===r&&!d){var u=/./[e],c=n(h,e,""[r],function maybeCallNative(t,n,r,e,i){return n.exec===v?o&&!i?{done:!0,value:u.call(n,r,e)}:{done:!0,value:t.call(r,n,e)}:{done:!1}}),a=c[1];f(String.prototype,r,c[0]),s(RegExp.prototype,e,2==t?function(t,n){return a.call(t,this,n)}:function(t){return a.call(t,this)})}}},function(t,n,r){var e=r(2).navigator;t.exports=e&&e.userAgent||""},function(t,n,r){var d=r(2),b=r(0),S=r(12),_=r(41),x=r(30),m=r(40),w=r(39),E=r(4),O=r(3),M=r(57),I=r(43),P=r(72);t.exports=function(e,t,n,r,i,o){var u=d[e],c=u,a=i?"set":"add",f=c&&c.prototype,s={},l=function(t){var r=f[t];S(f,t,"delete"==t?function(t){return!(o&&!E(t))&&r.call(this,0===t?0:t)}:"has"==t?function has(t){return!(o&&!E(t))&&r.call(this,0===t?0:t)}:"get"==t?function get(t){return o&&!E(t)?Jt:r.call(this,0===t?0:t)}:"add"==t?function add(t){return r.call(this,0===t?0:t),this}:function set(t,n){return r.call(this,0===t?0:t,n),this})};if("function"==typeof c&&(o||f.forEach&&!O(function(){(new c).entries().next()}))){var h=new c,p=h[a](o?{}:-0,1)!=h,v=O(function(){h.has(1)}),g=M(function(t){new c(t)}),y=!o&&O(function(){for(var t=new c,n=5;n--;)t[a](n,n);return!t.has(-0)});g||(((c=t(function(t,n){w(t,c,e);var r=P(new u,t,c);return n!=Jt&&m(n,i,r[a],r),r})).prototype=f).constructor=c),(v||y)&&(l("delete"),l("has"),i&&l("get")),(y||p)&&l(a),o&&f.clear&&delete f.clear}else c=r.getConstructor(t,e,i,a),_(c.prototype,n),x.NEED=!0;return I(c,e),b(b.G+b.W+b.F*((s[e]=c)!=u),s),o||r.setStrong(c,e,i),c}},function(t,n,r){for(var e,i=r(2),o=r(11),u=r(33),c=u("typed_array"),a=u("view"),f=!(!i.ArrayBuffer||!i.DataView),s=f,l=0,h="Int8Array,Uint8Array,Uint8ClampedArray,Int16Array,Uint16Array,Int32Array,Uint32Array,Float32Array,Float64Array".split(",");l<9;)(e=i[h[l++]])?(o(e.prototype,c,!0),o(e.prototype,a,!0)):s=!1;t.exports={ABV:f,CONSTR:s,TYPED:c,VIEW:a}},function(t,n,r){t.exports=r(29)||!r(3)(function(){var t=Math.random();__defineSetter__.call(null,t,function(){}),delete r(2)[t]})},function(t,n,r){var e=r(0);t.exports=function(t){e(e.S,t,{of:function of(){for(var t=arguments.length,n=new Array(t);t--;)n[t]=arguments[t];return new this(n)}})}},function(t,n,r){var e=r(0),u=r(10),c=r(18),a=r(40);t.exports=function(t){e(e.S,t,{from:function from(t){var n,r,e,i,o=arguments[1];return u(this),(n=o!==Jt)&&u(o),t==Jt?new this:(r=[],n?(e=0,i=c(o,arguments[2],2),a(t,!1,function(t){r.push(i(t,e++))})):a(t,!1,r.push,r),new this(r))}})}},function(t,n,r){var e=r(4),i=r(2).document,o=e(i)&&e(i.createElement);t.exports=function(t){return o?i.createElement(t):{}}},function(t,n,r){var e=r(2),i=r(26),o=r(29),u=r(94),c=r(8).f;t.exports=function(t){var n=i.Symbol||(i.Symbol=o?{}:e.Symbol||{});"_"==t.charAt(0)||t in n||c(n,t,{value:u.f(t)})}},function(t,n,r){var e=r(47)("keys"),i=r(33);t.exports=function(t){return e[t]||(e[t]=i(t))}},function(t,n){t.exports="constructor,hasOwnProperty,isPrototypeOf,propertyIsEnumerable,toLocaleString,toString,valueOf".split(",")},function(t,n,r){var e=r(2).document;t.exports=e&&e.documentElement},function(t,n,i){var r=i(4),e=i(1),o=function(t,n){if(e(t),!r(n)&&null!==n)throw TypeError(n+": can't set as prototype!")};t.exports={set:Object.setPrototypeOf||("__proto__"in{}?function(t,r,e){try{(e=i(18)(Function.call,i(16).f(Object.prototype,"__proto__").set,2))(t,[]),r=!(t instanceof Array)}catch(n){r=!0}return function setPrototypeOf(t,n){return o(t,n),r?t.__proto__=n:e(t,n),t}}({},!1):Jt),check:o}},function(t,n,r){var o=r(4),u=r(71).set;t.exports=function(t,n,r){var e,i=n.constructor;return i!==r&&"function"==typeof i&&(e=i.prototype)!==r.prototype&&o(e)&&u&&u(t,e),t}},function(t,n){t.exports="\t\n\x0B\f\r   ᠎             　\u2028\u2029\ufeff"},function(t,n,r){var i=r(20),o=r(23);t.exports=function repeat(t){var n=String(o(this)),r="",e=i(t);if(e<0||e==Infinity)throw RangeError("Count can't be negative");for(;0>>=1)&&(n+=n))1&e&&(r+=n);return r}},function(t,n){t.exports=Math.sign||function sign(t){return 0==(t=+t)||t!=t?t:t<0?-1:1}},function(t,n){var r=Math.expm1;t.exports=!r||22025.465794806718>1,s=23===n?F(2,-24)-F(2,-77):0,l=0,h=t<0||0===t&&1/t<0?1:0;for((t=P(t))!=t||t===M?(i=t!=t?1:0,e=a):(e=A(k(t)/N),t*(o=F(2,-e))<1&&(e--,o*=2),2<=(t+=1<=e+f?s/o:s*F(2,1-f))*o&&(e++,o/=2),a<=e+f?(i=0,e=a):1<=e+f?(i=(t*o-1)*F(2,n),e+=f):(i=t*F(2,f-1)*F(2,n),e=0));8<=n;u[l++]=255&i,i/=256,n-=8);for(e=e<>1,c=i-7,a=r-1,f=t[a--],s=127&f;for(f>>=7;0>=-c,c+=n;0>8&255]}function packI32(t){return[255&t,t>>8&255,t>>16&255,t>>24&255]}function packF64(t){return packIEEE754(t,52,8)}function packF32(t){return packIEEE754(t,23,4)}function addGetter(t,n,r){g(t[_],n,{get:function(){return this[r]}})}function get(t,n,r,e){var i=p(+r);if(t[L]>24)},setUint8:function setUint8(t,n){B.call(this,t,n<<24>>24)}},!0)}else m=function ArrayBuffer(t){s(this,m,b);var n=p(t);this._b=y.call(new Array(n),0),this[L]=n},w=function DataView(t,n,r){s(this,w,S),s(t,m,S);var e=t[L],i=l(n);if(i<0||e>24},getUint8:function getUint8(t){return get(this,1,t)[0]},getInt16:function getInt16(t){var n=get(this,2,t,arguments[1]);return(n[1]<<8|n[0])<<16>>16},getUint16:function getUint16(t){var n=get(this,2,t,arguments[1]);return n[1]<<8|n[0]},getInt32:function getInt32(t){return unpackI32(get(this,4,t,arguments[1]))},getUint32:function getUint32(t){return unpackI32(get(this,4,t,arguments[1]))>>>0},getFloat32:function getFloat32(t){return unpackIEEE754(get(this,4,t,arguments[1]),23,4)},getFloat64:function getFloat64(t){return unpackIEEE754(get(this,8,t,arguments[1]),52,8)},setInt8:function setInt8(t,n){set(this,1,t,packI8,n)},setUint8:function setUint8(t,n){set(this,1,t,packI8,n)},setInt16:function setInt16(t,n){set(this,2,t,packI16,n,arguments[2])},setUint16:function setUint16(t,n){set(this,2,t,packI16,n,arguments[2])},setInt32:function setInt32(t,n){set(this,4,t,packI32,n,arguments[2])},setUint32:function setUint32(t,n){set(this,4,t,packI32,n,arguments[2])},setFloat32:function setFloat32(t,n){set(this,4,t,packF32,n,arguments[2])}, -setFloat64:function setFloat64(t,n){set(this,8,t,packF64,n,arguments[2])}});d(m,b),d(w,S),c(w[_],u.VIEW,!0),n[b]=m,n[S]=w},function(t,n,r){t.exports=!r(7)&&!r(3)(function(){return 7!=Object.defineProperty(r(66)("div"),"a",{get:function(){return 7}}).a})},function(t,n,r){n.f=r(5)},function(t,n,r){var u=r(14),c=r(15),a=r(52)(!1),f=r(68)("IE_PROTO");t.exports=function(t,n){var r,e=c(t),i=0,o=[];for(r in e)r!=f&&u(e,r)&&o.push(r);for(;i>>0||(u.test(r)?16:10))}:e},function(t,n){t.exports=Math.log1p||function log1p(t){return-1e-8<(t=+t)&&t<1e-8?t-t*t/2:Math.log(1+t)}},function(t,n,r){var o=r(75),e=Math.pow,u=e(2,-52),c=e(2,-23),a=e(2,127)*(2-c),f=e(2,-126);t.exports=Math.fround||function fround(t){var n,r,e=Math.abs(t),i=o(t);return e>>=0)?31-Math.floor(Math.log(t+.5)*Math.LOG2E):32}})},function(t,n,r){var e=r(0),i=Math.exp;e(e.S,"Math",{cosh:function cosh(t){return(i(t=+t)+i(-t))/2}})},function(t,n,r){var e=r(0),i=r(76);e(e.S+e.F*(i!=Math.expm1),"Math",{expm1:i})},function(t,n,r){var e=r(0);e(e.S,"Math",{fround:r(107)})},function(t,n,r){var e=r(0),a=Math.abs;e(e.S,"Math",{hypot:function hypot(t,n){for(var r,e,i=0,o=0,u=arguments.length,c=0;o>>16)*u+o*(r&i>>>16)<<16>>>0)}})},function(t,n,r){var e=r(0);e(e.S,"Math",{log10:function log10(t){return Math.log(t)*Math.LOG10E}})},function(t,n,r){var e=r(0);e(e.S,"Math",{log1p:r(106)})},function(t,n,r){var e=r(0);e(e.S,"Math",{log2:function log2(t){return Math.log(t)/Math.LN2}})},function(t,n,r){var e=r(0);e(e.S,"Math",{sign:r(75)})},function(t,n,r){var e=r(0),i=r(76),o=Math.exp;e(e.S+e.F*r(3)(function(){return-2e-17!=!Math.sinh(-2e-17)}),"Math",{sinh:function sinh(t){return Math.abs(t=+t)<1?(i(t)-i(-t))/2:(o(t-1)-o(-t-1))*(Math.E/2)}})},function(t,n,r){var e=r(0),i=r(76),o=Math.exp;e(e.S,"Math",{tanh:function tanh(t){var n=i(t=+t),r=i(-t);return n==Infinity?1:r==Infinity?-1:(n-r)/(o(t)+o(-t))}})},function(t,n,r){var e=r(0);e(e.S,"Math",{trunc:function trunc(t){return(0>10),n%1024+56320))}return r.join("")}})},function(t,n,r){var e=r(0),u=r(15),c=r(6);e(e.S,"String",{raw:function raw(t){for(var n=u(t.raw),r=c(n.length),e=arguments.length,i=[],o=0;o]*>)/g,v=/\$([$&`']|\d\d?)/g;r(59)("replace",2,function(i,o,x,m){return[function replace(t,n){var r=i(this),e=t==Jt?Jt:t[o];return e!==Jt?e.call(t,r,n):x.call(String(r),t,n)},function(t,n){var r=m(x,t,this,n);if(r.done)return r.value;var e=w(t),i=String(this),o="function"==typeof n;o||(n=String(n));var u=e.global;if(u){var c=e.unicode;e.lastIndex=0}for(var a=[];;){var f=I(e,i);if( -null===f)break;if(a.push(f),!u)break;""===String(f[0])&&(e.lastIndex=M(i,E(e.lastIndex),c))}for(var s,l="",h=0,p=0;p>>0,f=new RegExp(t.source,(t.ignoreCase?"i":"")+(t.multiline?"m":"")+(t.unicode?"u":"")+(t.sticky?"y":"")+"g");(e=l.call(f,r))&&!(c<(i=f[v])&&(u.push(r.slice(c,e.index)),1>>0;if(0===a)return[];if(0===i.length)return null===m(c,i)?[i]:[];for(var f=0,s=0,l=[];s>>0,o=r>>>0;return(n>>>0)+(e>>>0)+((i&o|(i|o)&~(i+o>>>0))>>>31)|0}})},function(t,n,r){var e=r(0);e(e.S,"Math",{isubh:function isubh(t,n,r,e){var i=t>>>0,o=r>>>0;return(n>>>0)-(e>>>0)-((~i&o|~(i^o)&i-o>>>0)>>>31)|0}})},function(t,n,r){var e=r(0);e(e.S,"Math",{imulh:function imulh(t,n){var r=+t,e=+n,i=65535&r,o=65535&e,u=r>>16,c=e>>16,a=(u*o>>>0)+(i*o>>>16);return u*c+(a>>16)+((i*c>>>0)+(65535&a)>>16)}})},function(t,n,r){var e=r(0);e(e.S,"Math",{RAD_PER_DEG:180/Math.PI})},function(t,n,r){var e=r(0),i=Math.PI/180;e(e.S,"Math",{radians:function radians(t){return t*i}})},function(t,n,r){var e=r(0);e(e.S,"Math",{scale:r(128)})},function(t,n,r){var e=r(0);e(e.S,"Math",{umulh:function umulh(t,n){var r=+t,e=+n,i=65535&r,o=65535&e,u=r>>>16,c=e>>>16,a=(u*o>>>0)+(i*o>>>16);return u*c+(a>>>16)+((i*c>>>0)+(65535&a)>>>16)}})},function(t,n,r){var e=r(0);e(e.S,"Math",{signbit:function signbit(t){return(t=+t)!=t?t:0==t?1/t==Infinity:0").addClass(errClass); - errorSpan.text(err.message); - $el.after(errorSpan); - } - } else if (display === "block") { - // If block, add an error just after the el, set visibility:none on the - // el, and position the error to be on top of the el. - // Mark it with a unique ID and CSS class so we can remove it later. - $el.css("visibility", "hidden"); - if (err.message !== "") { - var errorDiv = $("
").addClass(errClass).css("position", "absolute") - .css("top", el.offsetTop) - .css("left", el.offsetLeft) - // setting width can push out the page size, forcing otherwise - // unnecessary scrollbars to appear and making it impossible for - // the element to shrink; so use max-width instead - .css("maxWidth", el.offsetWidth) - .css("height", el.offsetHeight); - errorDiv.text(err.message); - $el.after(errorDiv); - - // Really dumb way to keep the size/position of the error in sync with - // the parent element as the window is resized or whatever. - var intId = setInterval(function() { - if (!errorDiv[0].parentElement) { - clearInterval(intId); - return; - } - errorDiv - .css("top", el.offsetTop) - .css("left", el.offsetLeft) - .css("maxWidth", el.offsetWidth) - .css("height", el.offsetHeight); - }, 500); - } - } - }, - clearError: function(el) { - var $el = $(el); - var display = $el.data("restore-display-mode"); - $el.data("restore-display-mode", null); - - if (display === "inline" || display === "inline-block") { - if (display) - $el.css("display", display); - $(el.nextSibling).filter(".htmlwidgets-error").remove(); - } else if (display === "block"){ - $el.css("visibility", "inherit"); - $(el.nextSibling).filter(".htmlwidgets-error").remove(); - } - }, - sizing: {} - }; - - // Called by widget bindings to register a new type of widget. The definition - // object can contain the following properties: - // - name (required) - A string indicating the binding name, which will be - // used by default as the CSS classname to look for. - // - initialize (optional) - A function(el) that will be called once per - // widget element; if a value is returned, it will be passed as the third - // value to renderValue. - // - renderValue (required) - A function(el, data, initValue) that will be - // called with data. Static contexts will cause this to be called once per - // element; Shiny apps will cause this to be called multiple times per - // element, as the data changes. - window.HTMLWidgets.widget = function(definition) { - if (!definition.name) { - throw new Error("Widget must have a name"); - } - if (!definition.type) { - throw new Error("Widget must have a type"); - } - // Currently we only support output widgets - if (definition.type !== "output") { - throw new Error("Unrecognized widget type '" + definition.type + "'"); - } - // TODO: Verify that .name is a valid CSS classname - - // Support new-style instance-bound definitions. Old-style class-bound - // definitions have one widget "object" per widget per type/class of - // widget; the renderValue and resize methods on such widget objects - // take el and instance arguments, because the widget object can't - // store them. New-style instance-bound definitions have one widget - // object per widget instance; the definition that's passed in doesn't - // provide renderValue or resize methods at all, just the single method - // factory(el, width, height) - // which returns an object that has renderValue(x) and resize(w, h). - // This enables a far more natural programming style for the widget - // author, who can store per-instance state using either OO-style - // instance fields or functional-style closure variables (I guess this - // is in contrast to what can only be called C-style pseudo-OO which is - // what we required before). - if (definition.factory) { - definition = createLegacyDefinitionAdapter(definition); - } - - if (!definition.renderValue) { - throw new Error("Widget must have a renderValue function"); - } - - // For static rendering (non-Shiny), use a simple widget registration - // scheme. We also use this scheme for Shiny apps/documents that also - // contain static widgets. - window.HTMLWidgets.widgets = window.HTMLWidgets.widgets || []; - // Merge defaults into the definition; don't mutate the original definition. - var staticBinding = extend({}, defaults, definition); - overrideMethod(staticBinding, "find", function(superfunc) { - return function(scope) { - var results = superfunc(scope); - // Filter out Shiny outputs, we only want the static kind - return filterByClass(results, "html-widget-output", false); - }; - }); - window.HTMLWidgets.widgets.push(staticBinding); - - if (shinyMode) { - // Shiny is running. Register the definition with an output binding. - // The definition itself will not be the output binding, instead - // we will make an output binding object that delegates to the - // definition. This is because we foolishly used the same method - // name (renderValue) for htmlwidgets definition and Shiny bindings - // but they actually have quite different semantics (the Shiny - // bindings receive data that includes lots of metadata that it - // strips off before calling htmlwidgets renderValue). We can't - // just ignore the difference because in some widgets it's helpful - // to call this.renderValue() from inside of resize(), and if - // we're not delegating, then that call will go to the Shiny - // version instead of the htmlwidgets version. - - // Merge defaults with definition, without mutating either. - var bindingDef = extend({}, defaults, definition); - - // This object will be our actual Shiny binding. - var shinyBinding = new Shiny.OutputBinding(); - - // With a few exceptions, we'll want to simply use the bindingDef's - // version of methods if they are available, otherwise fall back to - // Shiny's defaults. NOTE: If Shiny's output bindings gain additional - // methods in the future, and we want them to be overrideable by - // HTMLWidget binding definitions, then we'll need to add them to this - // list. - delegateMethod(shinyBinding, bindingDef, "getId"); - delegateMethod(shinyBinding, bindingDef, "onValueChange"); - delegateMethod(shinyBinding, bindingDef, "onValueError"); - delegateMethod(shinyBinding, bindingDef, "renderError"); - delegateMethod(shinyBinding, bindingDef, "clearError"); - delegateMethod(shinyBinding, bindingDef, "showProgress"); - - // The find, renderValue, and resize are handled differently, because we - // want to actually decorate the behavior of the bindingDef methods. - - shinyBinding.find = function(scope) { - var results = bindingDef.find(scope); - - // Only return elements that are Shiny outputs, not static ones - var dynamicResults = results.filter(".html-widget-output"); - - // It's possible that whatever caused Shiny to think there might be - // new dynamic outputs, also caused there to be new static outputs. - // Since there might be lots of different htmlwidgets bindings, we - // schedule execution for later--no need to staticRender multiple - // times. - if (results.length !== dynamicResults.length) - scheduleStaticRender(); - - return dynamicResults; - }; - - // Wrap renderValue to handle initialization, which unfortunately isn't - // supported natively by Shiny at the time of this writing. - - shinyBinding.renderValue = function(el, data) { - Shiny.renderDependencies(data.deps); - // Resolve strings marked as javascript literals to objects - if (!(data.evals instanceof Array)) data.evals = [data.evals]; - for (var i = 0; data.evals && i < data.evals.length; i++) { - window.HTMLWidgets.evaluateStringMember(data.x, data.evals[i]); - } - if (!bindingDef.renderOnNullValue) { - if (data.x === null) { - el.style.visibility = "hidden"; - return; - } else { - el.style.visibility = "inherit"; - } - } - if (!elementData(el, "initialized")) { - initSizing(el); - - elementData(el, "initialized", true); - if (bindingDef.initialize) { - var rect = el.getBoundingClientRect(); - var result = bindingDef.initialize(el, rect.width, rect.height); - elementData(el, "init_result", result); - } - } - bindingDef.renderValue(el, data.x, elementData(el, "init_result")); - evalAndRun(data.jsHooks.render, elementData(el, "init_result"), [el, data.x]); - }; - - // Only override resize if bindingDef implements it - if (bindingDef.resize) { - shinyBinding.resize = function(el, width, height) { - // Shiny can call resize before initialize/renderValue have been - // called, which doesn't make sense for widgets. - if (elementData(el, "initialized")) { - bindingDef.resize(el, width, height, elementData(el, "init_result")); - } - }; - } - - Shiny.outputBindings.register(shinyBinding, bindingDef.name); - } - }; - - var scheduleStaticRenderTimerId = null; - function scheduleStaticRender() { - if (!scheduleStaticRenderTimerId) { - scheduleStaticRenderTimerId = setTimeout(function() { - scheduleStaticRenderTimerId = null; - window.HTMLWidgets.staticRender(); - }, 1); - } - } - - // Render static widgets after the document finishes loading - // Statically render all elements that are of this widget's class - window.HTMLWidgets.staticRender = function() { - var bindings = window.HTMLWidgets.widgets || []; - forEach(bindings, function(binding) { - var matches = binding.find(document.documentElement); - forEach(matches, function(el) { - var sizeObj = initSizing(el, binding); - - var getSize = function(el) { - if (sizeObj) { - return {w: sizeObj.getWidth(), h: sizeObj.getHeight()} - } else { - var rect = el.getBoundingClientRect(); - return {w: rect.width, h: rect.height} - } - }; - - if (hasClass(el, "html-widget-static-bound")) - return; - el.className = el.className + " html-widget-static-bound"; - - var initResult; - if (binding.initialize) { - var size = getSize(el); - initResult = binding.initialize(el, size.w, size.h); - elementData(el, "init_result", initResult); - } - - if (binding.resize) { - var lastSize = getSize(el); - var resizeHandler = function(e) { - var size = getSize(el); - if (size.w === 0 && size.h === 0) - return; - if (size.w === lastSize.w && size.h === lastSize.h) - return; - lastSize = size; - binding.resize(el, size.w, size.h, initResult); - }; - - on(window, "resize", resizeHandler); - - // This is needed for cases where we're running in a Shiny - // app, but the widget itself is not a Shiny output, but - // rather a simple static widget. One example of this is - // an rmarkdown document that has runtime:shiny and widget - // that isn't in a render function. Shiny only knows to - // call resize handlers for Shiny outputs, not for static - // widgets, so we do it ourselves. - if (window.jQuery) { - window.jQuery(document).on( - "shown.htmlwidgets shown.bs.tab.htmlwidgets shown.bs.collapse.htmlwidgets", - resizeHandler - ); - window.jQuery(document).on( - "hidden.htmlwidgets hidden.bs.tab.htmlwidgets hidden.bs.collapse.htmlwidgets", - resizeHandler - ); - } - - // This is needed for the specific case of ioslides, which - // flips slides between display:none and display:block. - // Ideally we would not have to have ioslide-specific code - // here, but rather have ioslides raise a generic event, - // but the rmarkdown package just went to CRAN so the - // window to getting that fixed may be long. - if (window.addEventListener) { - // It's OK to limit this to window.addEventListener - // browsers because ioslides itself only supports - // such browsers. - on(document, "slideenter", resizeHandler); - on(document, "slideleave", resizeHandler); - } - } - - var scriptData = document.querySelector("script[data-for='" + el.id + "'][type='application/json']"); - if (scriptData) { - var data = JSON.parse(scriptData.textContent || scriptData.text); - // Resolve strings marked as javascript literals to objects - if (!(data.evals instanceof Array)) data.evals = [data.evals]; - for (var k = 0; data.evals && k < data.evals.length; k++) { - window.HTMLWidgets.evaluateStringMember(data.x, data.evals[k]); - } - binding.renderValue(el, data.x, initResult); - evalAndRun(data.jsHooks.render, initResult, [el, data.x]); - } - }); - }); - - invokePostRenderHandlers(); - } - - - function has_jQuery3() { - if (!window.jQuery) { - return false; - } - var $version = window.jQuery.fn.jquery; - var $major_version = parseInt($version.split(".")[0]); - return $major_version >= 3; - } - - /* - / Shiny 1.4 bumped jQuery from 1.x to 3.x which means jQuery's - / on-ready handler (i.e., $(fn)) is now asyncronous (i.e., it now - / really means $(setTimeout(fn)). - / https://jquery.com/upgrade-guide/3.0/#breaking-change-document-ready-handlers-are-now-asynchronous - / - / Since Shiny uses $() to schedule initShiny, shiny>=1.4 calls initShiny - / one tick later than it did before, which means staticRender() is - / called renderValue() earlier than (advanced) widget authors might be expecting. - / https://github.com/rstudio/shiny/issues/2630 - / - / For a concrete example, leaflet has some methods (e.g., updateBounds) - / which reference Shiny methods registered in initShiny (e.g., setInputValue). - / Since leaflet is privy to this life-cycle, it knows to use setTimeout() to - / delay execution of those methods (until Shiny methods are ready) - / https://github.com/rstudio/leaflet/blob/18ec981/javascript/src/index.js#L266-L268 - / - / Ideally widget authors wouldn't need to use this setTimeout() hack that - / leaflet uses to call Shiny methods on a staticRender(). In the long run, - / the logic initShiny should be broken up so that method registration happens - / right away, but binding happens later. - */ - function maybeStaticRenderLater() { - if (shinyMode && has_jQuery3()) { - window.jQuery(window.HTMLWidgets.staticRender); - } else { - window.HTMLWidgets.staticRender(); - } - } - - if (document.addEventListener) { - document.addEventListener("DOMContentLoaded", function() { - document.removeEventListener("DOMContentLoaded", arguments.callee, false); - maybeStaticRenderLater(); - }, false); - } else if (document.attachEvent) { - document.attachEvent("onreadystatechange", function() { - if (document.readyState === "complete") { - document.detachEvent("onreadystatechange", arguments.callee); - maybeStaticRenderLater(); - } - }); - } - - - window.HTMLWidgets.getAttachmentUrl = function(depname, key) { - // If no key, default to the first item - if (typeof(key) === "undefined") - key = 1; - - var link = document.getElementById(depname + "-" + key + "-attachment"); - if (!link) { - throw new Error("Attachment " + depname + "/" + key + " not found in document"); - } - return link.getAttribute("href"); - }; - - window.HTMLWidgets.dataframeToD3 = function(df) { - var names = []; - var length; - for (var name in df) { - if (df.hasOwnProperty(name)) - names.push(name); - if (typeof(df[name]) !== "object" || typeof(df[name].length) === "undefined") { - throw new Error("All fields must be arrays"); - } else if (typeof(length) !== "undefined" && length !== df[name].length) { - throw new Error("All fields must be arrays of the same length"); - } - length = df[name].length; - } - var results = []; - var item; - for (var row = 0; row < length; row++) { - item = {}; - for (var col = 0; col < names.length; col++) { - item[names[col]] = df[names[col]][row]; - } - results.push(item); - } - return results; - }; - - window.HTMLWidgets.transposeArray2D = function(array) { - if (array.length === 0) return array; - var newArray = array[0].map(function(col, i) { - return array.map(function(row) { - return row[i] - }) - }); - return newArray; - }; - // Split value at splitChar, but allow splitChar to be escaped - // using escapeChar. Any other characters escaped by escapeChar - // will be included as usual (including escapeChar itself). - function splitWithEscape(value, splitChar, escapeChar) { - var results = []; - var escapeMode = false; - var currentResult = ""; - for (var pos = 0; pos < value.length; pos++) { - if (!escapeMode) { - if (value[pos] === splitChar) { - results.push(currentResult); - currentResult = ""; - } else if (value[pos] === escapeChar) { - escapeMode = true; - } else { - currentResult += value[pos]; - } - } else { - currentResult += value[pos]; - escapeMode = false; - } - } - if (currentResult !== "") { - results.push(currentResult); - } - return results; - } - // Function authored by Yihui/JJ Allaire - window.HTMLWidgets.evaluateStringMember = function(o, member) { - var parts = splitWithEscape(member, '.', '\\'); - for (var i = 0, l = parts.length; i < l; i++) { - var part = parts[i]; - // part may be a character or 'numeric' member name - if (o !== null && typeof o === "object" && part in o) { - if (i == (l - 1)) { // if we are at the end of the line then evalulate - if (typeof o[part] === "string") - o[part] = tryEval(o[part]); - } else { // otherwise continue to next embedded object - o = o[part]; - } - } - } - }; - - // Retrieve the HTMLWidget instance (i.e. the return value of an - // HTMLWidget binding's initialize() or factory() function) - // associated with an element, or null if none. - window.HTMLWidgets.getInstance = function(el) { - return elementData(el, "init_result"); - }; - - // Finds the first element in the scope that matches the selector, - // and returns the HTMLWidget instance (i.e. the return value of - // an HTMLWidget binding's initialize() or factory() function) - // associated with that element, if any. If no element matches the - // selector, or the first matching element has no HTMLWidget - // instance associated with it, then null is returned. - // - // The scope argument is optional, and defaults to window.document. - window.HTMLWidgets.find = function(scope, selector) { - if (arguments.length == 1) { - selector = scope; - scope = document; - } - - var el = scope.querySelector(selector); - if (el === null) { - return null; - } else { - return window.HTMLWidgets.getInstance(el); - } - }; - - // Finds all elements in the scope that match the selector, and - // returns the HTMLWidget instances (i.e. the return values of - // an HTMLWidget binding's initialize() or factory() function) - // associated with the elements, in an array. If elements that - // match the selector don't have an associated HTMLWidget - // instance, the returned array will contain nulls. - // - // The scope argument is optional, and defaults to window.document. - window.HTMLWidgets.findAll = function(scope, selector) { - if (arguments.length == 1) { - selector = scope; - scope = document; - } - - var nodes = scope.querySelectorAll(selector); - var results = []; - for (var i = 0; i < nodes.length; i++) { - results.push(window.HTMLWidgets.getInstance(nodes[i])); - } - return results; - }; - - var postRenderHandlers = []; - function invokePostRenderHandlers() { - while (postRenderHandlers.length) { - var handler = postRenderHandlers.shift(); - if (handler) { - handler(); - } - } - } - - // Register the given callback function to be invoked after the - // next time static widgets are rendered. - window.HTMLWidgets.addPostRenderHandler = function(callback) { - postRenderHandlers.push(callback); - }; - - // Takes a new-style instance-bound definition, and returns an - // old-style class-bound definition. This saves us from having - // to rewrite all the logic in this file to accomodate both - // types of definitions. - function createLegacyDefinitionAdapter(defn) { - var result = { - name: defn.name, - type: defn.type, - initialize: function(el, width, height) { - return defn.factory(el, width, height); - }, - renderValue: function(el, x, instance) { - return instance.renderValue(x); - }, - resize: function(el, width, height, instance) { - return instance.resize(width, height); - } - }; - - if (defn.find) - result.find = defn.find; - if (defn.renderError) - result.renderError = defn.renderError; - if (defn.clearError) - result.clearError = defn.clearError; - - return result; - } -})(); diff --git a/pr-preview/pr-358/articles/data_dictionary_files/react-18.2.0/AUTHORS b/pr-preview/pr-358/articles/data_dictionary_files/react-18.2.0/AUTHORS deleted file mode 100644 index 770cdc8c..00000000 --- a/pr-preview/pr-358/articles/data_dictionary_files/react-18.2.0/AUTHORS +++ /dev/null @@ -1,696 +0,0 @@ -39 <8398a7@gmail.com> -Aaron Franks -Aaron Gelter -Adam Bloomston -Adam Krebs -Adam Mark -Adam Solove -Adam Timberlake -Adam Zapletal -Ahmad Wali Sidiqi -Alan Plum -Alan Souza -Alan deLevie -Alastair Hole -Alex -Alex Boatwright -Alex Boyd -Alex Dajani -Alex Lopatin -Alex Mykyta -Alex Pien -Alex Smith -Alex Zelenskiy -Alexander Shtuchkin -Alexander Solovyov -Alexander Tseung -Alexandre Gaudencio -Alexey Raspopov -Alexey Shamrin -Ali Ukani -Andre Z Sanchez -Andreas Savvides -Andreas Svensson -Andres Kalle -Andres Suarez -Andrew Clark -Andrew Cobby -Andrew Davey -Andrew Henderson -Andrew Kulakov -Andrew Rasmussen -Andrew Sokolov -Andrew Zich -Andrey Popp <8mayday@gmail.com> -Anthony van der Hoorn -Anto Aravinth -Antonio Ruberto -Antti Ahti -Anuj Tomar -AoDev -April Arcus -Areeb Malik -Aria Buckles -Aria Stewart -Arian Faurtosh -Artem Nezvigin -Austin Wright -Ayman Osman -Baraa Hamodi -Bartosz Kaszubowski -Basarat Ali Syed -Battaile Fauber -Beau Smith -Ben Alpert -Ben Anderson -Ben Brooks -Ben Foxall -Ben Halpern -Ben Jaffe -Ben Moss -Ben Newman -Ben Ripkens -Benjamin Keen -Benjamin Leiken -Benjamin Woodruff -Benjy Cui -Bill Blanchard -Bill Fisher -Blaine Hatab -Blaine Kasten -Bob Eagan -Bob Ralian -Bob Renwick -Bobby -Bojan Mihelac -Bradley Spaulding -Brandon Bloom -Brandon Tilley -Brenard Cubacub -Brian Cooke -Brian Holt -Brian Hsu -Brian Kim -Brian Kung -Brian Reavis -Brian Rue -Bruno Škvorc -Cam Song -Cam Spiers -Cameron Chamberlain -Cameron Matheson -Carter Chung -Cassus Adam Banko -Cat Chen -Cedric Sohrauer -Cesar William Alvarenga -Changsoon Bok -Charles Marsh -Chase Adams -Cheng Lou -Chitharanjan Das -Chris Bolin -Chris Grovers -Chris Ha -Chris Rebert -Chris Sciolla -Christian Alfoni -Christian Oliff -Christian Roman -Christoffer Sawicki -Christoph Pojer -Christopher Monsanto -Clay Allsopp -Connor McSheffrey -Conor Hastings -Cory House -Cotton Hou -Craig Akimoto -Cristovao Verstraeten -Damien Pellier -Dan Abramov -Dan Fox -Dan Schafer -Daniel Carlsson -Daniel Cousens -Daniel Friesen -Daniel Gasienica -Daniel Hejl -Daniel Hejl -Daniel Lo Nigro -Daniel Mané -Daniel Miladinov -Daniel Rodgers-Pryor -Daniel Schonfeld -Danny Ben-David -Darcy -Daryl Lau -Darío Javier Cravero -Dave Galbraith -David Baker -David Ed Mellum -David Goldberg -David Granado -David Greenspan -David Hellsing -David Hu -David Khourshid -David Mininger -David Neubauer -David Percy -Dean Shi -Denis Sokolov -Deniss Jacenko -Dennis Johnson -Devon Blandin -Devon Harvey -Dmitrii Abramov -Dmitriy Rozhkov -Dmitry Blues -Dmitry Mazuro -Domenico Matteo -Don Abrams -Dongsheng Liu -Dustan Kasten -Dustin Getz -Dylan Harrington -Eduardo Garcia -Edvin Erikson -Elaine Fang -Enguerran -Eric Clemmons -Eric Eastwood -Eric Florenzano -Eric O'Connell -Eric Schoffstall -Erik Harper -Espen Hovlandsdal -Evan Coonrod -Evan Vosberg -Fabio M. Costa -Federico Rampazzo -Felipe Oliveira Carvalho -Felix Gnass -Felix Kling -Fernando Correia -Frankie Bagnardi -François-Xavier Bois -Fred Zhao -Freddy Rangel -Fyodor Ivanishchev -G Scott Olson -G. Kay Lee -Gabe Levi -Gajus Kuizinas -Gareth Nicholson -Garren Smith -Gavin McQuistin -Geert Pasteels -Geert-Jan Brits -George A Sisco III -Georgii Dolzhykov -Gilbert -Glen Mailer -Grant Timmerman -Greg Hurrell -Greg Perkins -Greg Roodt -Gregory -Guangqiang Dong -Guido Bouman -Harry Hull -Harry Marr -Harry Moreno -Harshad Sabne -Hekar Khani -Hendrik Swanepoel -Henrik Nyh -Henry Wong -Henry Zhu -Hideo Matsumoto -Hou Chia -Huang-Wei Chang -Hugo Agbonon -Hugo Jobling -Hyeock Kwon -Héliton Nordt -Ian Obermiller -Ignacio Carbajo -Igor Scekic -Ilia Pavlenkov -Ilya Shuklin -Ilyá Belsky -Ingvar Stepanyan -Irae Carvalho -Isaac Salier-Hellendag -Iurii Kucherov -Ivan Kozik -Ivan Krechetov -Ivan Vergiliev -J. Andrew Brassington -J. Renée Beach -JD Isaacks -JJ Weber -JW -Jack Zhang -Jackie Wung -Jacob Gable -Jacob Greenleaf -Jae Hun Ro -Jaeho Lee -Jaime Mingo -Jake Worth -Jakub Malinowski -James -James Brantly -James Burnett -James Friend -James Ide -James Long -James Pearce -James Seppi -James South -James Wen -Jamie Wong -Jamis Charles -Jamison Dance -Jan Hancic -Jan Kassens -Jan Raasch -Jared Forsyth -Jason -Jason Bonta -Jason Ly -Jason Miller -Jason Quense -Jason Trill -Jason Webster -Jay Jaeho Lee -Jean Lauliac -Jed Watson -Jeff Barczewski -Jeff Carpenter -Jeff Chan -Jeff Hicken -Jeff Kolesky -Jeff Morrison -Jeff Welch -Jeffrey Lin -Jeremy Fairbank -Jesse Skinner -Jignesh Kakadiya -Jim OBrien -Jim Sproch -Jimmy Jea -Jing Chen -Jinwoo Oh -Jinxiu Lee -Jiyeon Seo -Jody McIntyre -Joe Critchley -Joe Stein -Joel Auterson -Johannes Baiter -Johannes Emerich -Johannes Lumpe -John Heroy -John Ryan -John Watson -John-David Dalton -Jon Beebe -Jon Chester -Jon Hester -Jon Madison -Jon Scott Clark -Jon Tewksbury -Jonas Enlund -Jonas Gebhardt -Jonathan Hsu -Jonathan Persson -Jordan Harband -Jordan Walke -Jorrit Schippers -Joseph Nudell -Joseph Savona -Josh Bassett -Josh Duck -Josh Perez -Josh Yudaken -Joshua Evans -Joshua Go -Joshua Goldberg -Joshua Ma -João Valente -Juan Serrano -Julen Ruiz Aizpuru -Julian Viereck -Julien Bordellier -Julio Lopez -Jun Wu -Juraj Dudak -Justas Brazauskas -Justin Jaffray -Justin Robison -Justin Woo -Kale -Kamron Batman -Karl Mikkelsen -Karpich Dmitry -Keito Uchiyama -Ken Powers -Kent C. Dodds -Kevin Cheng <09chengk@gmail.com> -Kevin Coughlin -Kevin Huang -Kevin Lau -Kevin Old -Kevin Robinson -Kewei Jiang -Kier Borromeo -KimCoding -Kirk Steven Hansen -Kit Randel -Kohei TAKATA -Koo Youngmin -Krystian Karczewski -Kunal Mehta -Kurt Ruppel -Kyle Kelley -Kyle Mathews -Laurence Rowe -Laurent Etiemble -Lee Byron -Lee Jaeyoung -Lei -Leland Richardson -Leon Fedotov -Leon Yip -Leonardo YongUk Kim -Levi Buzolic -Levi McCallum -Lily -Logan Allen -Lovisa Svallingson -Ludovico Fischer -Luigy Leon -Luke Horvat -MIKAMI Yoshiyuki -Maher Beg -Manas -Marcin K. -Marcin Kwiatkowski -Marcin Szczepanski -Mariano Desanze -Marjan -Mark Anderson -Mark Funk -Mark Hintz -Mark IJbema -Mark Murphy -Mark Richardson -Mark Rushakoff -Mark Sun -Marlon Landaverde -Marshall Roch -Martin Andert -Martin Hujer -Martin Jul -Martin Konicek -Martin Mihaylov -Masaki KOBAYASHI -Mathieu M-Gosselin -Mathieu Savy -Matias Singers -Matsunoki -Matt Brookes -Matt Dunn-Rankin -Matt Harrison -Matt Huggins -Matt Stow -Matt Zabriskie -Matthew Dapena-Tretter -Matthew Herbst -Matthew Hodgson -Matthew Johnston -Matthew King -Matthew Looi -Matthew Miner -Matthias Le Brun -Matti Nelimarkka -Mattijs Kneppers -Max F. Albrecht <1@178.is> -Max Heiber -Max Stoiber -Maxi Ferreira -Maxim Abramchuk -Merrick Christensen -Mert Kahyaoğlu -Michael Chan -Michael McDermott -Michael Randers-Pehrson -Michael Ridgway -Michael Warner -Michael Wiencek -Michael Ziwisky -Michal Srb -Michelle Todd -Mihai Parparita -Mike D Pilsbury -Mike Groseclose -Mike Nordick -Mikolaj Dadela -Miles Johnson -Minwe LUO -Miorel Palii -Morhaus -Moshe Kolodny -Mouad Debbar -Murad -Murray M. Moss -Nadeesha Cabral -Naman Goel -Nate Hunzaker -Nate Lee -Nathan Smith -Nathan White -Nee <944316342@qq.com> -Neri Marschik -Nguyen Truong Duy -Nicholas Bergson-Shilcock -Nicholas Clawson -Nick Balestra -Nick Fitzgerald -Nick Gavalas -Nick Merwin -Nick Presta -Nick Raienko -Nick Thompson -Nick Williams -Niklas Boström -Ning Xia -Niole Nelson -Oiva Eskola -Oleg -Oleksii Markhovskyi -Oliver Zeigermann -Olivier Tassinari -Owen Coutts -Pablo Lacerda de Miranda -Paolo Moretti -Pascal Hartig -Patrick -Patrick Laughlin -Patrick Stapleton -Paul Benigeri -Paul Harper -Paul O’Shannessy -Paul Seiffert -Paul Shen -Pedro Nauck -Pete Hunt -Peter Blazejewicz -Peter Cottle -Peter Jaros -Peter Newnham -Petri Lehtinen -Petri Lievonen -Pieter Vanderwerff -Pouja Nikray -Prathamesh Sonpatki -Prayag Verma -Preston Parry -Rafael -Rafal Dittwald -Rainer Oviir -Rajat Sehgal -Rajiv Tirumalareddy -Ram Kaniyur -Randall Randall -Ray -Raymond Ha -Reed Loden -Remko Tronçon -Richard D. Worth -Richard Feldman -Richard Kho -Richard Littauer -Richard Livesey -Richard Wood -Rick Beerendonk -Rick Ford -Riley Tomasek -Rob Arnold -Robert Binna -Robert Knight -Robert Sedovsek -Robin Berjon -Robin Frischmann -Roman Pominov -Roman Vanesyan -Russ -Ryan Seddon -Sahat Yalkabov -Saif Hakim -Saiichi Hashimoto -Sam Beveridge -Sam Saccone -Sam Selikoff -Samy Al Zahrani -Sander Spies -Scott Burch -Scott Feeney -Sean Kinsey -Sebastian Markbåge -Sebastian McKenzie -Seoh Char -Sercan Eraslan -Serg -Sergey Generalov -Sergey Rubanov -Seyi Adebajo -Shane O'Sullivan -Shaun Trennery -ShihChi Huang -Shim Won -Shinnosuke Watanabe -Shogun Sea -Shota Kubota -Shripad K -Sibi -Simen Bekkhus -Simon Højberg -Simon Welsh -Simone Vittori -Soichiro Kawamura -Sophia Westwood -Sota Ohara -Spencer Handley -Stefan Dombrowski -Stephen Murphy -Sterling Cobb -Steve Baker <_steve_@outlook.com> -Steven Luscher -Steven Vachon -Stoyan Stefanov -Sundeep Malladi -Sunny Juneja -Sven Helmberger -Sverre Johansen -Sébastien Lorber -Sławomir Laskowski -Taeho Kim -Tay Yang Shun -Ted Kim -Tengfei Guo -Teodor Szente -Thomas Aylott -Thomas Boyt -Thomas Broadley -Thomas Reggi -Thomas Röggla -Thomas Shaddox -Thomas Shafer -ThomasCrvsr -Tienchai Wirojsaksaree -Tim Routowicz -Tim Schaub -Timothy Yung -Timur Carpeev -Tobias Reiss -Tom Duncalf -Tom Haggie -Tom Hauburger -Tom MacWright -Tom Occhino -Tomasz Kołodziejski -Tomoya Suzuki -Tony Spiro -Toru Kobayashi -Trinh Hoang Nhu -Tsung Hung -Tyler Brock -Ustin Zarubin -Vadim Chernysh -Varun Rau -Vasiliy Loginevskiy -Victor Alvarez -Victor Homyakov -Victor Koenders -Ville Immonen -Vincent Riemer -Vincent Siao -Vipul A M -Vitaly Kramskikh -Vitor Balocco -Vjeux -Volkan Unsal -Wander Wang -Wayne Larsen -WickyNilliams -Wincent Colaiuta -Wout Mertens -Xavier Morel -XuefengWu -Yakov Dalinchuk -Yasar icli -YouBao Nong -Yuichi Hagio -Yuriy Dybskiy -Yutaka Nakajima -Yuval Dekel -Zach Bruggeman -Zach Ramaekers -Zacharias -Zeke Sikelianos -Zhangjd -adraeth -arush -brafdlog -chen -clariroid -claudiopro -cutbko -davidxi -dongmeng.ldm -iamchenxin -iamdoron -iawia002 -imagentleman -koh-taka -kohashi85 -laiso -leeyoungalias -li.li -maxprafferty -rgarifullin -songawee -sugarshin -wali-s -yiminghe -youmoo -zhangjg -zwhitchcox -Árni Hermann Reynisson -元彦 -凌恒 -张敏 diff --git a/pr-preview/pr-358/articles/data_dictionary_files/react-18.2.0/LICENSE.txt b/pr-preview/pr-358/articles/data_dictionary_files/react-18.2.0/LICENSE.txt deleted file mode 100644 index 188fb2b0..00000000 --- a/pr-preview/pr-358/articles/data_dictionary_files/react-18.2.0/LICENSE.txt +++ /dev/null @@ -1,21 +0,0 @@ -MIT License - -Copyright (c) 2013-present, Facebook, Inc. - -Permission is hereby granted, free of charge, to any person obtaining a copy -of this software and associated documentation files (the "Software"), to deal -in the Software without restriction, including without limitation the rights -to use, copy, modify, merge, publish, distribute, sublicense, and/or sell -copies of the Software, and to permit persons to whom the Software is -furnished to do so, subject to the following conditions: - -The above copyright notice and this permission notice shall be included in all -copies or substantial portions of the Software. - -THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR -IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, -FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE -AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER -LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, -OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE -SOFTWARE. diff --git a/pr-preview/pr-358/articles/data_dictionary_files/react-18.2.0/react-dom.min.js b/pr-preview/pr-358/articles/data_dictionary_files/react-18.2.0/react-dom.min.js deleted file mode 100644 index 4578fc9b..00000000 --- a/pr-preview/pr-358/articles/data_dictionary_files/react-18.2.0/react-dom.min.js +++ /dev/null @@ -1,267 +0,0 @@ -/** - * @license React - * react-dom.production.min.js - * - * Copyright (c) Facebook, Inc. and its affiliates. - * - * This source code is licensed under the MIT license found in the - * LICENSE file in the root directory of this source tree. - */ -(function(){/* - Modernizr 3.0.0pre (Custom Build) | MIT -*/ -'use strict';(function(Q,mb){"object"===typeof exports&&"undefined"!==typeof module?mb(exports,require("react")):"function"===typeof define&&define.amd?define(["exports","react"],mb):(Q=Q||self,mb(Q.ReactDOM={},Q.React))})(this,function(Q,mb){function n(a){for(var b="https://reactjs.org/docs/error-decoder.html?invariant="+a,c=1;cb}return!1}function Y(a,b,c,d,e,f,g){this.acceptsBooleans=2===b||3===b||4===b;this.attributeName=d;this.attributeNamespace=e;this.mustUseProperty=c;this.propertyName=a;this.type=b;this.sanitizeURL=f;this.removeEmptyString=g}function $d(a,b,c,d){var e=R.hasOwnProperty(b)?R[b]:null;if(null!==e?0!==e.type:d||!(2h||e[g]!==f[h]){var k="\n"+e[g].replace(" at new "," at ");a.displayName&&k.includes("")&&(k=k.replace("",a.displayName));return k}while(1<=g&&0<=h)}break}}}finally{ce=!1,Error.prepareStackTrace=c}return(a=a?a.displayName||a.name:"")?bc(a): -""}function gj(a){switch(a.tag){case 5:return bc(a.type);case 16:return bc("Lazy");case 13:return bc("Suspense");case 19:return bc("SuspenseList");case 0:case 2:case 15:return a=be(a.type,!1),a;case 11:return a=be(a.type.render,!1),a;case 1:return a=be(a.type,!0),a;default:return""}}function de(a){if(null==a)return null;if("function"===typeof a)return a.displayName||a.name||null;if("string"===typeof a)return a;switch(a){case Bb:return"Fragment";case Cb:return"Portal";case ee:return"Profiler";case fe:return"StrictMode"; -case ge:return"Suspense";case he:return"SuspenseList"}if("object"===typeof a)switch(a.$$typeof){case gg:return(a.displayName||"Context")+".Consumer";case hg:return(a._context.displayName||"Context")+".Provider";case ie:var b=a.render;a=a.displayName;a||(a=b.displayName||b.name||"",a=""!==a?"ForwardRef("+a+")":"ForwardRef");return a;case je:return b=a.displayName||null,null!==b?b:de(a.type)||"Memo";case Ta:b=a._payload;a=a._init;try{return de(a(b))}catch(c){}}return null}function hj(a){var b=a.type; -switch(a.tag){case 24:return"Cache";case 9:return(b.displayName||"Context")+".Consumer";case 10:return(b._context.displayName||"Context")+".Provider";case 18:return"DehydratedFragment";case 11:return a=b.render,a=a.displayName||a.name||"",b.displayName||(""!==a?"ForwardRef("+a+")":"ForwardRef");case 7:return"Fragment";case 5:return b;case 4:return"Portal";case 3:return"Root";case 6:return"Text";case 16:return de(b);case 8:return b===fe?"StrictMode":"Mode";case 22:return"Offscreen";case 12:return"Profiler"; -case 21:return"Scope";case 13:return"Suspense";case 19:return"SuspenseList";case 25:return"TracingMarker";case 1:case 0:case 17:case 2:case 14:case 15:if("function"===typeof b)return b.displayName||b.name||null;if("string"===typeof b)return b}return null}function Ua(a){switch(typeof a){case "boolean":case "number":case "string":case "undefined":return a;case "object":return a;default:return""}}function ig(a){var b=a.type;return(a=a.nodeName)&&"input"===a.toLowerCase()&&("checkbox"===b||"radio"=== -b)}function ij(a){var b=ig(a)?"checked":"value",c=Object.getOwnPropertyDescriptor(a.constructor.prototype,b),d=""+a[b];if(!a.hasOwnProperty(b)&&"undefined"!==typeof c&&"function"===typeof c.get&&"function"===typeof c.set){var e=c.get,f=c.set;Object.defineProperty(a,b,{configurable:!0,get:function(){return e.call(this)},set:function(a){d=""+a;f.call(this,a)}});Object.defineProperty(a,b,{enumerable:c.enumerable});return{getValue:function(){return d},setValue:function(a){d=""+a},stopTracking:function(){a._valueTracker= -null;delete a[b]}}}}function Pc(a){a._valueTracker||(a._valueTracker=ij(a))}function jg(a){if(!a)return!1;var b=a._valueTracker;if(!b)return!0;var c=b.getValue();var d="";a&&(d=ig(a)?a.checked?"true":"false":a.value);a=d;return a!==c?(b.setValue(a),!0):!1}function Qc(a){a=a||("undefined"!==typeof document?document:void 0);if("undefined"===typeof a)return null;try{return a.activeElement||a.body}catch(b){return a.body}}function ke(a,b){var c=b.checked;return E({},b,{defaultChecked:void 0,defaultValue:void 0, -value:void 0,checked:null!=c?c:a._wrapperState.initialChecked})}function kg(a,b){var c=null==b.defaultValue?"":b.defaultValue,d=null!=b.checked?b.checked:b.defaultChecked;c=Ua(null!=b.value?b.value:c);a._wrapperState={initialChecked:d,initialValue:c,controlled:"checkbox"===b.type||"radio"===b.type?null!=b.checked:null!=b.value}}function lg(a,b){b=b.checked;null!=b&&$d(a,"checked",b,!1)}function le(a,b){lg(a,b);var c=Ua(b.value),d=b.type;if(null!=c)if("number"===d){if(0===c&&""===a.value||a.value!= -c)a.value=""+c}else a.value!==""+c&&(a.value=""+c);else if("submit"===d||"reset"===d){a.removeAttribute("value");return}b.hasOwnProperty("value")?me(a,b.type,c):b.hasOwnProperty("defaultValue")&&me(a,b.type,Ua(b.defaultValue));null==b.checked&&null!=b.defaultChecked&&(a.defaultChecked=!!b.defaultChecked)}function mg(a,b,c){if(b.hasOwnProperty("value")||b.hasOwnProperty("defaultValue")){var d=b.type;if(!("submit"!==d&&"reset"!==d||void 0!==b.value&&null!==b.value))return;b=""+a._wrapperState.initialValue; -c||b===a.value||(a.value=b);a.defaultValue=b}c=a.name;""!==c&&(a.name="");a.defaultChecked=!!a._wrapperState.initialChecked;""!==c&&(a.name=c)}function me(a,b,c){if("number"!==b||Qc(a.ownerDocument)!==a)null==c?a.defaultValue=""+a._wrapperState.initialValue:a.defaultValue!==""+c&&(a.defaultValue=""+c)}function Db(a,b,c,d){a=a.options;if(b){b={};for(var e=0;e>>=0;return 0===a?32:31-(rj(a)/sj|0)|0}function hc(a){switch(a&-a){case 1:return 1;case 2:return 2;case 4:return 4;case 8:return 8;case 16:return 16;case 32:return 32;case 64:case 128:case 256:case 512:case 1024:case 2048:case 4096:case 8192:case 16384:case 32768:case 65536:case 131072:case 262144:case 524288:case 1048576:case 2097152:return a& -4194240;case 4194304:case 8388608:case 16777216:case 33554432:case 67108864:return a&130023424;case 134217728:return 134217728;case 268435456:return 268435456;case 536870912:return 536870912;case 1073741824:return 1073741824;default:return a}}function Vc(a,b){var c=a.pendingLanes;if(0===c)return 0;var d=0,e=a.suspendedLanes,f=a.pingedLanes,g=c&268435455;if(0!==g){var h=g&~e;0!==h?d=hc(h):(f&=g,0!==f&&(d=hc(f)))}else g=c&~e,0!==g?d=hc(g):0!==f&&(d=hc(f));if(0===d)return 0;if(0!==b&&b!==d&&0===(b&e)&& -(e=d&-d,f=b&-b,e>=f||16===e&&0!==(f&4194240)))return b;0!==(d&4)&&(d|=c&16);b=a.entangledLanes;if(0!==b)for(a=a.entanglements,b&=d;0c;c++)b.push(a); -return b}function ic(a,b,c){a.pendingLanes|=b;536870912!==b&&(a.suspendedLanes=0,a.pingedLanes=0);a=a.eventTimes;b=31-ta(b);a[b]=c}function vj(a,b){var c=a.pendingLanes&~b;a.pendingLanes=b;a.suspendedLanes=0;a.pingedLanes=0;a.expiredLanes&=b;a.mutableReadLanes&=b;a.entangledLanes&=b;b=a.entanglements;var d=a.eventTimes;for(a=a.expirationTimes;0=b)return{node:c,offset:b-a};a=d}a:{for(;c;){if(c.nextSibling){c=c.nextSibling;break a}c=c.parentNode}c=void 0}c=$g(c)}}function bh(a,b){return a&&b?a===b?!0:a&&3===a.nodeType?!1:b&&3===b.nodeType?bh(a,b.parentNode):"contains"in a?a.contains(b):a.compareDocumentPosition?!!(a.compareDocumentPosition(b)&16):!1:!1}function ch(){for(var a=window,b=Qc();b instanceof a.HTMLIFrameElement;){try{var c="string"===typeof b.contentWindow.location.href}catch(d){c=!1}if(c)a=b.contentWindow;else break; -b=Qc(a.document)}return b}function Ie(a){var b=a&&a.nodeName&&a.nodeName.toLowerCase();return b&&("input"===b&&("text"===a.type||"search"===a.type||"tel"===a.type||"url"===a.type||"password"===a.type)||"textarea"===b||"true"===a.contentEditable)}function Uj(a){var b=ch(),c=a.focusedElem,d=a.selectionRange;if(b!==c&&c&&c.ownerDocument&&bh(c.ownerDocument.documentElement,c)){if(null!==d&&Ie(c))if(b=d.start,a=d.end,void 0===a&&(a=b),"selectionStart"in c)c.selectionStart=b,c.selectionEnd=Math.min(a,c.value.length); -else if(a=(b=c.ownerDocument||document)&&b.defaultView||window,a.getSelection){a=a.getSelection();var e=c.textContent.length,f=Math.min(d.start,e);d=void 0===d.end?f:Math.min(d.end,e);!a.extend&&f>d&&(e=d,d=f,f=e);e=ah(c,f);var g=ah(c,d);e&&g&&(1!==a.rangeCount||a.anchorNode!==e.node||a.anchorOffset!==e.offset||a.focusNode!==g.node||a.focusOffset!==g.offset)&&(b=b.createRange(),b.setStart(e.node,e.offset),a.removeAllRanges(),f>d?(a.addRange(b),a.extend(g.node,g.offset)):(b.setEnd(g.node,g.offset), -a.addRange(b)))}b=[];for(a=c;a=a.parentNode;)1===a.nodeType&&b.push({element:a,left:a.scrollLeft,top:a.scrollTop});"function"===typeof c.focus&&c.focus();for(c=0;cMb||(a.current=Se[Mb],Se[Mb]=null,Mb--)} -function y(a,b,c){Mb++;Se[Mb]=a.current;a.current=b}function Nb(a,b){var c=a.type.contextTypes;if(!c)return cb;var d=a.stateNode;if(d&&d.__reactInternalMemoizedUnmaskedChildContext===b)return d.__reactInternalMemoizedMaskedChildContext;var e={},f;for(f in c)e[f]=b[f];d&&(a=a.stateNode,a.__reactInternalMemoizedUnmaskedChildContext=b,a.__reactInternalMemoizedMaskedChildContext=e);return e}function ea(a){a=a.childContextTypes;return null!==a&&void 0!==a}function th(a,b,c){if(J.current!==cb)throw Error(n(168)); -y(J,b);y(S,c)}function uh(a,b,c){var d=a.stateNode;b=b.childContextTypes;if("function"!==typeof d.getChildContext)return c;d=d.getChildContext();for(var e in d)if(!(e in b))throw Error(n(108,hj(a)||"Unknown",e));return E({},c,d)}function ld(a){a=(a=a.stateNode)&&a.__reactInternalMemoizedMergedChildContext||cb;qb=J.current;y(J,a);y(S,S.current);return!0}function vh(a,b,c){var d=a.stateNode;if(!d)throw Error(n(169));c?(a=uh(a,b,qb),d.__reactInternalMemoizedMergedChildContext=a,w(S),w(J),y(J,a)):w(S); -y(S,c)}function wh(a){null===La?La=[a]:La.push(a)}function kk(a){md=!0;wh(a)}function db(){if(!Te&&null!==La){Te=!0;var a=0,b=z;try{var c=La;for(z=1;a>=g;e-=g;Ma=1<<32-ta(b)+e|c<q?(v=l,l=null):v=l.sibling;var A=r(e,l,h[q],k);if(null===A){null===l&&(l=v);break}a&&l&&null===A.alternate&&b(e,l);g=f(A,g,q);null===m?n=A:m.sibling=A;m=A;l=v}if(q===h.length)return c(e,l),D&&rb(e,q),n;if(null===l){for(;qv?(A=q,q=null):A=q.sibling;var x=r(e,q,t.value,k);if(null===x){null===q&&(q=A);break}a&&q&&null===x.alternate&&b(e,q);g=f(x,g,v);null===l?m=x:l.sibling=x;l=x;q=A}if(t.done)return c(e,q),D&&rb(e,v),m; -if(null===q){for(;!t.done;v++,t=h.next())t=u(e,t.value,k),null!==t&&(g=f(t,g,v),null===l?m=t:l.sibling=t,l=t);D&&rb(e,v);return m}for(q=d(e,q);!t.done;v++,t=h.next())t=p(q,e,v,t.value,k),null!==t&&(a&&null!==t.alternate&&q.delete(null===t.key?v:t.key),g=f(t,g,v),null===l?m=t:l.sibling=t,l=t);a&&q.forEach(function(a){return b(e,a)});D&&rb(e,v);return m}function w(a,d,f,h){"object"===typeof f&&null!==f&&f.type===Bb&&null===f.key&&(f=f.props.children);if("object"===typeof f&&null!==f){switch(f.$$typeof){case xd:a:{for(var k= -f.key,m=d;null!==m;){if(m.key===k){k=f.type;if(k===Bb){if(7===m.tag){c(a,m.sibling);d=e(m,f.props.children);d.return=a;a=d;break a}}else if(m.elementType===k||"object"===typeof k&&null!==k&&k.$$typeof===Ta&&Kh(k)===m.type){c(a,m.sibling);d=e(m,f.props);d.ref=vc(a,m,f);d.return=a;a=d;break a}c(a,m);break}else b(a,m);m=m.sibling}f.type===Bb?(d=ub(f.props.children,a.mode,h,f.key),d.return=a,a=d):(h=wd(f.type,f.key,f.props,null,a.mode,h),h.ref=vc(a,d,f),h.return=a,a=h)}return g(a);case Cb:a:{for(m=f.key;null!== -d;){if(d.key===m)if(4===d.tag&&d.stateNode.containerInfo===f.containerInfo&&d.stateNode.implementation===f.implementation){c(a,d.sibling);d=e(d,f.children||[]);d.return=a;a=d;break a}else{c(a,d);break}else b(a,d);d=d.sibling}d=hf(f,a.mode,h);d.return=a;a=d}return g(a);case Ta:return m=f._init,w(a,d,m(f._payload),h)}if(cc(f))return x(a,d,f,h);if(ac(f))return F(a,d,f,h);vd(a,f)}return"string"===typeof f&&""!==f||"number"===typeof f?(f=""+f,null!==d&&6===d.tag?(c(a,d.sibling),d=e(d,f),d.return=a,a=d): -(c(a,d),d=gf(f,a.mode,h),d.return=a,a=d),g(a)):c(a,d)}return w}function vb(a){if(a===wc)throw Error(n(174));return a}function jf(a,b){y(xc,b);y(yc,a);y(Ea,wc);a=b.nodeType;switch(a){case 9:case 11:b=(b=b.documentElement)?b.namespaceURI:oe(null,"");break;default:a=8===a?b.parentNode:b,b=a.namespaceURI||null,a=a.tagName,b=oe(b,a)}w(Ea);y(Ea,b)}function Tb(a){w(Ea);w(yc);w(xc)}function Mh(a){vb(xc.current);var b=vb(Ea.current);var c=oe(b,a.type);b!==c&&(y(yc,a),y(Ea,c))}function kf(a){yc.current===a&& -(w(Ea),w(yc))}function yd(a){for(var b=a;null!==b;){if(13===b.tag){var c=b.memoizedState;if(null!==c&&(c=c.dehydrated,null===c||"$?"===c.data||"$!"===c.data))return b}else if(19===b.tag&&void 0!==b.memoizedProps.revealOrder){if(0!==(b.flags&128))return b}else if(null!==b.child){b.child.return=b;b=b.child;continue}if(b===a)break;for(;null===b.sibling;){if(null===b.return||b.return===a)return null;b=b.return}b.sibling.return=b.return;b=b.sibling}return null}function lf(){for(var a=0;ac?c:4;a(!0);var d=uf.transition;uf.transition={};try{a(!1),b()}finally{z=c,uf.transition=d}}function di(){return sa().memoizedState}function rk(a,b, -c){var d=hb(a);c={lane:d,action:c,hasEagerState:!1,eagerState:null,next:null};if(ei(a))fi(b,c);else if(c=Ch(a,b,c,d),null!==c){var e=Z();ya(c,a,d,e);gi(c,b,d)}}function pk(a,b,c){var d=hb(a),e={lane:d,action:c,hasEagerState:!1,eagerState:null,next:null};if(ei(a))fi(b,e);else{var f=a.alternate;if(0===a.lanes&&(null===f||0===f.lanes)&&(f=b.lastRenderedReducer,null!==f))try{var g=b.lastRenderedState,h=f(g,c);e.hasEagerState=!0;e.eagerState=h;if(ua(h,g)){var k=b.interleaved;null===k?(e.next=e,cf(b)): -(e.next=k.next,k.next=e);b.interleaved=e;return}}catch(m){}finally{}c=Ch(a,b,e,d);null!==c&&(e=Z(),ya(c,a,d,e),gi(c,b,d))}}function ei(a){var b=a.alternate;return a===C||null!==b&&b===C}function fi(a,b){zc=Bd=!0;var c=a.pending;null===c?b.next=b:(b.next=c.next,c.next=b);a.pending=b}function gi(a,b,c){if(0!==(c&4194240)){var d=b.lanes;d&=a.pendingLanes;c|=d;b.lanes=c;xe(a,c)}}function Ub(a,b){try{var c="",d=b;do c+=gj(d),d=d.return;while(d);var e=c}catch(f){e="\nError generating stack: "+f.message+ -"\n"+f.stack}return{value:a,source:b,stack:e,digest:null}}function vf(a,b,c){return{value:a,source:null,stack:null!=c?c:null,digest:null!=b?b:null}}function wf(a,b){try{console.error(b.value)}catch(c){setTimeout(function(){throw c;})}}function hi(a,b,c){c=Pa(-1,c);c.tag=3;c.payload={element:null};var d=b.value;c.callback=function(){Ed||(Ed=!0,xf=d);wf(a,b)};return c}function ii(a,b,c){c=Pa(-1,c);c.tag=3;var d=a.type.getDerivedStateFromError;if("function"===typeof d){var e=b.value;c.payload=function(){return d(e)}; -c.callback=function(){wf(a,b)}}var f=a.stateNode;null!==f&&"function"===typeof f.componentDidCatch&&(c.callback=function(){wf(a,b);"function"!==typeof d&&(null===ib?ib=new Set([this]):ib.add(this));var c=b.stack;this.componentDidCatch(b.value,{componentStack:null!==c?c:""})});return c}function ji(a,b,c){var d=a.pingCache;if(null===d){d=a.pingCache=new sk;var e=new Set;d.set(b,e)}else e=d.get(b),void 0===e&&(e=new Set,d.set(b,e));e.has(c)||(e.add(c),a=tk.bind(null,a,b,c),b.then(a,a))}function ki(a){do{var b; -if(b=13===a.tag)b=a.memoizedState,b=null!==b?null!==b.dehydrated?!0:!1:!0;if(b)return a;a=a.return}while(null!==a);return null}function li(a,b,c,d,e){if(0===(a.mode&1))return a===b?a.flags|=65536:(a.flags|=128,c.flags|=131072,c.flags&=-52805,1===c.tag&&(null===c.alternate?c.tag=17:(b=Pa(-1,1),b.tag=2,eb(c,b,1))),c.lanes|=1),a;a.flags|=65536;a.lanes=e;return a}function aa(a,b,c,d){b.child=null===a?mi(b,null,c,d):Vb(b,a.child,c,d)}function ni(a,b,c,d,e){c=c.render;var f=b.ref;Sb(b,e);d=of(a,b,c,d,f, -e);c=pf();if(null!==a&&!ha)return b.updateQueue=a.updateQueue,b.flags&=-2053,a.lanes&=~e,Qa(a,b,e);D&&c&&Ue(b);b.flags|=1;aa(a,b,d,e);return b.child}function oi(a,b,c,d,e){if(null===a){var f=c.type;if("function"===typeof f&&!yf(f)&&void 0===f.defaultProps&&null===c.compare&&void 0===c.defaultProps)return b.tag=15,b.type=f,pi(a,b,f,d,e);a=wd(c.type,null,d,b,b.mode,e);a.ref=b.ref;a.return=b;return b.child=a}f=a.child;if(0===(a.lanes&e)){var g=f.memoizedProps;c=c.compare;c=null!==c?c:qc;if(c(g,d)&&a.ref=== -b.ref)return Qa(a,b,e)}b.flags|=1;a=gb(f,d);a.ref=b.ref;a.return=b;return b.child=a}function pi(a,b,c,d,e){if(null!==a){var f=a.memoizedProps;if(qc(f,d)&&a.ref===b.ref)if(ha=!1,b.pendingProps=d=f,0!==(a.lanes&e))0!==(a.flags&131072)&&(ha=!0);else return b.lanes=a.lanes,Qa(a,b,e)}return zf(a,b,c,d,e)}function qi(a,b,c){var d=b.pendingProps,e=d.children,f=null!==a?a.memoizedState:null;if("hidden"===d.mode)if(0===(b.mode&1))b.memoizedState={baseLanes:0,cachePool:null,transitions:null},y(Ga,ba),ba|=c; -else{if(0===(c&1073741824))return a=null!==f?f.baseLanes|c:c,b.lanes=b.childLanes=1073741824,b.memoizedState={baseLanes:a,cachePool:null,transitions:null},b.updateQueue=null,y(Ga,ba),ba|=a,null;b.memoizedState={baseLanes:0,cachePool:null,transitions:null};d=null!==f?f.baseLanes:c;y(Ga,ba);ba|=d}else null!==f?(d=f.baseLanes|c,b.memoizedState=null):d=c,y(Ga,ba),ba|=d;aa(a,b,e,c);return b.child}function ri(a,b){var c=b.ref;if(null===a&&null!==c||null!==a&&a.ref!==c)b.flags|=512,b.flags|=2097152}function zf(a, -b,c,d,e){var f=ea(c)?qb:J.current;f=Nb(b,f);Sb(b,e);c=of(a,b,c,d,f,e);d=pf();if(null!==a&&!ha)return b.updateQueue=a.updateQueue,b.flags&=-2053,a.lanes&=~e,Qa(a,b,e);D&&d&&Ue(b);b.flags|=1;aa(a,b,c,e);return b.child}function si(a,b,c,d,e){if(ea(c)){var f=!0;ld(b)}else f=!1;Sb(b,e);if(null===b.stateNode)Fd(a,b),Hh(b,c,d),ff(b,c,d,e),d=!0;else if(null===a){var g=b.stateNode,h=b.memoizedProps;g.props=h;var k=g.context,m=c.contextType;"object"===typeof m&&null!==m?m=qa(m):(m=ea(c)?qb:J.current,m=Nb(b, -m));var l=c.getDerivedStateFromProps,n="function"===typeof l||"function"===typeof g.getSnapshotBeforeUpdate;n||"function"!==typeof g.UNSAFE_componentWillReceiveProps&&"function"!==typeof g.componentWillReceiveProps||(h!==d||k!==m)&&Ih(b,g,d,m);fb=!1;var r=b.memoizedState;g.state=r;td(b,d,g,e);k=b.memoizedState;h!==d||r!==k||S.current||fb?("function"===typeof l&&(ef(b,c,l,d),k=b.memoizedState),(h=fb||Gh(b,c,h,d,r,k,m))?(n||"function"!==typeof g.UNSAFE_componentWillMount&&"function"!==typeof g.componentWillMount|| -("function"===typeof g.componentWillMount&&g.componentWillMount(),"function"===typeof g.UNSAFE_componentWillMount&&g.UNSAFE_componentWillMount()),"function"===typeof g.componentDidMount&&(b.flags|=4194308)):("function"===typeof g.componentDidMount&&(b.flags|=4194308),b.memoizedProps=d,b.memoizedState=k),g.props=d,g.state=k,g.context=m,d=h):("function"===typeof g.componentDidMount&&(b.flags|=4194308),d=!1)}else{g=b.stateNode;Dh(a,b);h=b.memoizedProps;m=b.type===b.elementType?h:xa(b.type,h);g.props= -m;n=b.pendingProps;r=g.context;k=c.contextType;"object"===typeof k&&null!==k?k=qa(k):(k=ea(c)?qb:J.current,k=Nb(b,k));var p=c.getDerivedStateFromProps;(l="function"===typeof p||"function"===typeof g.getSnapshotBeforeUpdate)||"function"!==typeof g.UNSAFE_componentWillReceiveProps&&"function"!==typeof g.componentWillReceiveProps||(h!==n||r!==k)&&Ih(b,g,d,k);fb=!1;r=b.memoizedState;g.state=r;td(b,d,g,e);var x=b.memoizedState;h!==n||r!==x||S.current||fb?("function"===typeof p&&(ef(b,c,p,d),x=b.memoizedState), -(m=fb||Gh(b,c,m,d,r,x,k)||!1)?(l||"function"!==typeof g.UNSAFE_componentWillUpdate&&"function"!==typeof g.componentWillUpdate||("function"===typeof g.componentWillUpdate&&g.componentWillUpdate(d,x,k),"function"===typeof g.UNSAFE_componentWillUpdate&&g.UNSAFE_componentWillUpdate(d,x,k)),"function"===typeof g.componentDidUpdate&&(b.flags|=4),"function"===typeof g.getSnapshotBeforeUpdate&&(b.flags|=1024)):("function"!==typeof g.componentDidUpdate||h===a.memoizedProps&&r===a.memoizedState||(b.flags|= -4),"function"!==typeof g.getSnapshotBeforeUpdate||h===a.memoizedProps&&r===a.memoizedState||(b.flags|=1024),b.memoizedProps=d,b.memoizedState=x),g.props=d,g.state=x,g.context=k,d=m):("function"!==typeof g.componentDidUpdate||h===a.memoizedProps&&r===a.memoizedState||(b.flags|=4),"function"!==typeof g.getSnapshotBeforeUpdate||h===a.memoizedProps&&r===a.memoizedState||(b.flags|=1024),d=!1)}return Af(a,b,c,d,f,e)}function Af(a,b,c,d,e,f){ri(a,b);var g=0!==(b.flags&128);if(!d&&!g)return e&&vh(b,c,!1), -Qa(a,b,f);d=b.stateNode;uk.current=b;var h=g&&"function"!==typeof c.getDerivedStateFromError?null:d.render();b.flags|=1;null!==a&&g?(b.child=Vb(b,a.child,null,f),b.child=Vb(b,null,h,f)):aa(a,b,h,f);b.memoizedState=d.state;e&&vh(b,c,!0);return b.child}function ti(a){var b=a.stateNode;b.pendingContext?th(a,b.pendingContext,b.pendingContext!==b.context):b.context&&th(a,b.context,!1);jf(a,b.containerInfo)}function ui(a,b,c,d,e){Qb();Ye(e);b.flags|=256;aa(a,b,c,d);return b.child}function Bf(a){return{baseLanes:a, -cachePool:null,transitions:null}}function vi(a,b,c){var d=b.pendingProps,e=G.current,f=!1,g=0!==(b.flags&128),h;(h=g)||(h=null!==a&&null===a.memoizedState?!1:0!==(e&2));if(h)f=!0,b.flags&=-129;else if(null===a||null!==a.memoizedState)e|=1;y(G,e&1);if(null===a){Xe(b);a=b.memoizedState;if(null!==a&&(a=a.dehydrated,null!==a))return 0===(b.mode&1)?b.lanes=1:"$!"===a.data?b.lanes=8:b.lanes=1073741824,null;g=d.children;a=d.fallback;return f?(d=b.mode,f=b.child,g={mode:"hidden",children:g},0===(d&1)&&null!== -f?(f.childLanes=0,f.pendingProps=g):f=Gd(g,d,0,null),a=ub(a,d,c,null),f.return=b,a.return=b,f.sibling=a,b.child=f,b.child.memoizedState=Bf(c),b.memoizedState=Cf,a):Df(b,g)}e=a.memoizedState;if(null!==e&&(h=e.dehydrated,null!==h))return vk(a,b,g,d,h,e,c);if(f){f=d.fallback;g=b.mode;e=a.child;h=e.sibling;var k={mode:"hidden",children:d.children};0===(g&1)&&b.child!==e?(d=b.child,d.childLanes=0,d.pendingProps=k,b.deletions=null):(d=gb(e,k),d.subtreeFlags=e.subtreeFlags&14680064);null!==h?f=gb(h,f):(f= -ub(f,g,c,null),f.flags|=2);f.return=b;d.return=b;d.sibling=f;b.child=d;d=f;f=b.child;g=a.child.memoizedState;g=null===g?Bf(c):{baseLanes:g.baseLanes|c,cachePool:null,transitions:g.transitions};f.memoizedState=g;f.childLanes=a.childLanes&~c;b.memoizedState=Cf;return d}f=a.child;a=f.sibling;d=gb(f,{mode:"visible",children:d.children});0===(b.mode&1)&&(d.lanes=c);d.return=b;d.sibling=null;null!==a&&(c=b.deletions,null===c?(b.deletions=[a],b.flags|=16):c.push(a));b.child=d;b.memoizedState=null;return d} -function Df(a,b,c){b=Gd({mode:"visible",children:b},a.mode,0,null);b.return=a;return a.child=b}function Hd(a,b,c,d){null!==d&&Ye(d);Vb(b,a.child,null,c);a=Df(b,b.pendingProps.children);a.flags|=2;b.memoizedState=null;return a}function vk(a,b,c,d,e,f,g){if(c){if(b.flags&256)return b.flags&=-257,d=vf(Error(n(422))),Hd(a,b,g,d);if(null!==b.memoizedState)return b.child=a.child,b.flags|=128,null;f=d.fallback;e=b.mode;d=Gd({mode:"visible",children:d.children},e,0,null);f=ub(f,e,g,null);f.flags|=2;d.return= -b;f.return=b;d.sibling=f;b.child=d;0!==(b.mode&1)&&Vb(b,a.child,null,g);b.child.memoizedState=Bf(g);b.memoizedState=Cf;return f}if(0===(b.mode&1))return Hd(a,b,g,null);if("$!"===e.data){d=e.nextSibling&&e.nextSibling.dataset;if(d)var h=d.dgst;d=h;f=Error(n(419));d=vf(f,d,void 0);return Hd(a,b,g,d)}h=0!==(g&a.childLanes);if(ha||h){d=O;if(null!==d){switch(g&-g){case 4:e=2;break;case 16:e=8;break;case 64:case 128:case 256:case 512:case 1024:case 2048:case 4096:case 8192:case 16384:case 32768:case 65536:case 131072:case 262144:case 524288:case 1048576:case 2097152:case 4194304:case 8388608:case 16777216:case 33554432:case 67108864:e= -32;break;case 536870912:e=268435456;break;default:e=0}e=0!==(e&(d.suspendedLanes|g))?0:e;0!==e&&e!==f.retryLane&&(f.retryLane=e,Oa(a,e),ya(d,a,e,-1))}Ef();d=vf(Error(n(421)));return Hd(a,b,g,d)}if("$?"===e.data)return b.flags|=128,b.child=a.child,b=wk.bind(null,a),e._reactRetry=b,null;a=f.treeContext;fa=Ka(e.nextSibling);la=b;D=!0;wa=null;null!==a&&(na[oa++]=Ma,na[oa++]=Na,na[oa++]=sb,Ma=a.id,Na=a.overflow,sb=b);b=Df(b,d.children);b.flags|=4096;return b}function wi(a,b,c){a.lanes|=b;var d=a.alternate; -null!==d&&(d.lanes|=b);bf(a.return,b,c)}function Ff(a,b,c,d,e){var f=a.memoizedState;null===f?a.memoizedState={isBackwards:b,rendering:null,renderingStartTime:0,last:d,tail:c,tailMode:e}:(f.isBackwards=b,f.rendering=null,f.renderingStartTime=0,f.last=d,f.tail=c,f.tailMode=e)}function xi(a,b,c){var d=b.pendingProps,e=d.revealOrder,f=d.tail;aa(a,b,d.children,c);d=G.current;if(0!==(d&2))d=d&1|2,b.flags|=128;else{if(null!==a&&0!==(a.flags&128))a:for(a=b.child;null!==a;){if(13===a.tag)null!==a.memoizedState&& -wi(a,c,b);else if(19===a.tag)wi(a,c,b);else if(null!==a.child){a.child.return=a;a=a.child;continue}if(a===b)break a;for(;null===a.sibling;){if(null===a.return||a.return===b)break a;a=a.return}a.sibling.return=a.return;a=a.sibling}d&=1}y(G,d);if(0===(b.mode&1))b.memoizedState=null;else switch(e){case "forwards":c=b.child;for(e=null;null!==c;)a=c.alternate,null!==a&&null===yd(a)&&(e=c),c=c.sibling;c=e;null===c?(e=b.child,b.child=null):(e=c.sibling,c.sibling=null);Ff(b,!1,e,c,f);break;case "backwards":c= -null;e=b.child;for(b.child=null;null!==e;){a=e.alternate;if(null!==a&&null===yd(a)){b.child=e;break}a=e.sibling;e.sibling=c;c=e;e=a}Ff(b,!0,c,null,f);break;case "together":Ff(b,!1,null,null,void 0);break;default:b.memoizedState=null}return b.child}function Fd(a,b){0===(b.mode&1)&&null!==a&&(a.alternate=null,b.alternate=null,b.flags|=2)}function Qa(a,b,c){null!==a&&(b.dependencies=a.dependencies);ra|=b.lanes;if(0===(c&b.childLanes))return null;if(null!==a&&b.child!==a.child)throw Error(n(153));if(null!== -b.child){a=b.child;c=gb(a,a.pendingProps);b.child=c;for(c.return=b;null!==a.sibling;)a=a.sibling,c=c.sibling=gb(a,a.pendingProps),c.return=b;c.sibling=null}return b.child}function xk(a,b,c){switch(b.tag){case 3:ti(b);Qb();break;case 5:Mh(b);break;case 1:ea(b.type)&&ld(b);break;case 4:jf(b,b.stateNode.containerInfo);break;case 10:var d=b.type._context,e=b.memoizedProps.value;y(rd,d._currentValue);d._currentValue=e;break;case 13:d=b.memoizedState;if(null!==d){if(null!==d.dehydrated)return y(G,G.current& -1),b.flags|=128,null;if(0!==(c&b.child.childLanes))return vi(a,b,c);y(G,G.current&1);a=Qa(a,b,c);return null!==a?a.sibling:null}y(G,G.current&1);break;case 19:d=0!==(c&b.childLanes);if(0!==(a.flags&128)){if(d)return xi(a,b,c);b.flags|=128}e=b.memoizedState;null!==e&&(e.rendering=null,e.tail=null,e.lastEffect=null);y(G,G.current);if(d)break;else return null;case 22:case 23:return b.lanes=0,qi(a,b,c)}return Qa(a,b,c)}function Dc(a,b){if(!D)switch(a.tailMode){case "hidden":b=a.tail;for(var c=null;null!== -b;)null!==b.alternate&&(c=b),b=b.sibling;null===c?a.tail=null:c.sibling=null;break;case "collapsed":c=a.tail;for(var d=null;null!==c;)null!==c.alternate&&(d=c),c=c.sibling;null===d?b||null===a.tail?a.tail=null:a.tail.sibling=null:d.sibling=null}}function W(a){var b=null!==a.alternate&&a.alternate.child===a.child,c=0,d=0;if(b)for(var e=a.child;null!==e;)c|=e.lanes|e.childLanes,d|=e.subtreeFlags&14680064,d|=e.flags&14680064,e.return=a,e=e.sibling;else for(e=a.child;null!==e;)c|=e.lanes|e.childLanes, -d|=e.subtreeFlags,d|=e.flags,e.return=a,e=e.sibling;a.subtreeFlags|=d;a.childLanes=c;return b}function yk(a,b,c){var d=b.pendingProps;Ve(b);switch(b.tag){case 2:case 16:case 15:case 0:case 11:case 7:case 8:case 12:case 9:case 14:return W(b),null;case 1:return ea(b.type)&&(w(S),w(J)),W(b),null;case 3:d=b.stateNode;Tb();w(S);w(J);lf();d.pendingContext&&(d.context=d.pendingContext,d.pendingContext=null);if(null===a||null===a.child)pd(b)?b.flags|=4:null===a||a.memoizedState.isDehydrated&&0===(b.flags& -256)||(b.flags|=1024,null!==wa&&(Gf(wa),wa=null));yi(a,b);W(b);return null;case 5:kf(b);var e=vb(xc.current);c=b.type;if(null!==a&&null!=b.stateNode)zk(a,b,c,d,e),a.ref!==b.ref&&(b.flags|=512,b.flags|=2097152);else{if(!d){if(null===b.stateNode)throw Error(n(166));W(b);return null}a=vb(Ea.current);if(pd(b)){d=b.stateNode;c=b.type;var f=b.memoizedProps;d[Da]=b;d[uc]=f;a=0!==(b.mode&1);switch(c){case "dialog":B("cancel",d);B("close",d);break;case "iframe":case "object":case "embed":B("load",d);break; -case "video":case "audio":for(e=0;e\x3c/script>",a=a.removeChild(a.firstChild)):"string"===typeof d.is?a=g.createElement(c,{is:d.is}):(a=g.createElement(c),"select"===c&&(g=a,d.multiple?g.multiple=!0:d.size&&(g.size=d.size))):a=g.createElementNS(a,c);a[Da]=b;a[uc]=d;Ak(a,b,!1,!1);b.stateNode=a;a:{g=qe(c,d);switch(c){case "dialog":B("cancel",a);B("close",a);e=d;break;case "iframe":case "object":case "embed":B("load",a);e=d;break; -case "video":case "audio":for(e=0;eHf&&(b.flags|=128,d=!0,Dc(f,!1),b.lanes=4194304)}else{if(!d)if(a=yd(g),null!==a){if(b.flags|=128,d=!0,c=a.updateQueue,null!==c&&(b.updateQueue=c,b.flags|=4),Dc(f,!0),null===f.tail&&"hidden"===f.tailMode&&!g.alternate&&!D)return W(b),null}else 2*P()-f.renderingStartTime>Hf&&1073741824!==c&&(b.flags|= -128,d=!0,Dc(f,!1),b.lanes=4194304);f.isBackwards?(g.sibling=b.child,b.child=g):(c=f.last,null!==c?c.sibling=g:b.child=g,f.last=g)}if(null!==f.tail)return b=f.tail,f.rendering=b,f.tail=b.sibling,f.renderingStartTime=P(),b.sibling=null,c=G.current,y(G,d?c&1|2:c&1),b;W(b);return null;case 22:case 23:return ba=Ga.current,w(Ga),d=null!==b.memoizedState,null!==a&&null!==a.memoizedState!==d&&(b.flags|=8192),d&&0!==(b.mode&1)?0!==(ba&1073741824)&&(W(b),b.subtreeFlags&6&&(b.flags|=8192)):W(b),null;case 24:return null; -case 25:return null}throw Error(n(156,b.tag));}function Ck(a,b,c){Ve(b);switch(b.tag){case 1:return ea(b.type)&&(w(S),w(J)),a=b.flags,a&65536?(b.flags=a&-65537|128,b):null;case 3:return Tb(),w(S),w(J),lf(),a=b.flags,0!==(a&65536)&&0===(a&128)?(b.flags=a&-65537|128,b):null;case 5:return kf(b),null;case 13:w(G);a=b.memoizedState;if(null!==a&&null!==a.dehydrated){if(null===b.alternate)throw Error(n(340));Qb()}a=b.flags;return a&65536?(b.flags=a&-65537|128,b):null;case 19:return w(G),null;case 4:return Tb(), -null;case 10:return af(b.type._context),null;case 22:case 23:return ba=Ga.current,w(Ga),null;case 24:return null;default:return null}}function Wb(a,b){var c=a.ref;if(null!==c)if("function"===typeof c)try{c(null)}catch(d){H(a,b,d)}else c.current=null}function If(a,b,c){try{c()}catch(d){H(a,b,d)}}function Dk(a,b){Jf=Zc;a=ch();if(Ie(a)){if("selectionStart"in a)var c={start:a.selectionStart,end:a.selectionEnd};else a:{c=(c=a.ownerDocument)&&c.defaultView||window;var d=c.getSelection&&c.getSelection(); -if(d&&0!==d.rangeCount){c=d.anchorNode;var e=d.anchorOffset,f=d.focusNode;d=d.focusOffset;try{c.nodeType,f.nodeType}catch(M){c=null;break a}var g=0,h=-1,k=-1,m=0,t=0,u=a,r=null;b:for(;;){for(var p;;){u!==c||0!==e&&3!==u.nodeType||(h=g+e);u!==f||0!==d&&3!==u.nodeType||(k=g+d);3===u.nodeType&&(g+=u.nodeValue.length);if(null===(p=u.firstChild))break;r=u;u=p}for(;;){if(u===a)break b;r===c&&++m===e&&(h=g);r===f&&++t===d&&(k=g);if(null!==(p=u.nextSibling))break;u=r;r=u.parentNode}u=p}c=-1===h||-1===k?null: -{start:h,end:k}}else c=null}c=c||{start:0,end:0}}else c=null;Kf={focusedElem:a,selectionRange:c};Zc=!1;for(l=b;null!==l;)if(b=l,a=b.child,0!==(b.subtreeFlags&1028)&&null!==a)a.return=b,l=a;else for(;null!==l;){b=l;try{var x=b.alternate;if(0!==(b.flags&1024))switch(b.tag){case 0:case 11:case 15:break;case 1:if(null!==x){var w=x.memoizedProps,z=x.memoizedState,A=b.stateNode,v=A.getSnapshotBeforeUpdate(b.elementType===b.type?w:xa(b.type,w),z);A.__reactInternalSnapshotBeforeUpdate=v}break;case 3:var q= -b.stateNode.containerInfo;1===q.nodeType?q.textContent="":9===q.nodeType&&q.documentElement&&q.removeChild(q.documentElement);break;case 5:case 6:case 4:case 17:break;default:throw Error(n(163));}}catch(M){H(b,b.return,M)}a=b.sibling;if(null!==a){a.return=b.return;l=a;break}l=b.return}x=Ai;Ai=!1;return x}function Gc(a,b,c){var d=b.updateQueue;d=null!==d?d.lastEffect:null;if(null!==d){var e=d=d.next;do{if((e.tag&a)===a){var f=e.destroy;e.destroy=void 0;void 0!==f&&If(b,c,f)}e=e.next}while(e!==d)}} -function Id(a,b){b=b.updateQueue;b=null!==b?b.lastEffect:null;if(null!==b){var c=b=b.next;do{if((c.tag&a)===a){var d=c.create;c.destroy=d()}c=c.next}while(c!==b)}}function Lf(a){var b=a.ref;if(null!==b){var c=a.stateNode;switch(a.tag){case 5:a=c;break;default:a=c}"function"===typeof b?b(a):b.current=a}}function Bi(a){var b=a.alternate;null!==b&&(a.alternate=null,Bi(b));a.child=null;a.deletions=null;a.sibling=null;5===a.tag&&(b=a.stateNode,null!==b&&(delete b[Da],delete b[uc],delete b[Me],delete b[Ek], -delete b[Fk]));a.stateNode=null;a.return=null;a.dependencies=null;a.memoizedProps=null;a.memoizedState=null;a.pendingProps=null;a.stateNode=null;a.updateQueue=null}function Ci(a){return 5===a.tag||3===a.tag||4===a.tag}function Di(a){a:for(;;){for(;null===a.sibling;){if(null===a.return||Ci(a.return))return null;a=a.return}a.sibling.return=a.return;for(a=a.sibling;5!==a.tag&&6!==a.tag&&18!==a.tag;){if(a.flags&2)continue a;if(null===a.child||4===a.tag)continue a;else a.child.return=a,a=a.child}if(!(a.flags& -2))return a.stateNode}}function Mf(a,b,c){var d=a.tag;if(5===d||6===d)a=a.stateNode,b?8===c.nodeType?c.parentNode.insertBefore(a,b):c.insertBefore(a,b):(8===c.nodeType?(b=c.parentNode,b.insertBefore(a,c)):(b=c,b.appendChild(a)),c=c._reactRootContainer,null!==c&&void 0!==c||null!==b.onclick||(b.onclick=kd));else if(4!==d&&(a=a.child,null!==a))for(Mf(a,b,c),a=a.sibling;null!==a;)Mf(a,b,c),a=a.sibling}function Nf(a,b,c){var d=a.tag;if(5===d||6===d)a=a.stateNode,b?c.insertBefore(a,b):c.appendChild(a); -else if(4!==d&&(a=a.child,null!==a))for(Nf(a,b,c),a=a.sibling;null!==a;)Nf(a,b,c),a=a.sibling}function jb(a,b,c){for(c=c.child;null!==c;)Ei(a,b,c),c=c.sibling}function Ei(a,b,c){if(Ca&&"function"===typeof Ca.onCommitFiberUnmount)try{Ca.onCommitFiberUnmount(Uc,c)}catch(h){}switch(c.tag){case 5:X||Wb(c,b);case 6:var d=T,e=za;T=null;jb(a,b,c);T=d;za=e;null!==T&&(za?(a=T,c=c.stateNode,8===a.nodeType?a.parentNode.removeChild(c):a.removeChild(c)):T.removeChild(c.stateNode));break;case 18:null!==T&&(za? -(a=T,c=c.stateNode,8===a.nodeType?Re(a.parentNode,c):1===a.nodeType&&Re(a,c),nc(a)):Re(T,c.stateNode));break;case 4:d=T;e=za;T=c.stateNode.containerInfo;za=!0;jb(a,b,c);T=d;za=e;break;case 0:case 11:case 14:case 15:if(!X&&(d=c.updateQueue,null!==d&&(d=d.lastEffect,null!==d))){e=d=d.next;do{var f=e,g=f.destroy;f=f.tag;void 0!==g&&(0!==(f&2)?If(c,b,g):0!==(f&4)&&If(c,b,g));e=e.next}while(e!==d)}jb(a,b,c);break;case 1:if(!X&&(Wb(c,b),d=c.stateNode,"function"===typeof d.componentWillUnmount))try{d.props= -c.memoizedProps,d.state=c.memoizedState,d.componentWillUnmount()}catch(h){H(c,b,h)}jb(a,b,c);break;case 21:jb(a,b,c);break;case 22:c.mode&1?(X=(d=X)||null!==c.memoizedState,jb(a,b,c),X=d):jb(a,b,c);break;default:jb(a,b,c)}}function Fi(a){var b=a.updateQueue;if(null!==b){a.updateQueue=null;var c=a.stateNode;null===c&&(c=a.stateNode=new Gk);b.forEach(function(b){var d=Hk.bind(null,a,b);c.has(b)||(c.add(b),b.then(d,d))})}}function Aa(a,b,c){c=b.deletions;if(null!==c)for(var d=0;de&&(e=g);d&=~f}d=e;d=P()-d;d=(120>d?120:480>d?480:1080>d?1080:1920>d?1920:3E3>d?3E3:4320>d?4320:1960*Nk(d/1960))-d;if(10a?16:a;if(null===lb)var d=!1;else{a=lb;lb=null;Qd=0;if(0!==(p&6))throw Error(n(331));var e=p;p|=4;for(l=a.current;null!==l;){var f=l,g=f.child;if(0!==(l.flags&16)){var h=f.deletions;if(null!==h){for(var k=0;kP()-Of?xb(a,0):Sf|=c);ia(a,b)}function Ui(a,b){0===b&&(0===(a.mode&1)?b=1:(b=Rd,Rd<<=1,0===(Rd&130023424)&&(Rd=4194304)));var c=Z();a=Oa(a,b);null!==a&&(ic(a,b,c),ia(a,c))}function wk(a){var b=a.memoizedState,c=0;null!==b&&(c=b.retryLane);Ui(a,c)}function Hk(a,b){var c=0;switch(a.tag){case 13:var d=a.stateNode;var e=a.memoizedState;null!==e&&(c=e.retryLane); -break;case 19:d=a.stateNode;break;default:throw Error(n(314));}null!==d&&d.delete(b);Ui(a,c)}function Ni(a,b){return xh(a,b)}function Uk(a,b,c,d){this.tag=a;this.key=c;this.sibling=this.child=this.return=this.stateNode=this.type=this.elementType=null;this.index=0;this.ref=null;this.pendingProps=b;this.dependencies=this.memoizedState=this.updateQueue=this.memoizedProps=null;this.mode=d;this.subtreeFlags=this.flags=0;this.deletions=null;this.childLanes=this.lanes=0;this.alternate=null}function yf(a){a= -a.prototype;return!(!a||!a.isReactComponent)}function Vk(a){if("function"===typeof a)return yf(a)?1:0;if(void 0!==a&&null!==a){a=a.$$typeof;if(a===ie)return 11;if(a===je)return 14}return 2}function gb(a,b){var c=a.alternate;null===c?(c=pa(a.tag,b,a.key,a.mode),c.elementType=a.elementType,c.type=a.type,c.stateNode=a.stateNode,c.alternate=a,a.alternate=c):(c.pendingProps=b,c.type=a.type,c.flags=0,c.subtreeFlags=0,c.deletions=null);c.flags=a.flags&14680064;c.childLanes=a.childLanes;c.lanes=a.lanes;c.child= -a.child;c.memoizedProps=a.memoizedProps;c.memoizedState=a.memoizedState;c.updateQueue=a.updateQueue;b=a.dependencies;c.dependencies=null===b?null:{lanes:b.lanes,firstContext:b.firstContext};c.sibling=a.sibling;c.index=a.index;c.ref=a.ref;return c}function wd(a,b,c,d,e,f){var g=2;d=a;if("function"===typeof a)yf(a)&&(g=1);else if("string"===typeof a)g=5;else a:switch(a){case Bb:return ub(c.children,e,f,b);case fe:g=8;e|=8;break;case ee:return a=pa(12,c,b,e|2),a.elementType=ee,a.lanes=f,a;case ge:return a= -pa(13,c,b,e),a.elementType=ge,a.lanes=f,a;case he:return a=pa(19,c,b,e),a.elementType=he,a.lanes=f,a;case Vi:return Gd(c,e,f,b);default:if("object"===typeof a&&null!==a)switch(a.$$typeof){case hg:g=10;break a;case gg:g=9;break a;case ie:g=11;break a;case je:g=14;break a;case Ta:g=16;d=null;break a}throw Error(n(130,null==a?a:typeof a,""));}b=pa(g,c,b,e);b.elementType=a;b.type=d;b.lanes=f;return b}function ub(a,b,c,d){a=pa(7,a,d,b);a.lanes=c;return a}function Gd(a,b,c,d){a=pa(22,a,d,b);a.elementType= -Vi;a.lanes=c;a.stateNode={isHidden:!1};return a}function gf(a,b,c){a=pa(6,a,null,b);a.lanes=c;return a}function hf(a,b,c){b=pa(4,null!==a.children?a.children:[],a.key,b);b.lanes=c;b.stateNode={containerInfo:a.containerInfo,pendingChildren:null,implementation:a.implementation};return b}function Wk(a,b,c,d,e){this.tag=b;this.containerInfo=a;this.finishedWork=this.pingCache=this.current=this.pendingChildren=null;this.timeoutHandle=-1;this.callbackNode=this.pendingContext=this.context=null;this.callbackPriority= -0;this.eventTimes=we(0);this.expirationTimes=we(-1);this.entangledLanes=this.finishedLanes=this.mutableReadLanes=this.expiredLanes=this.pingedLanes=this.suspendedLanes=this.pendingLanes=0;this.entanglements=we(0);this.identifierPrefix=d;this.onRecoverableError=e;this.mutableSourceEagerHydrationData=null}function Vf(a,b,c,d,e,f,g,h,k,m){a=new Wk(a,b,c,h,k);1===b?(b=1,!0===f&&(b|=8)):b=0;f=pa(3,null,null,b);a.current=f;f.stateNode=a;f.memoizedState={element:d,isDehydrated:c,cache:null,transitions:null, -pendingSuspenseBoundaries:null};df(f);return a}function Xk(a,b,c){var d=3