G-Cubed Calibration settings
The calibration section changes model-wide economic settings. Omit fields that should use the G-Cubed defaults.
State selected calibration values
calibration:
parameter_module: calibrated_parameters
neutral_real_interest_rate: 0.036
effective_labor_productivity_growth_rate_in_steady_state: 1.4
rate_of_time_preference: 0.022
marginal_propensity_to_consume: 1.0
blanchard_probability_of_death: 0.03
This is a partial configuration: merge it into an existing model YAML. The module name does not include .py. Numeric fields must be finite YAML numbers; quoted numbers and booleans are invalid.
effective_labor_productivity_growth_rate_in_steady_state is an annual percentage log growth rate: 1.4 means 1.4 per cent, and omission defaults to 1.4. Its value must be nonnegative and less than 100. An annual log growth rate of 1.4 per cent gives ordinary compounded growth of 100 * (exp(0.014) - 1), approximately 1.40985 per cent.
The other rate fields retain their decimal units. For example, neutral_real_interest_rate: 0.036 means 3.6 per cent. Do not multiply these other settings by 100 when migrating the growth setting. Baseline-tuning INTR inputs have their own percentage-point units.
Common frontier growth and sector deviations
From model build 200 onwards, technology_advancement_rates.csv stores deviations from the configured common frontier growth rate. Build 199 and earlier used absolute frontier growth rates; see the build 200 migration guidance.
Let G be the configured percentage growth rate and D a cell in technology_advancement_rates.csv. Actual annual frontier log growth is:
actual frontier growth (percent) = G + D
actual frontier growth (decimal) = (G + D) / 100
The CSV contains percentage-point deviations. Zero selects the configured frontier rate. With G = 1.4, D = 0.6 gives 2.0 per cent growth and D = -0.4 gives 1.0 per cent growth. Negative deviations are valid provided actual frontier growth remains nonnegative. Default generation writes zeros, including template files. Every sector must have exact zero deviations for the final 50 configured projection years; see the technology advancement input contract.
The Python property ModelConfiguration.effective_labor_productivity_growth_rate_in_steady_state remains a normalized decimal: YAML 1.4 produces Python 0.014. Calibration, labgrow, data generation and publication scaling use that decimal. Convert once at configuration loading; Python consumers must not divide it by 100 again.
Migrate existing growth inputs
The compatibility break occurs at model build 200. The CSV filename and layout are unchanged, but the meaning of its values changes:
| Input | Build 199 and earlier: original convention | Build 200 onwards: new convention |
|---|---|---|
| Configured steady-state growth | Decimal annual log rate: 0.014 means 1.4% | Percentage annual log rate: 1.4 means 1.4% |
technology_advancement_rates.csv cell | Absolute annual frontier log growth in percent | Percentage-point deviation from configured growth |
| CSV value for a 1.4% frontier path with a 1.4% common trend | 1.4 | 0.0 |
This is a breaking interpretation change within schema_version: 1; there is no schema version 2. Schema version 1 does not identify whether old inputs have been migrated. Pair build 200 inputs with the software implementing the new convention. To reproduce an unmigrated older build, retain its matching older software and original inputs.
The build number marks the compatibility boundary, not an automatic runtime switch. The updated implementation applies the new interpretation even to an older build identifier. Migrate both inputs before running such a build with updated software; neither build number nor numeric magnitude triggers conversion. YAML 0.014 now means 0.014 per cent log growth. With configured G = 1.4, an unmigrated CSV cell of 1.4 resolves to 2.8 per cent, rather than retaining the old 1.4 per cent path (and fails validation in the final 50 years).
Migrate the configuration and its advancement CSV together:
new configured G = 100 * old configured decimal
new CSV deviation = old absolute percentage rate - new configured G
For example, old YAML 0.014 becomes 1.4; old CSV 1.4 becomes 0.0, 2.0 becomes 0.6, and 1.0 becomes -0.4. Materialize an omitted old default as explicit 1.4. Keep schema_version: 1 and preserve custom file names and nonzero deviations before the final 50 years.
If subtraction leaves nonzero values in the protected years, the old frontier path disagrees with the configured long-run rate. Resolve that economic assumption explicitly; migration must not silently flatten the path. Regenerate dependent inputs and saved solutions following the baseline regeneration sequence.
Override one value
calibration:
neutral_real_interest_rate: 0.04
Unlisted settings retain their G-Cubed defaults.