numerical-mooc / numerical-mooc Goto Github PK

Hello Professor,

I just finished module 1. It was really great!

I noticed that in the screencast video at 13:00, 14:40 and 15:40, the u'(n+1)_dt area is shaded instead of of u'(n)_dt

Bests,
Mostafa

It seems that the roots are returned in a non-deterministic order -- either this is a machine-by-machine thing or has to do with recent changes before SymPy 1.0.

Not a huge deal, but to avoid confusion, we should rewrite that section a bit and then automatically choose the positive root.

Now that display() is a built-in, we don't need calls like from IPython.display import display

See: http://blog.jupyter.org/2017/05/31/release-of-ipython-5-4-6-1-and-rlipython-2/

Sets a trap for the students -- needs to be changed in all notebooks (after explanation in notebook 1 "Beware the CFL") in module 3

Following discussion, we're going to do this the "right" way and only use

from matplotlib import pyplot

pyplot.plot()

Hello

I've finished all the modules and claimed for the badges. I have two suggestions:

First, It'd be a great idea to have an overall badge entitled "Numerical Mooc" issued for the users who have passed all the modules.

Second, the badges verification system is currently running on port 5000 (openedx.seas.gwu.edu:5000) which might be blocked by some university firewalls. It's possible to use rewrite rules to serve the badges over the standard port (e.g. openedx.seas.gwu.edu/badges/).

Thank you for this great work
Hope to see CFD-Mooc (FVM, FEM and CVFEM) soon

In email conversation, @bknaepen said his curriculum included Monte Carlo, a topic we've not covered in numerical-mooc. Recently, I talked with @afeiguin (Adrian) who teaches a computational physics course at Northeastern University:
http://www.northeastern.edu/afeiguin/phys5870/

I introduced Adrian to Jupyter and he is enthusiastic about adopting Python for his course. We have an opportunity here to collaborate in the development of a new module on Monte Carlo methods — @IanHawke was also interested, and he's got some Python code for one of the NGCM modules.

Let's start a discussion here about how a module on MC might look like and how to pull our resources together to make it happen!

The code uses V_max for the maximum traffic speed, but everywhere else we are using "u" for the traffic speed. This variable name should be changed for consistency.

http://nbviewer.ipython.org/github/numerical-mooc/numerical-mooc/blob/master/lessons/03_wave/03_01_conservationLaw.ipynb

In the jupyter notebook file here, the script is using numpy.pi in In [8], which will return a 6.28 for two pi.

In this case, I would suggest using sympy.pi instead, which would be neater, and it will do the same work with numpy.pi.

Hello,

I have developed the code for the assignment. I think there are several parts that are ambiguous:
1- It is not clear from the figure that what is the propellant burn rate at t=5. Is it 20 or 0?
2- When using Euler method, f(u) has to be evaluated at t=n (and not t=n+1 or n+1/2).Is it right?
3- Using the dt=0.1 of the assignment, there is no discrete point with h=0 to find when the rocket impacted the ground. Shall I use linear interpolation to find associated time and velocity of h=0 point?

I got the following results by assuming mdot=20 at t=5 and evaluate f(u) at t=n

Vmax is: 237.2
t @ Vmax is: 5.1
h @ Vmax is: 546.73
hmax is: 1372.04
t @ hmax is: 15.9

but the system doesn't approve them.

Thanks

Hi all,

I'd like to suggest, as per the Google Python Style Guide that we not use

import numpy as np

and instead just

import numpy

Also per the style guide,

import matplotlib.pyplot as plt

is totally fine, as that's preposterously long to write out each time, but I do think it helps people better understand the libraries they're using (as they start out) to have to call them explicitly, just as we're doing with sympy in the first notebook.

I know the import numpy as np is a convention, but it's a bad convention.

I've just pushed the master branch from the private repo to here. To start using this repo, you'll want to do something like:

git remote rename origin old
git remote add origin [email protected]:numerical-mooc/numerical-mooc.git

Once everybody is comfortably set up with the new repo, I'll close this.

Use something like

$$ \begin{equation} \parallel \mathbf{p}^{k+1} - \mathbf{p}^k \parallel_{L_2} = \sqrt{\sum_{i, j} \big| p_{ij}^{k+1} - p_{ij}^k \big|^2} \end{equation} $$

and for the relative L2 norm:

$$ \begin{equation} \frac{\parallel \mathbf{p}^{k+1} - \mathbf{p}^k \parallel_{L_2}}{\parallel \mathbf{p}^k \parallel_{L_2}} = \frac{\sqrt{\sum_{i, j} \big| p_{ij}^{k+1} - p_{ij}^k \big|^2}}{\sqrt{\sum_{i, j} \big| p_{ij}^k \big|^2}} \end{equation} $$

The third python cell of the above notebook reads:

u = numpy.ones(nx) #numpy function ones()
u[.5/dx : 1/dx+1]=2 #setting u = 2 between 0.5 and 1 as per our I.C.s

print(u)

Is it safe to assume that .5/dx and 1/dx + 1 will always convert to the intended integer values? Isn't it better to call the round function to make sure as in?

u = numpy.ones(nx) #numpy function ones()
start = round(.5/dx)
end = round(1/dx)
u[start : end +1] = 2 #setting u = 2 between 0.5 and 1 as per our I.C.s

print(u)

Cheers,
Bernard.

Notebook: Lesson 4 of Module 5.

Problem: In the section "More difficult Poisson problems", there is a mismatch in the last of the source term between the mathematical equation (with cos) and the Python implementation (with sin).

Solution: We need to fix the last term of the Python implementation (sin -> cos).