The main objective of this project was to develop an agent-based model (ABM) for studying a shipwreck’s site formation process (SFP). ABM are computational tools used for modeling complex adaptive systems in order to understand both the rules that make them up and the emergent phenomena that arise from them.
In maritime archaeology, the study of shipwreck SFP aims at understanding how “a highly organised and dynamic assemblage of artefacts [the sailing ship] is transformed into a static and disorganised state with long-term stability [the shipwreck site]” [Muckelroy, 1978, p. 175]. The project’s rationale was that ABM would allow archaeologists to postulate more refined and experimentally supported interpretations of SFP by testing different historical scenarios. This would be particularly true for maritime archaeologists studying shipwreck SFP.
For developing the shipwreck SFP ABM, I took as a case study the USS Somers, a 19th-century brig-of-war that sank in 1846 off the port of Veracruz, Mexico, during the Mexican-American War. Some of the research questions I tried to answer with the Somers ABM included: What was the SFP of the Somers wreck site? What were the characteristics and interactions of the social and natural elements that resulted in today’s shipwreck configuration? How much of the shipwreck SFP is possible to know from the surface record only, that is, without excavating it?
Developing the Somers ABM project involved four stages:
Building a conceptual model. I first defined all the elements that would constitute the ABM based on historical data about the ship’s nautical characteristics and operation, information on the wrecking event from eyewitnesses, and modern environmental data. These included agents (ship, sediment, organisms, currents), variables (materials, densities, salvage value, salvage difficulty, etc.), processes (setup, execution, wood degradation, metal corrosion, salvage operations), and indicators (ship degradation, deposition sequence).
In ABM, agents are defined as any “autonomous object with particular properties, actions, and possibly goals” [Wilenksy and Rand, 2015, p. 32]. Thus, an agent may be any element that interacts in a simulation environment; they may update their internal condition or take actions based on information exchange.
Creating a detailed 3D model of the ship. Based on the original lines plans of the Somers, I created a 3D model of most of the ship’s structural elements and accessories using Rhinoceros. This model would constitute the main set of agents to be used in the ABM simulations.
A detailed 3D model of the USS Somers, created from the original plans.
Developing the ABM simulation platform. This was the most time-consuming part of the project, which involved selecting an appropriate simulation environment, becoming familiar with its features and programming language, programming all the ABM code, and verifying its contents and performance. The Somers ABM was developed in Unreal Engine 4.
The initial screen of the Somers ABM simulation platform in Unreal Engine 4.
Testing historical and archaeological hypotheses. Using the ABM simulation platform, various possible scenarios of the SFP were explored, contrasting their results with the archaeological record of the shipwreck.
Once the simulation platform was verified, various historical hypotheses about the SFP were tested.
Time Needed
When did you begin this project? When did you complete this project?
Time Span: September 2018 - February 2021
Length: 2.5 years, part-time.
Outcomes
What is the outcome of the project?
This project resulted in an agent-based model that was used for testing historical and archaeological hypotheses about the site formation process of the USS Somers (1846) shipwreck. The ABM is available at the project’s online repository.1
The 3D model of the Somers that was used in the ABM simulations is available on Sketchfab and can be accessed here.
A short video (in Spanish) in which some details of the ABM and one of the simulation scenarios of the Somers’ site formation process are shown. It can be accessed here.
Resources
What tools, resources, programs, or equipment did you use for this project?
This project was developed in a Toshiba Satellite L45 laptop, with an Intel Core i5-5200U processor, 2.20 GHz CPU, and 12 GB RAM, running on Windows 10 (x64).
The 3D model of the USS Somers was created using Rhinoceros version 6 (Robert McNeel & Associates). For most of the structure and accessories, I used as template a 2D model of the ship created by maritime archaeologist Jorge M. Herrera. This 2D model is based on the ship’s original lines plans published by naval historian Howard I. Chapelle in The history of the American sailing Navy: the ships and their development (Bonanza, New York, 1949).
Please describe any costs incurred for this project, and (if relevant) how you secured funding for these costs.
This development project did not receive any specific funding, and the entire work was carried out by the author using his personal computer.
However, the project was developed in the context of the Proyecto Arqueología Marítima de la Guerra de Intervención 1846-1848 (PAMGI), a maritime archaeology research project being carried out at the Institute of Anthropological Research, National Autonomous University of Mexico, in collaboration with the Centre for Maritime Archaeology at the University of Southampton, UK.
PAMGI was supported by:
The British Academy
Newton Advanced Fellowships Programme (AF160206)
The National Autonomous University of Mexico (UNAM)
PAPIIT program (IA400818)
Laboratory of Oceanographic Vessels and the Coordination of Oceanographic Platforms, Campaña Guerra de Intervención 01 2018 aboard the Oceanographic Vessel Justo Sierra
The National Science and Technology Council (CONACYT), Mexico
Frontier Science Program (CF 2019 / 1327714)
Workflow
Please give an overview of the workflow or process you followed to execute this project, including time estimates where possible.
Project’s background
During the Mexican-American War of 1846-1848, one of the main actions of the invading fleet was blocking Mexican ports, both in the Gulf of Mexico and in the Pacific. Particularly important was the blockade of Veracruz in which the brig USS Somers participated. Somers was one of the last of its class, built with a wooden hull, using traditional techniques, and propelled by sails (figure 1).
Figure 1. Currier, Nathaniel. The U.S. Brig-of-War “Somers”.
On December 8, 1846, the Somers was surprised by a northern (i.e., a strong wind or gale coming from the North, characteristic of the Gulf of Mexico) when pursuing another ship off Veracruz. Despite all efforts by men and officials, the Somers capsized and sank in less than an hour, taking down with it almost half of its crew (figure 2). Some of the survivors were rescued by other ships; others drifted ashore to Veracruz. Two of them, commander Semmes and surgeon Wright, later gave detailed accounts of the wreck, which today constitute our main historical source of the event.
The Somers shipwreck represents an excellent case study for maritime archaeology, particularly for studying shipwreck site formation processes (SFP). We know, on the one hand, the ship’s structural characteristics and the general circumstances that led to its sinking. On the other hand, we know the wreck’s element distribution. However, we do not know the series of events and conditions, both social and natural, that led to the shipwreck’s current state. That is, we do not know the SFP of the Somers shipwreck. The ABM and simulation platform described here were developed to study such SFP.
Building a conceptual model
When developing any ABM, we first create a conceptual model where agents’ characteristics and properties, processes, indicators, and elements for model verification are defined (figure 3). This should precede the development of the ABM to ensure that it will address our research question by exploring different simulation scenarios.
It is useful to write the conceptual model as pseudocode to facilitate their programming in the next stage. Pseudocode is “a midway point between natural language and formal programming language [that] can be read by anyone, regardless of his or her programming knowledge, while, at the same time containing algorithmic structure that makes it easier to implement directly into real code” [Wilensky & Rand, 2015, p. 314].
The following is a brief example of the pseudocode used for handling dates in the Somers ABM. The current-month global variable is used to keep a record of the month to which the EXECUTION process that is running at a given moment corresponds. It is a numeric variable with values from 1 (January) to 12 (December). At the end of each EXECUTION iteration, current-month increases by one unit (returning to 1 after 12). Similarly, the current-year global variable keeps track of the simulated year and increases one unit each time the month changes to “1” (January). The initial values of both variables are set to “12” (December) and “1846”, respectively, corresponding to the date when the Somers sank.
Pseudocode:
Before the simulation starts (SETUP):
Set current-month = 12
Set current-year = 1846
At the end of each EXECUTION process
If current-month < 12, set current-month = current-month + 1
If current-month = 12, set current-month = 1
If current-month = 1, set current-year = current-year + 1
If current-month = simulation-end-month AND current-year = simulation-end-year, stop the simulation
Creating the conceptual model could take from a few hours to several months, depending on the type of questions we are trying to explore with the ABM, the author's expertise in the research area, and the availability of required information and data. The conceptual model for the Somers ABM took about six months to develop since it involved a considerable amount of archival research. It was based on historical data about the ship’s nautical characteristics and operation, information on the wrecking event from eyewitnesses, as well as modern environmental data.
Figure 3. Elements in the conceptual model of the Somers ABM.
Creating a detailed 3D model of the ship
The main set of agents to be used in the ABM simulations would comprise Somers’ structural elements and accessories. These were created as individual 3D models based on the ship’s original lines plans published by the naval historian Howard I. Chapelle in his 1949 book The history of the American sailing Navy: the ships and their development (Bonanza, New York). The original 1842 ship’s plans by naval constructor Samuel Humphreys are currently held in the U.S. National Archives (NARA I) in Washington D.C.
These plans contained precise details on the shape, dimension, and position of most elements of the ship's structure, accessories, and rigging. For those elements not included in the plans, I used other historical documents, such as photographs and videos from extant historical ships, e.g., USS Constitution (1797) and USS Constellation (1854).
Individual 3D models of each of the ship parts were created in Rhinoceros 6 (Robert McNeel & Associates). Depending on expertise with 3D modeling and the particular software to be used, this stage of the project may take from some weeks to a few months. With no prior expertise, I completed this model in about eight months.
Figure 4 shows the final 3D model of the Somers that was used in the ABM simulations. The model is available on Sketchfab and can be accessed here.
Figure 4. A detailed 3D model of the USS Somers, created from the original plans.
Developing the ABM simulation platform
The next step was to develop the ABM in a simulation environment. This involved selecting the most adequate simulation platform, programming all code, and verifying its contents and performance. This stage was the most time-consuming part of the project, spanning almost one year.
The amount of time required for this phase depends greatly on the modeler’s familiarity with the simulation platform and its programming language. Therefore, it is strongly recommended that developing an ABM be an interdisciplinary endeavor, with researchers and programmers working closely together.
Platform selection
The first platform considered for implementing the ABM and carrying out the simulations was NetLogo. This is a simple yet robust programmable environment for simulating complex systems through ABM; it was designed for people who do not necessarily have experience with programming. However, shortly after starting the programming of the Somers ABM on NetLogo, two important limitations became evident, which made it impossible to use in this project.
The first is that NetLogo does not have a built-in capability for importing geometries, i.e., triangle meshes like the ones generated in 3D modeling software. This can be partially overcome using a model called "Loading geometry into NetLogo 3D" developed by Gabriel Wurzer of the Institute of Architectural Sciences at Vienna University of Technology. However, elements are not imported as solids, meaning that the 3D mesh does not behave as a whole; rather, vertices and edges are imported as independent agents. This, in turn, affects programming and simulating physical processes, such as the movement of the ship’s elements.
The second problem was that such an import process generated several thousands of agents per individual element, causing the platform to crash since it almost immediately exhausted its computational capacity.
Because of these issues, I looked for other software alternatives that would allow the simulation of physical processes, importing complex geometries, and creating customized functions and variables using a relatively simple programming language. I chose Unreal Engine 4.25 (UE4), a video game engine that has also been used for research and teaching.
The reasons for choosing this particular game engine were:
It is open source, i.e., free for non-commercial applications.
Allows the import and management of geometry in a wide variety of formats.
It has a built-in module for simulating physical processes, so it is not necessary to program them.
It has a visual programming language (based on C++), so no coding is required.
Allows creating personalized functions and variables.
Allows the creation of a wide variety of agents (actors) combining geometries, materials, variables, and functions.
In addition to UE4’s built-in functions, I used two plugins that were very useful for programming the simulation: Victory Plugin developed by Rama, and Easy File Dialog by Firefly Studio. These added various functions and capabilities such as vertex exportation and handling of external files with user-defined dialog boxes. A big thank you to their authors for developing these plugins and making them freely available to the UE4 community.
The Somers ABM
In UE4, each element that participates in the simulation is called an actor. These are not strictly identical to agents (in the ABM sense) since UE actors can comprise different components (geometries, animation elements, physics handlers, etc.). For example, the ship’s keel is made up of a single element, therefore, the actor who represents it has a single component. On the other hand, artillery pieces or anchors are each made up of several elements, and therefore the actors who represent them have dozens of components. Since variables and functions may affect either the actor as a whole or each of its individual components separately, in reality, each component of each actor constitutes an agent in the ABM.
Taking advantage of the actor class hierarchy in UE4, I created a "parent" agent called Piece that works as a generic actor and serves as the basis for creating all other actors (figure 5). In it, all the functions that affected the ship’s elements (e.g., wood degradation, metal corrosion), defined in the conceptual model, were coded. This greatly simplified the initial programming and further modifications that affected all agents, eliminating the need to program and modify each agent individually. This means, for example, that if a new variable or function needed to be added to all actors, we only needed to include it as part of the Piece parent actor, which would automatically inherit them to every “child” actor that was created based on it.
Figure 5. Components, variables, and code of the Piece actor.
All the variables and processes that agents will execute are defined in this “generic” agent so they can be seamlessly passed down to "child" actors. Also defined here are the components’ materials (oak, pine, iron, brass) used for visual rendering as well their physical properties (friction, restitution, and density) used to simulate physical processes.
In addition to the agents that simulate the parts of the ship and the seabed, I also included a Calculator actor. This is an “invisible” actor that does not interact with others but rather serves as a kind of storage for global variables and indicators. It also handled timing in the simulation (start, advance, and end) and calculated various indicators (figure 6).
Finally, when studying archaeological sites from the perspective of SFP we must be able to locate in time the various natural and social events involved in the process, i.e., to establish a sequence. Therefore, the Somers ABM included a chronological record of two types of events: 1) the degradation and 2) the deposition of every ship’s element.
Figure 6. Part of the code and variables of the Calculator actor.
The Somers ABM simulation platform (figure 7) allows the user to take a "Virtual Tour", exploring the 3D model of Somers (figure 8), or start the “Simulation of the site formation process” and continue to the Configuration screen where the initial conditions of the simulation are established (figure 9).
Figure 7. The Somers ABM start screen.
Figure 8. Virtual tour of Somers.
Figure 9. Configuration screen.
Here the initial conditions for the simulation are set.
The initial conditions are based on the different stages in the wrecking process and the people’s responses in each stage (crew members, survivors, people performing different types of salvage operations) [Gibbs, 2006], which may later alter the shipwreck site formation process and the archaeological site. These conditions specify, for example, whether anchors were dropped, heavy objects were jettisoned, if the boats were used, or if there is any historical record of different types of salvage operations.
Once the initial conditions are confirmed, the simulation of the shipwreck SFP properly begins (figure 10). When the simulation ends, the user is given the option to export as CSV files 1) the indicators’ results defined in the conceptual model; 2) a point cloud containing the positions of all remaining elements (i.e., ship’s pieces) above the sediment; and 3) the Degradation and Deposition logs.
Figure 10. Screenshots from a simulation scenario of the Somers’ SFP.
Images show the sequence of degradation and deposition starting from February 1847 (top left) and ending in August 2018 (bottom right).
Following this link, you can access a video (in Spanish) in which some details of the ABM and one of the simulation scenarios of the Somers’ site formation process are shown: https://youtu.be/0a-b2CkxRgg.
Testing historical and archaeological hypotheses
Once the simulation platform was developed, I ran different scenarios of the SFP to explore different parts of the process for which no historical data is available (figure 11). These were:
the dimensions of the metallic sheathing that covered the hull and the rudder blade
the degree of starboard listing (i.e., inclination) the ship had when it became deposited on the seabed
the number of opportunistic salvage operations that may have been carried out on the shipwreck from the end of the Mexican-American War (1848) to the present.
The results from these simulation scenarios, their interpretation, and implications for maritime archaeology in general and the Somers SFP in particular, will be published in a forthcoming paper.
Figure 11. Different scenarios of the Somers SFP were explored with the ABM.
Dimensions of the metallic sheathing (top), degree of starboard listing (center), and opportunistic salvage operations (bottom).
Challenges & Opportunities
What, if anything, changed between beginning your project and its current/final form?
The main challenge involved learning to use specialized software, i.e., 3D modeling software and a video game engine. Although a very satisfactory process, it naturally required a learning curve that increased the amount of time initially planned for the project.
The most significant change involved the simulation platform. As aforementioned, the project was initially conceived to be implemented in NetLogo but after some weeks of trial and error (and frustration), it became apparent that another platform was required. Switching to UE4 solved most of the initial problems but conveyed other challenges.
We, therefore, advise people interested in developing an ABM to reflect on the complexity that their research questions would require. This would allow for developing a conceptual model that is both simple and comprehensive as well as choosing the appropriate simulation platform. And, as early as possible in the project, to look for counsel and collaboration from people already experienced in such developments.
Is there anything specific you wish you had known when beginning your project that might help other people to know?
Simulation platforms, particularly video game engines, are powerful tools that can help us develop very realistic and complex simulations. However, they usually require hardware configurations that are not included in your everyday personal computer. This can greatly affect your simulation’s performance, to the point of making your computer crash. As much as possible, use high-performance hardware for these types of developments, e.g., “gamer” computers.
Next Steps
Do you have any plans to follow up on this project or work on something similar in the future?
Although the ABM I developed was designed specifically for the Somers SFP, since it is based on general theoretical models applicable to any shipwreck [Gibbs, 2006; Muckelroy, 1978], it could be adapted to other case studies by carrying out some modifications and extensions, including
Incorporating the effect of energetic conditions of the environment and intrusive archaeological operations (i.e., excavation)
Using other ships (e.g., preloaded models of different types of ships)
Choosing between different types of shipwrecks (weather events, grounding, battle damage) and different types of seabed (rocks, sand, gravel, silt, clay)
Publications & Presentations
The entire ABM development and simulation results were included in the undergraduate thesis (in Spanish) titled “Analysis of the site formation process of the USS Somers shipwreck using agent-based modelling”. This thesis was defended in October 2021 for obtaining the BA in Archaeology at the Escuela Nacional de Antropología e Historia (ENAH, México). It is currently being considered for publication as a monograph by British Archaeological Reports.
The ABM and some of the simulation results were presented at the SPARC-UKIERI Digital Heritage Workshop “Endangered Heritage in Mexico and India” organized in December 2021 by the Centre for Digital Humanities at Lancaster University, UK.
Creative Commons Attribution-NonCommercial-NoDerivatives 4.0 International License (CC-BY-NC-ND 4.0)
