Academia.eduAcademia.edu

Figure 7 – uploaded by Remo Suppi

See full PDFdownloadDownload figure
Fig. 7. Speedup and efficiency over 32 cores for different sizes of simulated space (up to x6). Although this is not an issue imposed by the HPC architecture, it is necessary consider this situation to orient to researcher to introduce changes in the model. The researcher should convert the model (or redesign) to avoid the large model data utilization which will result in a performance reductions. The memory problems for large models is a common issue in the Netlogo community and basically are defined by the amount of memory required to represent the agent’s elements and by the constraints imposed by the Java runtime environment.

Figure 7 Speedup and efficiency over 32 cores for different sizes of simulated space (up to x6). Although this is not an issue imposed by the HPC architecture, it is necessary consider this situation to orient to researcher to introduce changes in the model. The researcher should convert the model (or redesign) to avoid the large model data utilization which will result in a performance reductions. The memory problems for large models is a common issue in the Netlogo community and basically are defined by the amount of memory required to represent the agent’s elements and by the constraints imposed by the Java runtime environment.

Related Figures (7)

In the developed environment's, the Frontend service analyzes the user-specified model. From this, generates all configuration files required for the proposed simulation scenarios, creates the initialization files for the high-performance cluster queue system and then sends them to Backend. There the system executes the experiment and when it finishes, user can see the result through the same web interface. Figure 1 shows the proposed architecture.
In the developed environment's, the Frontend service analyzes the user-specified model. From this, generates all configuration files required for the proposed simulation scenarios, creates the initialization files for the high-performance cluster queue system and then sends them to Backend. There the system executes the experiment and when it finishes, user can see the result through the same web interface. Figure 1 shows the proposed architecture.
Fig. 3. User interface. Fig. 2. Stages of the ABM simulation execution process.
Fig. 3. User interface. Fig. 2. Stages of the ABM simulation execution process.
In order to maintain the confidentiality of the data during the whole process, the interaction with the Frontend/Backend is through secure protocols (https in the case of Fronted and SSH+PKI in the case of the cluster). Figure 2 shows the steps that are performed in the proposed infrastructure and figure 3 is an example of the graphical user interface.
In order to maintain the confidentiality of the data during the whole process, the interaction with the Frontend/Backend is through secure protocols (https in the case of Fronted and SSH+PKI in the case of the cluster). Figure 2 shows the steps that are performed in the proposed infrastructure and figure 3 is an example of the graphical user interface.
Fig. 4. Interactive graphical visualization interface of the Fire.nlogo simulation on Netlogo.
Fig. 4. Interactive graphical visualization interface of the Fire.nlogo simulation on Netlogo.
Fig. 5. Speedup and efficiency from 8 to 64 cores. Figure 5 shows the scalability of a fixed density value, while distributing the replicates to the different cores in the HPC cluster. As can be observed, the speedup results are very satisfying, although by starting from 32 cores, the values of speedup begin to move away from the linear value. The justification for it is that all cores share the disk and, although there are no communications between the executions because they are parametric simulations, the input/output is in the same NFS disk and this does as containment system for a high number of processes. However, it can be observed that the performance of the HPC architecture is fine and the efficiency values remain above 87%.
Fig. 5. Speedup and efficiency from 8 to 64 cores. Figure 5 shows the scalability of a fixed density value, while distributing the replicates to the different cores in the HPC cluster. As can be observed, the speedup results are very satisfying, although by starting from 32 cores, the values of speedup begin to move away from the linear value. The justification for it is that all cores share the disk and, although there are no communications between the executions because they are parametric simulations, the input/output is in the same NFS disk and this does as containment system for a high number of processes. However, it can be observed that the performance of the HPC architecture is fine and the efficiency values remain above 87%.
Fig. 4. Comparison of two executions experiments for the same density values.
Fig. 4. Comparison of two executions experiments for the same density values.
Fig. 6. Mean, median, min/max, Q1/Q3 values for execution time on 32 and 64 cores.
Fig. 6. Mean, median, min/max, Q1/Q3 values for execution time on 32 and 64 cores.
580 California St., Suite 400
San Francisco, CA, 94104
© 2025 Academia. All rights reserved