Further work has continued on the importation of meteorological data into the program. At this point, the wind data has been implemented; however, each query takes about 0.1 seconds. Because of the number of queries demanded by the algorithm, this is the current bottleneck, and at this rate, the expected completion time for a very finely resolved optimization is over an hour. Within the coming weeks, a new method of data query will have to be developed in order to minimize the query time to 0.5 milliseconds. An accurate current database has been found, and has been implemented into the program. This importation is still being optimized, but already shows potential of being able to query a point faster than the 0.5 millisecond threshold. The importation programs work by allowing the user to query a specific point, at which point a 2D interpolation is performed to give an accurate reading of the meteorological data at that point.
The program is being written in order of execution, and, as a result, the graphical user interface for inputting data is now complete. This interface allows a user to select a start location and end location based on a map of the Mediterranean. The program is flexible enough that a misplaced point (40 km inland, for example) will be readjusted to the nearest water point.
The next portion of the program displays the evaluation area as recommended by the program. The evaluation area is where the nodes and connected grid will be laid down for the optimization algorithm. The recommended area is based off of the start location, end location, and the distance and angle between the two locations. At this point, the user has the possibility to change the evaluation area. This feature was included because, based on the geography, it may be necessary to expand the search area in order that a route be found.
Once the evaluation area has been selected, the user is prompted to enter the ship size. As mentioned in the previous blog post, sailing polars are a function of wind and ship size, therefore, for an accurate evaluation, the ship size must be included. Finally, the user is prompted to enter the evaluation resolution. The evaluation resolution modifies a variety of parameters that change the accuracy with which the optimization if found. These changes to the algorithm include the grid size, coastline accuracy, number of iterations of the ant colony optimization algorithm, and number of local search passes made once the ant colony optimization has finished. The purpose and description of the local search will follow in a future blog post.
Progress had been made in setting up the grid for the any colony optimization, which will likely prove to be a more difficult task, programmatically, than the optimization algorithm itself. While a complete description will be included once this step is complete, one thing can be said now is that the setup will take into account the curvature of the earth in evaluating distances and will consider wind, water, and ship parameters when evaluating speeds.
Further considerations are being made whether or not the keel length will be implemented into the solution. The keel of a ship allows a ship to sail straight. A deep keel allows for straighter travel when experiencing lateral winds but, also, retards the forward travel velocity. A short keel on the other hand will permit a certain amount of lateral drift from the wind but allows for faster velocities. This is the reason why modern racing sailing ships have variable keel lengths. The addition of this may or may not produce a significant change, and will be evaluated in the near future to decide if this variable parameter should be included.
- Writing and debugging the code for the ant colony optimization specifically
- Converting the csv Venice ship data into a readable format
- Adding the feature of defining a maximum travel distance from land for the ships
- Optimizing the algorithm overall for speed efficiency