LEMONS: An open-source platform to generate non-circuLar, anthropometry-based pEdestrian shapes and simulate their Mechanical interactiONS in two dimensions

1. Overall, the authors should be congratulated on the technical scope and ambition of this work. The paper clearly describes the process by which the field of pedestrian dynamics modelling can improve the representation of pedestrian geometric forms in 2D. Creating such a tool, available for access in the open domain is to be commended.
2. Code is described in detail, and the implementation of algorithms is rigorous.
3. This work really does have the potential to be transformative in the field, creating a common code base for high density modelling. After quantified, and documented validation processes, it could become an extremely valuable contribution to the community.

1. Unfortunately, there are no validation tests implemented at any level to verify that the numerical outcomes are correct. These algorithms, ultimately, may be used to assess pedestrian and life safety, but without numerical comparison with real-world experimental results, the results, by definition, are only theoretical. The danger is that they produce such visually convincing motion that the viewer inherently trusts the results, where no numerical, scientific confidence has been proven.

2. Section 2.2 - Mechanical interactions - This section describes a potentially very useful combination of equations / sub-models to estimate contact, forces, frictional effects, deformation etc. but it really needs a referenced set of parameters which should be used in the equations, including where the referenced data source comes from for each parameter, otherwise they appear to be theoretical only. Table 1 is given later, but it gives no referenced sources for the parametric values.

3. The Discussion section 4.1 states that these mathematical operations in 2D may be questioned, in terms of height and hands. I agree that it may be questioned, but at a more fundamental level in the context of contact and force: when lateral contact force is applied to a shoulder, then the force applied will result in pedestrian movement and resistance pivoting from the standing foot / feet. If we are to realistically model pressure and movement, ignoring the standing feet and contact with ground seems to be an oversight.

4. Overall, the Discussion section is firstly scientific discussion (4.1) followed by further sections which read like a user manual. It might be better to have a separate section 'Instructions to use' or a separate appendix which described precisely how the user should run the software, command by command.

5. In section 4.4, the authors describe the implementation for bicycles. However, to implement bicycles before running any form of real-world validation on the base pedestrians seems like continuing to expand functionality before fully testing or validating the base components.

6. The conclusion states that the representation is much more faithful than typical modelling, but the paper documents no numerical evidence to support this claim. At a fundamental level, the reviewer believes this needs to be addressed before publication in a scientific publication.

7. Unfortunately, without any form of numerical validation, testing against real world results, the outcomes of the simulations may not be used to confidently predict real-world crowd movement or conditions.

Requested, significant, changes to content:

1. The reviewer strongly urges the authors to create a series of validation tests. Some testing of the real-world compressibility of bodies in crowd situations are available, and could be compared with, for example: a. Yoshimura, H. (2012). Estimation of crowd density by pressure on human body under experimentally overcrowded condition. In Proceedings of the 5th International Symposium on Human Behaviour in Fires (HBIF 2012). Interscience Communications Ltd. (and more recently) b. Rongyong Zhao, Arifur Rahman, Bingyu Wei, Cuiling Li, Yunlong Ma, Yuxing Cai, Lingchen Han, A literature review of contacting force measurement methods for pedestrian crowds, Heliyon, Volume 10, Issue 21, 2024, https://doi.org/10.1016/j.heliyon.2024.e39755.

2. Please address the changes listed in the 'weaknesses' Section 2.2 - Mechanical interactions where the referee requests a referenced set of parameters which should be used in the model in order to achieve realistic results from the simulations.

Line by line comments: 3. In the abstract, the authors states "Both can readily be called", but in the preceding sentence you say that the tool consists of an online platform, with a graphical user interface, based on anthropometric data, and a C++ library. There are 4 items here: platform, GUI, data, library. I think you mean the online platform and the C++ library, but It would be clearer to state explicitly which elements can be called from Python. 4. Also in the abstract, the authors state that the scripts "leave free reins to the user for" but this is a strange phrase to use here - better to be clear, maybe "which enable the user to fully control" is better? 5. Line 43, delete "yet"". 6. Line 46, states "Most existing crowd dynamics models [2, 5, 7] represent pedestrians as disks". While this is true, it seems an oversight to not mention the other models which have simulated people as several circles before (at this stage in the text), such as Evac(https://sarjaweb.vtt.fi/pdf/workingpapers/2009/W119.pdf), Langston et al (https://doi.org/10.1016/j.ssci.2005.11.007) and Simulex (https://doi.org/10.1016/0379-7112(95)00019-P). These models do simulate people up to about 6-8 people/m2. 7. Line 58. The authors talk of turning to 'an alternative solution'. This gives the impression that this work is the first to use several circles to model the body form for a full pedestrian dynamics simulation, but it is not. However, it does improve on previous models, so should be phrased in those terms. 8. Line 60 and 61 is split around the insertion of a figure, even cuting a word in half. This shoudl be changed to be more readable. 9. Line 62 - 64 states that "Despite extensive research"on granular dynamics models rarely integrate non single-circle shapes, but there are several instances of models which have done this with multiple circles before, with some examples listed in item 5 above. 10. Line 124. Please provide a scientific defintion of "torso height". Is it measured between which skeletal or muscular points? 11. Line 125. Insert 'that'in between fact and fatalities to fix the grammar. 12. Line 159 states that dynamic contact "follows Coulomb's law" and while the code implementation may do so, there is no documented evidence for how it may be calibrated or tested in this context or implementation. 13. Line 167 states "leaves free reins". Wherever this phrase is used, please replace it with objective scientific terminology, where it would be better to say (in this example) that it 'enables the user to control or define the parameters'. 14. Line 220, where Youngs Modulus, and related intrinsic properties are quoted, we need documented evidsence for how these equations are calibrated or justified for the application of compressibility/'spring' for human bodies. 15. Line 365 - "You should run these tests each time you modify". It would be better to say "These tests should be repeated, after each modification to C++ code or data files." 16. Line 403 - the authors state that "these tests yielded the expected outcomes" but while the tests produced nice, detailed, convincing animations, they are only qualitative, viewer-specific tests and are not scientifically rigorous, with documented quantifiable outcomes. 17. The values in Table 1, for the example application, are critical to the level of realism achieved in the simulation. It is excellent that they are clearly documented, but we need references for each parameter. The evidence needs to be referenced or documented. 18. One general comment is that many of the figures multiple line captions. Somtimes, ten lines or more. It would aid reabaility to have a shorter caption and related explanation in the body of the text. 19. Line 635, 636, the authors state that the model is "much more faithful" than other models but unfortunately, there is no numerical proof for this claim, other than the geometric form of 5 circles is a (more geometrically accurate) incremental improvement over the previous 3 circle forms of modelling.

Ask for major revision

Synopsis

LEMONS proposes a theoretical model of dense crowds in which individuals are subject to contact forces. LEMONS also provides a free and open software implementation of algorithms derived from the model. LEMONS models human bodies, in 2D, through five overlapping circles. This allows harnessing models of contact forces based on imaginary springs between circular bodies. These contact models are well understood, and they are well accepted for granular matter.

Strenghts

1. To my knowledge, this is the first work that explicitly models contact forces according to the state-of-the art of granular matter spring models. Former models tend to postulate a “repulsive force” between bodies, which achieves a form of collision avoidance but cannot deal with friction, or deformation. It seems very plausible to me to assume that the contact forces in very dense crowds are similar to those observed for granular matter.

2. The idea to approximate the human body in 2D, through five circles, and, thus, to be able to harness “classic” contact force models among spheres, is simple and elegant.

3. The authors do not only offer a theory, but also a free and open-source implementation, thus, paving the ground for other researchers. They also facilitate validation (or falsification). I find this commendable.

4. LEMONS has a set of tests that one should execute when changing code so that one does not, unintentionally, destroy desirable program properties. This is the nucleus of an integrated test pipeline.

5. LEMONS is easy to find, and easily accessible through github. Its license is compatible with GNU GPL. The repository contains documentation and it appears structured. Configuration is through files, that is, it takes place on a high level. A glance at the code revealed readable code that appeared clean ( as defined by Robert C. Martin: https://gist.github.com/wojteklu/73c6914cc446146b8b533c0988cf8d29) ). A Python-wrapper makes the functionality accessible for a wider community, while the C++ program core facilitates object-orientation and a modular structure.

6. My team have downloaded and run the software. They found it quite enjoyable and consider the documentation clear, well-structured and easy to navigate.

Weaknesses

Before I go into weaknesses and suggestions for improvements, I would like to underline that, in my eyes, the strengths, even if only stated briefly, outweigh the weaknesses by far.

1. The authors express the opinion, in their first sentence in the introduction, that Newtonian mechanics is the accepted model for pedestrian locomotion towards a target: “From an external physical standpoint, pedestrians are just mechanical bodies obeying Newton’s equations of motion”. However, this is not a universally accepted truth. Indeed, we have seen the advent of velocity-based ordinary differential equation models who seek to avoid the “behavioural” oscillations of the harmonic oscillator. We also see a number of models that do not rely on differential equations at all, but prefer utility-based (homo economicus), heuristic, or even stochastic decision making for their agents. Given the fact that human motion is bi-pedal, and thus step wise, and that it is will-driven, I find that one cannot ignore the arguments behind these models and claim that Newtonian mechanics is physically correct. I ask the authors to find a less general formulation such as “In this work, we consider pedestrians as mechanical bodies obeying…”.

2. The model implementation relies on Newtonian mechanics not only for the contact forces, but also for contact-free motion towards a target. I find this a pity, because modellers, who feel that social-force-like locomotion does not capture the behaviour that they are interested in, cannot build on LEMONS. I would welcome a way to interface with other locomotion models. One would perhaps start with velocity-based ODE models.

3. The sample bottleneck in the Fig. 9 shows body orientations that do not reflect queuing behaviour. Even if one assumes “competitive” behaviour, which is an exception rather than the rule, humans would be able to “negotiate” and “wiggle through”. This underlines, that the model may not be valid for scenarios that are not dense from all sides. More validation tests appear in order, possibly some calibration. Most likely one will end up with stating limitations.

4. While LEMONS has its own set of tests that are to be executed with each software change for verification, there are also standardized validation tests against empirical data: above all, I recommend ISO 20414 and NIST TN 1833. If LEMONS passed at least some of these tests, the community would certainly be more inclined to trust the new model. There even is a bottleneck test with a base scenario very similar to Fig. 9. Why not build on it?

5. While the code is on github, which is great, it is on author Oscar Dufour’s personal space. What will happen if he leaves academia? Who will guarantee continued access?

6. LEMON does not have a CI (continuous integration) pipeline with automatic and compulsory tests before programmers push code to the repository.

7. One small improvement for the documentation would be to add a note to the Test tab indicating that the current files and paths are set up for macOS and that users of Linux or Windows need to adjust them accordingly. A brief reminder in the documentation would enhance clarity and usability for all users.

1. My only “hard” request for revision is, that the authors discuss the limitation that comes with modelling non-dense scenarios through a harmonic oscillator type model, that is, as force-driven locomotion towards a target. For future work: I think that the value for the scientific community would be much greater still, if the authors also found a way to interface with velocity-based differential equation models or, even better, with models that, for non-contact scenarios, forgo differential equations all together.

2. A second “softer” suggestion is, that the authors discuss that the queuing in Fig. 9., does not reflect empirical observation. As such, the current model may be limited to very dense situations where agents have contacts to others from all sides.

Publish (surpasses expectations and criteria for this Journal; among top 10%)