GEModelR keeps the legacy in-memory engine as the default and offers sparse execution as an explicit runtime choice. This article runs one small generated model through both workflows. The fixture is deterministic and contains no external TABLO or HAR inputs.
Load the same TABLO recipe and input arrays with
engine = "legacy", set the closure and shock, then solve
with the matching engine. postsim = FALSE keeps this
example focused on the numerical solution.
legacyModel = GEModelR::GEModel$new()
legacyModel$loadTablo(fixture$tabloPath)
legacyModel$setClosure("tax")
legacyModel$loadData(fixture$inputData, engine = "legacy")
legacyModel$setShocks(setNames(4, 'tax["south"]'))
legacyModel$solveModel(
iter = 1,
steps = 1,
engine = "legacy",
postsim = FALSE
)To use sparse execution, load the data with
engine = "sparse" and use that same engine for the solve.
The Matrix backend is selected explicitly here. When changing an
existing model to a different engine, load its data again so the runtime
state matches the selected engine.
sparseModel = GEModelR::GEModel$new()
sparseModel$loadTablo(fixture$tabloPath)
sparseModel$setClosure("tax")
sparseModel$loadData(fixture$inputData, engine = "sparse")
sparseModel$setShocks(setNames(4, 'tax["south"]'))
sparseModel$solveModel(
iter = 1,
steps = 1,
engine = "sparse",
postsim = FALSE,
backend = "Matrix"
)Both runs use the same three-region model and shock. Inspect their solution vectors side by side:
If your code still names the predecessor package, replace
tabloToR with GEModelR directly. GEModelR does
not provide a compatibility shim. The root MIGRATION.md in
the source checkout is authoritative for package, option,
environment-variable, and saved-state replacements; this vignette covers
only the legacy-versus-sparse runtime choice.
The canonical repository’s first source publication and hosted documentation are pending. This installed vignette and the local source guide remain usable before those publication links are available.