In this exercise you will create a program system for modeling the trajectories and fate of objects or substances drifting in the ocean (e.g copepods, salmon lice, garbage...). You will also write a small web application to examine and visualize results from simulations.
In order to perform real simulations you will be provided with the following
data (in the data/
folder):
- A grid definition file:
grid.grd
. The grid used in this exercise is unstructured and triangular (obtained from the FVCOM ocean model). The grid file has three parts:- Line 1 is header with two integers: number of elements (triangles) and number of nodes.
- Lines 2 - (nElements + 1) has three integer, indexing coordinates of the corners of each element (triangle).
- Lines (nElements + 2) -> has two real number which are the coordinates of a node in meters in the UTM-33 projection.
- 24 velocity files
uv-N.dat
containing the current velocity components in m/s for each node. Each file represents one hour. - A particle file
particles.dat
with initial positions for particles, in the UTM-33 projection.
The steps required to simulate the trajectory (movement over time) of a particle are as follows:
- Read and initialize the grid.
- Read the velocities (u,v) for the current hour.
- Locate the element (triangle) which contains the particle coordinates (x, y).
- Look up the velocity of the element.
- Advect (move) the particle using the following formula: (x', y') = (x + u * dt, y + v * dt), where dt is the timestep (e.g. 60.0-600.0 s)
- Increment time by dt. If time is larger than the defined simulation time, stop. Otherwise:
goto 2
.
We well concern ourselves with two coordinates systems, with corresponding projections: UTM-33 and WGS84. WGS84 is based on spherical coordinates (degrees latitude and longitude), whereas UTM is Cartesian (meters).
For simulating trajectories it's vastly more convenient to work with Cartesian coordinates in UTM, than with spherical coordinates.
For plotting features on a map we must use WGS84, as the Leaflet mapping library only supports WGS84 out of the box.
Getting projections and transformations right is tricky business, so you have
been given two functions toLatLon
and fromLatLon
which will do the job for
you. They are available in src/Server/UTM.fs
.
- Read and plot particles
- Server side
- Read the particles from
particles.dat
. - Create a REST endpoint
/api/getParticles
to fetch the particles as JSON.
- Read the particles from
- Client side
- Fetch the initial particles from the server
- Plot the particles on the map.
- Server side
- Read and initialize the grid
- Server side
- Read the grid from
grid.grd
. - Calculate and print the bounding box (min and max coordinates) of the grid.
- Write a function to find which element a coordinate is inside (Hint: triangle interior).
- Calculate and print the initial element of each particle
- Create a REST endpoint
/api/getGrid
to fetch the grid.
- Read the grid from
- Client side
- Fetch the grid from the server and plot it on the map. NB! The grid is quite big (~50 000 elements), so this will torture your browser.
- Add a button to toggle the grid visibility.
- Server side
- Advect particles
- Server side
- Implement advection for the particles (see above). If a particles ends up outside the grid, leave it where it is and ignore it.
- Implement time stepping for up to 24 hours, using the correct velocity data.
- Keep the particle positions (simulation frame) for every hour, i.e. 24 frames per simulated day.
- Implement long simulations by wrapping velocity data.
- Implement a REST
/api/getFrame/{N}
endpoint to fetch frames
- Client side
- Load particle frames from the server and plot the particles
- Add buttons to time step back and forth through frames
- Add a play button to animate frames
- Server side
- Interactive simulations
- Server side
- Add a REST endpoint
/api/initSimulation
to send in initial particle positions, a timestep and simulation length - Add an endpoint
/api/runSimulation
to run the current simulation - Add an endpoint
/api/stepSimulation
to step the current simulation by one hour - Make advection more efficient by restricting the element search space (Hint: Maps and Sets are your friends)
- Add a REST endpoint
- Client side
- Add inputs for defining a new simulation: timestep, simulation time, number of particles, radius
- Initialize the particles by double-clicking on the map. This should randomly add the specified number of particles within the given radius
- Add buttons to run the whole calculation, or step trough it interactively
- Server side
A short written report must be included. The purpose is to help the review process. It should list what has been done and what has not, what is working and what is not. It should also mention anything else of importance, like if the code is not compiling, design choices, etc.
You will not be graded for the report. But not delivering are report or misreporting can cause a deduction of points. And remember, keep it short!
Please comment your code (except when obvious or trivial) to help reviewers understand your thinking. When implementing algorithms, provide a short description of the strategy and implementation.
The exercise is provided as a home exam, due 7.6.2021 at 12:00.
- Use the starter code available in GitHub classroom
- Do not modify files or code blocks marked DO NOT MODIFY.
- Questions must be asked in the open on Canvas.
- The code should compile and run using
dotnet run
from the top-level directory. - The exam must be submitted on WiseFlow as a pdf document with the code
archive as an attachment:
- The submitted code should be cleaned from the following directories:
node_modules .fake .fable deploy src/*/bin src/*/obj src/*/js
- The archive should contain the
.git
folder. - The archive should unpack directly into a folder named with the candidate's
identifier (not your name!), e.g.
mv inf-3910-drifter 123; tar fcz 123.tgz 123
- The submitted code should be cleaned from the following directories:
- If you find a bug in the starter code, please let me know, and I'll post a fix.
- Any updates to the starter code or to the exercise will be posted to the starter repository on GitHub and announced on Canvas.
The grading of the exam will be based on the following criteria:
- Functionality, i.e. what works and what does not.
- Usage of functional constructs and functional style.
- Cleanliness of the code and project.
The provided starter code contains a skeleton client-server project. The
project should be compiled and run using dotnet run
from the top-level folder.
Do not modify files marked as so.
NB! There are two versions of the Client starter code; The default is
is based on Elmish, the other is based on React Hooks and Reducers, and is
available in src/Client/react
. Choose whichever version you prefer.
You'll need to install the following pre-requisites in order to build SAFE applications
- .NET Core SDK 5.0 or higher
- Node LTS
Before you run the project for the first time only you must install dotnet "local tools" with this command:
dotnet tool restore
To concurrently run the server and the client components in watch mode use the following command:
dotnet run
Then open http://localhost:8080
in your browser.
The build project in root directory contains a couple of different build targets. You can specify them after --
(target name is case-insensitive).
You will find more documentation about the used F# components at the following places:
Oceanography and particle simulations:
Good luck, and may the Foo be with you!