Centralize functionality in a `module`

[navidcy]

At the moment it seems that the workflow is to re-define all functions at the top of each notebook. This could lead to confusion.

Even if we thoroughly test that the function do what we want them to be doing in notebookA.ipynb, then when we copy them in notebookB.ipynb we may have a mistake or anything.

The proper way forward is to write a module that includes all functionalities (derivatives, advection operators, time stepping etc). This module should be continuously tested. When I write here "continuously tested" here I don't imply that we go and test everything continuously in the ocd-sence but that we write simple tests and we use GitHub functionality + e.g., pytest to run these tests every time there is a new commit to the module. As soon as something breaks then we don't merge changes in the module but go back and check why that happened...

Then, in each notebook, call the module and then prescribe particular forcing fields etc, e.g.,

import numpy as np
from numpy import np.pi as π

import toy_model as tm

Lx, Ly = 4000e3, 4000e3

def wind_stress(x, y):
    return np.sin(2π*x*/Lx)

...

tm.advection_x(U/h, dx)

...

The module could also define class of objects (flow fields) and functions that act on them to give, e.g., the mean or other useful quantities.

Perhaps at this point is the right time to decide if we'd like to proceed with Python or Julia. I don't have a particular preference myself. I just know how to do these things in Julia while in Python I'll have to look it up. But I'm sure everything can be done in Python also.

What do you think @dhruvbhagtani2105, @AndyHoggANU?

[AndyHoggANU]

Yes, in the fullness of time, I agree. But for testing, I quite like having all the code in one spot. Once we know it is working, the final design can import functions.

[dhruvbhagtani]

I think there are pros and cons with each, but since the code snippets are so elementary, maybe we can skip it for now? Meanwhile, I'll learn more on how to implement modules in python.

[navidcy]

@AndyHoggANU, having a module/class which is tested does not need to be in a different file hidden from all.

Perhaps what I really wanted to say is that we should simply test everything. Just because a function is called derivative_x() for me it does not mean it computes the derivative unless I see a test for that. Personally, I do so many mistakes while coding that I don't believe anything.

Now on a different note and perhaps more philosophical I deposit here my 2 cents on the other issue above: But having 10 notebooks that all define 234 function at the top and then start doing some investigation will soon become incomprehensible. Also, in the process of playing around/debugging often one goes and comments out one line "to test something" and then forgets... and then copy all the top 234 functions to the next notebook and for 4 days try to find out "why the code isn't working now" only to realise later that some line was commented out. (All these scenaria taken from real-life experiences.)

[navidcy]

I think there are pros and cons with each, but since the code snippets are so elementary, maybe we can skip it for now? Meanwhile, I'll learn more on how to implement modules in python.

Beware, bugs can appear even in the more elementary of code snippets.

[dhruvbhagtani]

I agree with what you're saying @navidcy. I'll create a module and store it in a different file, and as you mentioned, we'll have it public so we can come back to it if we need to.

[navidcy]

Let’s leave it open then until we do what we decided to do. Don’t need to do it now. I don’t think making a module is first priority. But testing code in notebooks is.

(Open issues act as reminders of what need to be done. If at some point we decide that this is not relevant anymore we’ll close it.)

[dhruvbhagtani]

I've used modules to solve the 1D diffusion equation in this notebook.

[navidcy]

@dhruvbhagtani2105, did you write the Euler module?

import Euler.Euler1D as elr

If so, where is its source. Because if you haven't written it, hen perhaps it's better to stick with code you've written! :)