OpEc (Operational Ecology) will use the EU’s Global Monitoring for Environment and Security Marine Service as 
a framework and feed directly into the research and development of innovative global monitoring products or 
applications. This in turn will advise policies such as the European Marine Strategy Framework Directive and 
Common Fisheries Policy, as well as the continued monitoring of climate change and assessments of mitigation 
and adaptation strategies.

The programme will focus on four European regional seas (North-East Atlantic, Baltic, Mediterranean and Black
Seas) and plans to implement a prototype ecological Marine Forecast System, which will include hydrodynamics,
lower and higher trophic levels (plankton to fish) and biological data assimilation.        

Products and services generated by OPEC will provide tools and information for environmental managers, 
policymakers and other related industries, laying the foundations for the next generation of operational 
ecological products and identification of knowledge / data gaps.

See 'how_to_use.txt' for installation and usage notes.

Coding Conventions (loosely based on http://www.python.org/dev/peps/pep-0008/ and http://google-styleguide.googlecode.com/svn/trunk/pyguide.html):

- Use 4 spaces per indentation level
- Never mix tabs and spaces
- Imports should usually be on separate lines
- However, *from subprocess import Popen, PIPE* is ok, too
- from module import * is not ok, though; rather, use from module import name
- Imports are always put at the top of the file
- Avoid extraneous whitespace
- Use parentheses sparingly
- This does not apply to binary operators
- Don't use spaces around the = sign when used to indicate a keyword argument or a default parameter value
- Don't put an if/for/while with a small body on a single line
- Do not terminate your lines with semi-colons and do not use semi-colons to put two commands on the same line
- If a class inherits from no other base classes, explicitly inherit from object. This also applies to nested classes.
- As to naming conventions, generally Java conventions apply
- Function names should be lowercase, underscore separated
- Names of members considered private shall start with two underscores
- Use lambda expressions only for one-liners (else: hard to read and to debug)
- Use properties for accessing or setting data where you would normally have used simple, lightweight accessor or setter methods
- Avoid fancy features such as metaclasses, access to bytecode, on-the-fly compilation, dynamic inheritance, object reparenting, import hacks, reflection, modification of system internals as far as possible
- Explicitly close files and sockets when done with them
- Use TODO comments for code that is temporary, a short-term solution, or good-enough but not perfect