To This is especially helpful for calibration runs so they only need the periods that are calibrated and not further ones to avoid end of history effects.

The price sensitivity for construction and renovation is a crucial parameter. So far, we have calibrated it manually such that technology shares are matched as well as possible without intangible cost and then adjusted the latter to match them "exactly". But this seems to lead to a very sensitive model and it is questionable if the price sensitivity should be derived as such. We have to invest more time and effort (literature study, econometrics, bottom up estimate, etc.) to better understand and eventually define this parameter.

I wexpect similar results for T = {2020, 2025, 2030} and T = {2020, 2023, 2025, 2030} but BRICK doesn't behave well with changes in time step length. I suspect that the different contribution of zero renovation on the renovation heterogeneity has something to do with that. I already divide is by the length of the time step but this doesn't solve it yet.

We currently have the same price sensitivity for both new construction and renovation. I want to split this into two separate parameters as I expect higher price sensitivity for construction than renovation.

The call of a matching run with BRICK should be moved to mredgebuildings. The corresponding config should also be part of the mredgebuildings repo that has BRICK as a dependency. This makes most sense because matching is part of calculating input data for BRICK even though this involves a BRICK (matching) run. Then, the switch matchingRun can be removed.

When starting BRICK locally with initModel, I often forget to set sendToSlurm = FALSE which gives a non-descriptive error as I don't have SLURM. I would suggest to

• check if SLURM is installed
• throw an indicative error if sendToSlurm = TRUE but SLURM is not installed
• give sendToSlurm the default value of NULL or "auto" which will use SLURM only if available

We only use the historic gdx to fix the values of v_stock, v_construction, v_renovation and v_demolition. All parameters are defined by the input gdx and not affected by the historic gdx. For historic periods, also the parameters should take the historic values.

Reference values can vary widely in magnitude between regions and references. The weighting of discrepancies in the minimisation of the same has to account for that but this weighting needs to be done properly.

We need a function to read FE prices from REMIND GDX. Ideally, one can update the prices without rerunning the entire input data creation for BRICK to save time in coupled mode.

The default regionmapping config setting is an empty list. BRICK cannot handle this and throws an error that is not helpful. Instead, this should lead to country-level resolution as (to this date falsely) claimed in the default config.

When running brick from the installed brick package with the regionmapping specified in the config, the run fails:

The regionmapping file cannot be found as it is not included in the package - all content of inst/input/ is ignored as by the .gitignore file, including any regionmapping file in input/ (which is the standard by the minimal.yaml file)

In matching runs, I observed no values for flows in the first time step before the start year. They are zero for scenarios runs, too. But they exist (though I neither see them used in any equation). The missing values lead to failed reporting.

The technology mapping has columns for the label and colour of technologies that is used for some plots that remain in the BRICK code so far. I think every plot should use mip colours and we should get rind of this (already conflicting) duplication.

If only one region is considered, only four jobs are parallelized - then less CPUs should be requested.

In general, by checking on the dimension of the regions, type and location, the appropriate CPUs should be computed.

copyInitialGdx and copyHistoricGdx share much functionality and should be generalised to avoid code duplication.

function imports are missing at least for createParameters and createSets.

We currently use specific UE demand from Hotmaps. In the mid term. I want to calculate this demand in the model from Uvalue, HDD/CDD using i.a. Tabula data.

The creation of Parameters fails if one gives duplicate assumptions in one chunk of the intangible cost tables:

Error: gt_write_symbol:gdxError GDX error for p_specCostRen: Duplicate keys

This case should be specifically checked to give a helpful error message. Also wrong column elements need to throw an error. Currently, they'll just be ignored by left_join.

It seems that our life time distribution for buildings needs a higher share of very old buildings. The oldest vintage disappear from stock entirely quite quickly which is not realistic considering historic preservation. The very poor matching of vintage references with our current life time implementation also suggests this.

I suggest to let the cumulative distribution function approach a value smaller than 1 for high life times, e.g. 0.9. That means that 10% of the initially constructed stock can remain forever and does not have to be demolished.

The minimum shares of buildings to be demolished or renovated are calculated based on life time distributions for the building, the heating system and the building shell. Currently, the time of construction or installation is assumed to be the centre of the respective time step or vintage period. While this simplification seems to work well for short time steps, the more precise solution would be to assume a uniform distribution of construction/installation across the time span and integrate. For longer time steps, this might lead to more significantly different results than we can see right now.

For heating system installations, we only consider capacity specific purchasing cost so far. This makes new installations extremely cheap in efficient buildings. Fixed investment cost for the actual installation work is not included so far. The BDEW Heizkostenvergleich could be a good starting point for initial estimates.

Enable passing a certain time limit to the SLURM job in initModel().
This might enable faster starts of jobs and especially allows to continue working with SLURM if a maintenance window has been scheduled.

Back when there still was restartModel, one could leave the path empty and BRICK would find the most recent run and restart it. I found that quite convenient but we lost this functionality I believe. Now, leaving path empty leads to the default being executed, which I would keep. I'm wondering if we can still have this functionality. Maybe pass NA instead of NULL to path? But that isn't very intuitive. An alternative would be to introduce a new function like lastRun that returns the path of the last run. Then one could get what I mean with initModel(path = lastRun()). This suggestion probably doesn't work that simply because BRICK needs to know the output folder to look in which is an argument of initModel...

If the gams optimisation fails, the user will only notice because the reporting cannot find symbols as output.gdx is missing.

Start Gams: output/base_2024-06-04_08.34.43/main.gms
Gams finished after 1 sec.
running reportBuildingStock ...
Error in readGdxSymbol(gdx, "v_stock") : 
  This file does not exist: output/base_2024-06-04_08.34.43/output.gdx

This is not very insightful. We should add checks after the execution of gams to either print a message that gams was successful or an indicative error message.

If a run was restarted with restart options but should late be restarted without them, the old options persist. I guess the respective file restartOptions.csv has to be written in any case, also overwriting with an empty file such that the old settings don't persist.

Robert after the IEAMC 2023 presentation:

wir brauchen share-dependent inconvenience costs - die Möglichkeit, eine bestimmte Technologien zu installieren wird einfacher, wenn sie verbreiteter ist. (mehr Techniker, mehr Angebote, ... auch höhere pipeline costs wenn gas boilers einen geringen Anteil haben (wurde ja auch gefragt)

Robert suggested to drop 2/3 of the incenvenience mark-up when reaching a particular threshold with the share of heat pumps in the stock.

To solve this within one optimisation, only the share within each subset of the stock (e.g. DEU, SFH, rural) can be considered.

The historic gdx has to be given as a file path. It should be possible to also only the scenario name and let BRICK pick the most recent scenario with this name from the output folder.

Users can currently select from 3 different scenarios for carrier prices and carrier emission intensities. I want to make this a continuous scenario definition where on can set a trajectory over time that can assume values between -1 (low) over 0 (central) to 1 (high).

Issue to collect minor bugs so that they are not forgotten.

createInputData.R

• l. 221 (Creation of set "typ"): Should be records = typ
• l. 470 (Declaration of parameter p_specCostOpe): Unit should be USD/kWh.y