Modeling & Simulation Services
Conceptual and Computational models are highly specialized. Therefore, nexusSIM offers a range of solutions. The most appropriate solution will vary considerably depending on the current stage of development of the project.
Modeling is a fuzzy, sometimes meandering process. Nonetheless, there is a clear difference between a seed of a model that is high-level, non-specific idea, and a model-specification that lays out clear goals and related literature. With a good model spec, a modeler can easily make a first go at implementing a computational model, and the model can be iterated on from there. Our model specification service is for the academic that has a hunch that a certain topic will lend itself to a very fruitful computational model, but just isn’t certain what specifics will be most appropriate in a computational model.
To build a full model specification, we will work with the academic to build:
- Clear model goals, including the kind of analysis the model aims to make possible
- A conceptual model sketch, with specified inputs and outputs
- A literature review that will act as the sources for the model
- Key concepts from the literature review that the model will aim to include in its causal architecture
Once a model specification is clearly articulated, a technical expert can give a go at building a model that incorporates concepts from the literature into a causal architecture.
Building a model skeleton
After model specification, the next step is model skeleton. A model specification will have all the resources a modeler needs to ideate a computational model, but converting the ideation into code is still an intensive process. Discrepancies in the spec and within the literature may arise, and the technical expert will collaborate with the academic to work out the kinks.
The finished model skeleton will be implemented in software. It may or may not run. The model skeleton demonstrates what the model could look like in code, and articulates all the inputs and outputs from the spec. If the academic agrees with the skeleton, the skeleton can be mathematically fleshed out and validated.
Note that the skeleton may need some rounds of iterative development to reach a final product.
Filling in the model gaps
A completed model skeleton may not run, and it will not have some of the vital mathematics sorted out. Models rely on rates, distributions, and thresholds that may be sourced from empirical data and/or expert estimates. Integrating the model with the relevant data is often a separate task from building a model skeleton, and difficulty will depend a lot on the model.
With a filled out model skeleton, the next step is validating the model: if we try several different scenarios by varying the input data, is the output roughly what we would expect?
We do this by running a parameter sweep over the model inputs, and measuring the model outcomes. We can plot the outcomes in various ways, and work with the academic to see if the outcomes match our theoretical expectation. Often, successful verification may be the end of the project for the academic; the academic would work to publish the model and the verification findings.
If the model cannot be verified (outcomes do not match our theoretical expectation), it may be necessary to go back to an earlier stage of model development; perhaps trying different mathematics, or changing the skeleton of the model.
Model verification iterative development
If the model cannot be verified, this could mean that the theory behind the model is wrong. However, if the theory has significant empirical data backing it, it is more likely that the model integrates the theory inadequately. In this case, we need to go back and tweak the model, then verify it again.