Quantifying/converting abstract values to standard units in Netlogo simulations

Question

I'm working on a simulation project in NetLogo and have encountered a challenge regarding the quantification of certain values. Specifically, I'm trying to understand how to effectively convert abstract simulation measures into real-world units. Here are my main concerns:

Time Conversion: In NetLogo, time is typically represented in 'ticks', but I'm unsure how to translate this into real-world units like seconds or hours. Is there a standard approach or formula for this conversion, or is it entirely dependent on the context of the simulation?

Physical Quantities: Another aspect is converting abstract measures of attributes like 'muscle mass' in the simulation into realistic units such as kilograms or grams. Since NetLogo doesn't inherently define these units, I'm uncertain how to make these conversions meaningful and accurate.

My questions are:

• Are there any guidelines for converting these abstract quantities into real-world units in NetLogo?
• Should I assign arbitrary values to these units, or is there a more systematic approach to ensure consistency and realism in the simulation?

Any insights or examples from your experiences with similar conversions in NetLogo or other simulation environments?

Answer 1

The answer is simple: no, numbers in NetLogo don't represent anything in particular without your inentional definition; also, your intentional definition of units is everything that's needed for numbers to acquire real world meaning.

And it couldn't be any other way. Otherwise, that would limit applications: if ticks were seconds, it would have been practically impossible to model the gravity of the planets. If some variable were kilograms (but... what variable? you are the one creating variables!), it would have been impossible to model chemical processes.

You give variables the units that are sensible for the scope of your model, and the scope of your model is the only guiding principle. If you decide that ticks are days, then whatever takes place in a single iteration of your go procedure has to be consistent with what happens during one day in reality (assuming that an iteration of go equals one tick, according to common practice). Maintaining this consistency and doing it transparently is the only rule.

The only good standard you probably want to follow relates to the documentation of the model's Overview, Desgin concept and Details through the ODD protocol (or the ODD+D for better documentation regarding Decision making by agents in the model; or the ODD+2D for better documentation regarding the use of Data for parameterisation). This should be more than enough of a reference to understand better what's the deal.