There are simulation tools that require you to define your model entirely in the form of a program, or source code – whether via an existing general purpose programming language or a special purpose simulation language.\u00a0 Other tools require you to define models totally through data: graphical, tabular, or some combination of the two.\u00a0 This is usually a selling point \u2013 \u201cno programming required!!!\u201d Finally, there are packages that combine both approaches.<\/p>\n
Is \u201cNo programming required!\u201d a bug or a feature?\u00a0 That\u2019s a religious question that I\u2019d rather avoid, at least for now.\u00a0 Let it suffice to say that I believe that program code has its place \u2013 but then again, I develop software for a living, so perhaps I\u2019m just a bit biased.\u00a0 In any event, I fall into that third camp \u2013 both data and code.\u00a0 For now, the question I\u2019d like to explore is not whether<\/em> modelers should write code, but how and what kind.<\/p>\n <\/p>\n A few initial requirements come to mind:<\/p>\n As mentioned above, modeling code can take the form of either a domain-specific simulation language (DSL) or a general purpose programming language.\u00a0 When we evaluate these two approaches, we see a tension between the first requirement and the others, particularly (2) and (4).<\/p>\n A simulation DSL is, pretty much by definition, designed to express process and\/or agent behaviors using domain language.\u00a0 Meeting the other requirements is more of a challenge.\u00a0 Developing IDEs, debuggers and libraries from scratch entails an enormous effort.\u00a0 Depending on the design of the DSL, it may be possible to leverage an existing general-purpose tool chain, but some trade-offs are almost inevitable.\u00a0 In other words, the advantages of a DSL are likely to be at least partially offset by a less than state-of-the-art programming and runtime environment.<\/p>\n Modern, mainstream programming languages, on the other hand, come with a rich ecosystem of tools and libraries \u2013 in other words, they fully support requirements 2-4 pretty much out of the box.\u00a0 The first requirement is, however,\u00a0significantly more problematic. \u00a0I\u2019d like to be able to define a process as a single block of code that expresses delay and blocking actions through function calls such as wait() or acquireResource().\u00a0 Until relatively recently, it seemed virtually impossible to do that without using threads \u2013 a heavyweight solution that quickly introduces significant problems in both performance and scalability.<\/p>\n Enter coroutines<\/a>.\u00a0 A coroutine \u2013 with the ability to yield to other coroutines, and then be restarted at the point where it left off \u2013 provides the key mechanisms we need to implement blocking or delay actions in a simulation process, while costing orders of magnitude less than an operating system thread.\u00a0 Coroutines have been around for more than fifty years, but have only made their way into the mainstream over the past decade or so.<\/p>\n For me, designing and implementing a new simulation DSL has never been an option; that\u2019s one wheel I have neither the skills nor the desire to re-invent.\u00a0 Once I started looking at coroutines \u2013 and in particular, the ways in which they are implemented in Python \u2013 another path forward began to emerge.<\/p>\n","protected":false},"excerpt":{"rendered":" There are simulation tools that require you to define your model entirely in the form of a program, or source code – whether via an existing general purpose programming language or a special purpose simulation language.\u00a0 Other tools require you to define models totally through data: graphical, tabular, or some combination of the two.\u00a0 This… (read more<\/a>)<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"nf_dc_page":"","_jetpack_newsletter_access":"","_jetpack_dont_email_post_to_subs":false,"_jetpack_newsletter_tier_id":0,"_jetpack_memberships_contains_paywalled_content":false,"_jetpack_feature_clip_id":0,"_jetpack_memberships_contains_paid_content":false,"footnotes":"","jetpack_post_was_ever_published":false},"categories":[4,3,2],"tags":[],"class_list":["post-34","post","type-post","status-publish","format-standard","hentry","category-goals-requirements","category-modeling","category-simulation"],"jetpack_sharing_enabled":true,"jetpack_featured_media_url":"","_links":{"self":[{"href":"https:\/\/www.howardklein.net\/index.php?rest_route=\/wp\/v2\/posts\/34","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.howardklein.net\/index.php?rest_route=\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.howardklein.net\/index.php?rest_route=\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.howardklein.net\/index.php?rest_route=\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/www.howardklein.net\/index.php?rest_route=%2Fwp%2Fv2%2Fcomments&post=34"}],"version-history":[{"count":5,"href":"https:\/\/www.howardklein.net\/index.php?rest_route=\/wp\/v2\/posts\/34\/revisions"}],"predecessor-version":[{"id":40,"href":"https:\/\/www.howardklein.net\/index.php?rest_route=\/wp\/v2\/posts\/34\/revisions\/40"}],"wp:attachment":[{"href":"https:\/\/www.howardklein.net\/index.php?rest_route=%2Fwp%2Fv2%2Fmedia&parent=34"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.howardklein.net\/index.php?rest_route=%2Fwp%2Fv2%2Fcategories&post=34"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.howardklein.net\/index.php?rest_route=%2Fwp%2Fv2%2Ftags&post=34"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}\n