-
Notifications
You must be signed in to change notification settings - Fork 15
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Integrate the BOARIO model into CLIMADA SupplyChain Module #81
Conversation
Additions - added boario imports - added extended parsing of final demand in parse_mriot_from_df (required by boario) - added negative total final demand fix - added two approaches cases in calc_indirect_production_impacts (only aggregated implemented atm) Matters to attend - specify boario_output_dir (I will set registering files optional at some point, but probably not very soon) - Implement the results returned
- Changed names in model instantiation ('kapital' → 'productive_capital') - Added `psi_param` and `inventory_restoration_tau` in model instantiation (the values are the default values, this is only for transparency if you want to set these values programmatically at some point) - Removed multiplication by model.monetary_factor in Event instantiation (this is done more properly inside BoARIO now) - Swapped `add_event` to `add_events` for lisibility (since the method now exists) - The `production_evolution` dataframe is now directly accessible as a simulation property, hence I simplified the `self.indir_prod_impt_mat` affectation - Commented the mriot.unit part as it is not required anymore (see below)
The stock of capital should be in the same unit as the MRIOT, so we just divide it by the conversion factor.
Hi @spjuhel, I got a question after reading the BoARIO's docs again: currently From https://spjuhel.github.io/BoARIO/boario-math.html, I see that BOARIO actually can handle these use-cases as it can shock 1) productive capital (what we do now), 2) households (not relevant here) but also 3) production capacity. How should Thanks. |
Hi @aleeciu, This is handled by the type of Event you instantiate. Currently there's 3:
Note that:
I think in the long run, Climada's default should probably be EventKapitalRebuild, as it is hard to justify the absence of a rebuilding demand (especially after a Cyclone, for instance). But that requires to define the set of rebuilding sectors and their "market share" of the rebuilding demand, which is hard to generalize over different MRIOT. |
Thanks @spjuhel . I integrated the three BOARIO models now. Got to figure out how to best handle the kwargs in |
…roject/climada_petals into feature/climada_boario
Using complex events set (for example TCs from multiple bassins) can lead to event_id / occurences to not be ordered. Using .max() and .min() insure we use the correct 'first' event and 'last' event.
@emanuel-schmid or @peanutfun this is almost done, I have some quick technical questions:
Also can I safely black-format the whole file? |
It is highly probable that 0.5.10 / 0.6 will break everything.
I think I have adressed all remaining problems and remarks and the last remaining thing would be to add |
This PR integrates the BOARIO model (https://github.com/spjuhel/BoARIO) developed by @spjuhel into the CLIMADA's SupplyChain module.
Missing:
PR Author Checklist
develop
)TODOs:
>=v0.5.9
for compatibility.PR Reviewer Checklist
23/04/24 Remarks from @spjuhel while working on the PR:
boario_params["event"]
dict to hold unwanted keyword arguments for specific events (ieboario_params["event"]["recovery_time"]
is set to a default value if we instantiate anEventKapitalRecovery
, which currently causes an error when instantiating anEventKapitalRebuild
afterward. I've corrected this on the boario side, which will be part of its v0.5.9 release.pymrio
v0.5.4, just out, introduces Ghosh calculation (which we currently do by ourselves). I think we can just bump the dependency to this version and use their functions.