scalabm / requirements Goto Github PK

@prauwolf I agree that we need to prioritize getting some kind of website up and running. The current website that I threw together can be found here. The website leverages GitHub pages to serve a static website for our ScalABM organization. Individual repos can also have project webpages. We should probably also start writing a blog...

I am not sure that we should motivate ScalABM (or ABM in general) by setting it up as a direct competitor to DSGE models. I think this is the approach that ABM modelers have taken in the past and I think it has failed to persuade outside researchers (i.e., non-ABM converts); instead we should push ABM as a complementary approach to DSGE models that is better placed to leverage increasingly available large-scale micro panel data sets.

Proponents of DSGE modelers love to talk about "structural modeling" and "microfoundations"; I think it is important to stress that ABM models are also micro-founded, structural models. A major difference, as I see it, is that while DSGE models impose structure on preferences and production technologies, ABMs impose structure in the form of contractual relationships, market institutional structures, government policy, etc. The structure of preferences and production technologies are inherently difficult to observe, we can, however, easily observe contracts, market structures, government policies, etc and incorporate this structure into our ABMs.

I also think we should place estimation, calibration, and validation of models using ScalABM front and center as part of the motivation. Historically, this has been a weak spot of macroeconomic ABM models.
Basically: ScalABM combines "Big Data" techniques, particularly machine learning methods, that are capable of taking advantage of large-scale micro panel data sets with structural economic modeling.

I think we need to draw a sharper contrast between ScalABM and existing large-scale ABM modeling efforts (in particular the various flavors of EURACE, the CRISIS project, JMAB, etc). Various flavors of the EURACE project use the FLAME platform which is scalable but requires models written in C or C++, has an extremely high learning curve, is not widely used outside of academia, and is currently not being actively developed. I am not sure what the EURACE projects are doing on the estimation, calibration, validation front. CRISIS project and JMAB are not single-thread models and therefore not inherently scalable. Neither project has done much on the calibration, estimation, and validation front (at least to my knowledge).

While we want to contrast our approach with those existing projects, we do not want to be too critical. Ultimately, it would be great if we could bring those groups into the fold.