This is the fourth and final research note from Onkar Hoysala, one of the researchers who received the Social Media Research grant for 2016.
“Models and simulations, both, represent certain reality in an abstract form…we are essentially trying to represent reality in some sense. [It is an] abstraction of reality – it could be a mathematical model, simulation model, or a physical model.”
“When we develop a model there are a lot of parameters that need to be tuned, such as vehicle distribution, speed profile… Generally the software would have default values for these parameters and they have to be tuned based on Indian contexts. This becomes much more complicated in our traffic conditions because of the heterogeneity and non-lane-based movement. All this has to be replicated well in the simulation model.”
As Vinay, a professor of civil engineering from a university in Bangalore whose group works on transportation simulation and policies [1], says, a model or a simulation is an abstraction of reality. Models are calibrated and validated to resemble reality the closest they can. However, when the models are built to resemble a reality in one context and the same model is used to represent a reality elsewhere, model and simulation designers run into the problem of contextualisation.
Contextualisation is the “tuning” of different model and simulation parameters such as arrival rate of vehicles, vehicle distribution, acceleration deceleration characteristics, speed profile of vehicles, lateral and longitudinal distance between different categories of vehicles, etc., to calibrate and represent a context other than what it was built for. As I presented in my earlier posts, model and simulation designers discuss how a large part of the work carried out by them is contextualisation. While in the previous post I wrote about the issues of data, here I present in a little more detail the issues of contextualisation, and how the practices around contextualisation shape and are shaped by the technological artefacts of models and simulations. Since the previous post, I have been conducting interviews and some observation of Vinay’ group, which forms my case study.
Many times, contextualisation cannot be carried out by simply modifying the existing parameters provided by off-the-shelf software. As Vinay says, “In many cases we custom build the software – we don’t rely too much on off the shelf software. We do have them, but often we need to make our own scripting[2]. A lot of modelling and optimisation we do – my students do it on their own in Matlab or using simple programming languages. But yes we do use off the shelf software. It’s a mix.”
The challenge here, which Vinay ostensibly recognises, as do other academics in the field, is that while on the one hand by modelling what they intend to do is abstract the reality, their work is shaped by the kind of tools available for use. For instance, the particular tool for traffic microsimulation they use not only shapes the parameters that the scientists can use but also the kind of data that is required (to be collected). It also influences how the modellers think of models itself. While speaking to one of the students in the lab about whether they felt at any point that the existing models did not present them with enough options of input variables, one of the doctoral students said: “One of the models we use is called the Weidemann 74 model[3], which is very recognised and validated. The parameters incorporated in the model are the same regardless of context, they won’t change in the modelling exercise. What we have to do to change the values of the parameters”. While Vinay opines that there is a need to design models ground-up for scenarios in India, and works on different ways to achieve the same, we also see that there is a structural influence from the discipline of transportation engineering – where such models are well known as validated models – that shapes the practice of contextualisation. Thus I see these models and software as structuring resources in the practice of the simulation designers – they structure, sometimes invisibly, what people do.
On the other hand, the group also uses a set of tools along with the simulation software to achieve their goals – MatLab scripts and custom programs in other languages, which Vinay says is required in order to model the reality of Indian traffic to a reasonable accuracy:
“We always have to bank upon a combination of our own coding and software because our traffic conditions being so much more complex and homogeneous than lane based traffic situations in western world. These off-the-shelf software, although customized to a good extent, are still not so near the reality here.”
People in the group rely on these customized tools for their work, be it their research projects or doctoral work. While a number of constraints such as funding or availability of time or resources do affect the kind of work carried out and hence shape the field of transportation modelling itself, we also have to note that tools also play a major role in constraining and shaping the way an academic field moves. In other words, tools such as models and simulations are not immaterial (in that they matter). Through practices such as using a combination of techniques to achieve (or move towards achieving) the goal of contextualisation of models, the field of transport modelling itself is being shaped.
So what?
So here we see two aspects of interest: how models shape the practice of the designers, and how the practice shapes the field and in turn the technologies. Both of these aspects are well established in literature. Literature on social shaping of technologies (for example see, MacKenzie & Wajcman, 1999) describe how technologies are not created in a vacuum but are shaped by various social and economic constraint. Literature on technology enactment (for example see, Orlikowski, 2000) describe how technologies too shape what people do. Which brings me to the question: so what? So what if these models/ simulations and practices shape each other?
Theoretically, practice as a lens allows me to look at both of these aspects by treating them at the same level, and focussing on the reflexive nature of the relationship between the two. In particular for this study, what becomes important then, is not just to answer “how” technologies and practices shape each other, but also what the implications of it are. From the interviews I carried out, the designers all discuss why and how their modelling and simulation work has not seen an uptake by the transportation policy and decision making organisations. Why then, are these models and simulations seemingly successful in places like Europe and USA, and why are the same models and simulations (even though they are contextualised) not gaining a similar uptake by the policy regime here? Is it because of inherent properties of the models and simulations themselves (“They do not provide for adequate parameters to model the traffic conditions here.”[4])? Or is it because the urban transportation policy makers are not well informed about the use of these tools (“There is not enough know-how of these models and thus not enough trust in them.”[5])? It is likely that both shape the eventual outcome of the impact of these tools, along with various other factors such as the familiarity with the tools, the choice of what problem to model, etc. It becomes important then to place the practice of modelling and simulation designers within context. In the final two posts, I present more findings from the interviews and participant observation I am carrying out, and will attempt to place it within the larger context of urban transportation in Indian cities.
References
MacKenzie, D., & Wajcman, J. (1999). The social shaping of technology. Open university press. Retrieved from http://eprints.lse.ac.uk/28638
Orlikowski, W. J. (2000). Using Technology and Constituting Structures: A Practice Lens for Studying Technology in Organizations. Organization Science, 11(4), 404–428.
Notes
[1] Refer the second post for an introduction to Vinay and his group. <http://sarai.net/data-contextualisation-and-simulation-design-findings-from-pilot-interviews/>
[2] A ‘script’ is a short program written often in Very High Level Languages like Python or Matlab, and is not compiled but interpreted directly.
[3] This is a microsimulation car-following model first developed R. Wiedemann in 1974 in Germany. For more information on car-following models, please refer Brackstone, M., & McDonald, M. (1999). Car-following: a historical review. Transportation Research Part F: Traffic Psychology and Behaviour, 2(4), 181-196.
[4] A thought echoed by different simulation designers I interviewed.
[5] A thought echoed by different simulation designers I interviewed.