In [1]:
%pylab inline
Similarly to the "ADCP class" and the "TideGauge class", the "Drifter class" is a measurement-based object.
As any other library in Python, PySeidon has to be first imported before to be used. Here we will use an alternative import statement compared to the one previoulsy presented:
In [2]:
from pyseidon import *
Star here means all. Usually this form of statements would import the entire library. In the case of PySeidon, this statement will import the following object classes: FVCOM, Station, Validation, ADCP, Tidegauge and Drifter. Only the TideGauge class will be tackle in this tutorial. However note should note that the architecture design and functioning between each classes are very similar.
Python is by definition an object oriented language...and so is matlab. PySeidon is based on this notion of object, so let us define our first "Drifter" object.
Exercise 1:
Answer:
In [3]:
Drifter?
According to the documentation, in order to define a Drifter object, the only required input is a *filename. This string input represents path to a file (e.g. testAdcp=Drifter('./path_to_matlab_file/filename') and whose file must be a matlab file (i.e. *.mat).
Note that, at the current stage, the package only handle a certain type of file and data format. A template for the TideGauge file/data format is provided in the package under data4tutorial
Exercise 2:
Answer:
In [4]:
drift = Drifter('./data4tutorial/drifter_GP_01aug2013.mat')
The TideGauge object possesses 3 attributes and 2 methods. They would appear by typing tg. Tab for instance.
An attribute is a quantity intrinsic to its object. A method is an intrinsic function which changes an attribute of its object. Contrarily a function will generate its own output:
The Station attributes are:
The Station methods & functions are:
Exercise 3:
Answer:
In [5]:
drift.Plots.trajectories()
As beta tester, your first assignement is to report bugs...yet not everything is a bug. The first thing to check before to report a bug is to verify that your version of PySeidon is up-to-date. The best way to keep up with the package evolution is to git to clone the repository, use pull to update it and re-install it if needed.
The second thing to check before to report a bug is to verify that the bug is reproducible. When running into a bug, double check that your inputs fit the description of the documentation then turn the debug flag on (e.g. output = tidegaugeobject.function(inputs, debug=True)) and submit the command again. If the error re-occurs then report it (i.e. copy entire error message + command and send it to package administrator)
Your second role as beta-tester is to submit suggestions and critics to the developpers regarding the functioning and functionality of the package. Beta testing phase is the best opportunity to steer a project towards the applications you would like to be tackled...