So what happens? Look at its breakdown:

1	2	2.5	2
2	3.1	3.6	3
3	4.7	5.3	5
4	6	6.5	6
5	7.2	7.9	7
6	8.4	8.9	8
7	9.6	10.1	10
8	10.8	11.3	11

This is such a fascinating sequence! How is it possible? How can we prove that it will skip over all perfect squares? This relies on a few facts that I discovered just by investigating this sequence:

1. The amount of whole numbers in-between two perfect squares is always even. This is easily proven by . Because we want it exclusive, i.e. not counting the number we land on, we still need to take away 1, which gives .
2. Of this even amount, the integer part of is constant. Moreover, half of the outputs will be and half . That’s because half of the inputs are smaller than the inputs midpoint, and half are greater. And because is monotonically increasing, order is preserved.
3. The first output to exceed in its decimal part gets bumped to the next integer by the of the formula.

The post A numeric sequence lends itself for play appeared first on Quick Math Intuitions.

You take a loan for 1000$ with an interest rate of 20% per month. What is your debt after six months?

Obviously the textbook contains the exact formula the student should use to just show that He Knows It, but we’re here for the exploration so we’ll act as if we didn’t know anything other than basic arithmetic.

After the first month, the debt is

After two months,

(1)  

After three months, the reasoning is similar but we have to be careful not to infer the wrong pattern. In fact, it is tempting to say that will be the same as except that all s will be swapped with s, but that would be wrong. If we do the calculation once more, we find

if you haven’t collapsed into a coma and feel like doing it one more time,

do the coefficients ring a bell? It’s a Pascal’s triangle. And it makes sense, as the next term is the sum of the previous term plus the previous term times its own base power . That mixes the terms in just the right way so that they line up perfectly.

So the pattern is

That’s one way, and it gets us somewhere. Now let’s try another road and see how stupid it is and how much of a difference it can make. Think of grouping for 1000:

The pattern here is much more obvious:

which is what the poor children are thought: the debt at month is the base sum times .

It takes nothing to see how quickly it gets out of control. With such a simple formula, it’s possible to ask all sort of questions. For example,

How many months does it take for my debt to double?

so in just about 4 months I’m twice as in debt as I was when I was careless and free. Incredible, few teenagers would believe it.

How much do I have to pay every month so that my debt stays fixed and doesn’t grow?

This is trickier. If we think too narrowly, we may end up imposing

And this only works in the first month, for . Instead, in the first month the debt will grow, and there’s nothing we can do about it.  We need to allow the debt to grow somewhat before we can control it, otherwise we simply wouldn’t take a loan in the first place: we needed those 1000$ that month, and the bank will charge us a fee for having given that upfront. So we’ll get to . The question is how do we stay fixed at 1200$, and not grow beyond it? How can be equal to ?

Well, the question is not quite right. Debt is a thing that evolves constantly, and we can’t bound it month by month. But we can ensure it doesn’t grow beyond a certain point:

which is not quite mindblowing: if every month we accrue 200$ of debt, if we pay them back we get back to the original first month state. But it’s an unstable balance: as soon as this get past the first month and beyond 1200$, then we’d need to recalculate.

The post A fascinating exploration of interest rates appeared first on Quick Math Intuitions.

The simulation domain is 30×1 km, depicting a fjord. The right boundary faces the open ocean, the horizontal top boundary faces the atmosphere, the bottom is the bedrock, the tiny bottom-left vertical boundary stands for a small patch of land, and finally the slanted top-left boundary represents the ice-ocean interface.

On the side is a picture from a square version of the domain and a non-slanted ice shelf that might help render the idea.

Equations

On this domain, we solve the Navier-Stokes equations where the buoyancy force is given as a linear combination of temperature T and salinity S:

from which we obtain velocity and pressure profiles of the ocean. Temperature and salinity are solved for separately:

Both and are constant vectors, accounting for the different viscosity/diffusion in horizontal and vertical directions.

For all the equations above, the weak form is derived so that a FEM formulation can be obtained. We also apply stabilization techniques to both the Navier-Stokes and the T/S equations (GLS for the former, SUPG for the latter). I leave these final equations out of the explanations voluntarily to save you time at this stage, and focus only on the setup we have.

Our implementation is in Python and is based on the FEniCS framework, which provides a toolkit to solve the FEM forms.

We use 2nd degree elements for velocity, while 1st degree elements for pressure, temperature and salinity.

Initial conditions

Temperature and salinity are initialized as stratified with values ranging from -1.6 to 0.4 °C for T, and from 34 to 35 PSU for S. This mimics the actual physical scenario.

Velocity and pressure are initialized to zero everywhere.

Boundary conditions

Boundary conditions are set to reflect the physical scenario.

• Velocity is no-slip on all boundaries, except on the atmosphere interface, where motion is allowed x-wise. (The open ocean boundary is also no-slip, although it should be do-nothing, future project).
• Pressure is set to zero on a point on the atmosphere interface.
• Temperature/Salinity has insulated conditions on most boundaries (i.e. no flow) except on the ice-ocean interface, where a heat/salinity flux term plays the role of a Neumann condition mimicking influx of cold/fresh water coming from the melting ice. The open ocean boundary has instead a Dirichlet condition that matches the initial conditions.

The issue we are seeing

We have so far run the above scenario for 10 days of real-world time. The actual steady state is more around 50-60 days, but we haven’t yet run that long.

What follows is the evolution of the x-velocity and a close-up to a region of interest:

The issue that we are seeing is an overshot of temperature and salinity values in the proximity of the ice shelf, where the influx of colder and fresher water is. The next animations show the temperature evolution for values in the range of the overshot ; in other words, it only shows values above the expected maximum. Salinity exhibits a very similar behavior, except with different values.

My own interpretation is that the large gradient generated by the discontinuous jump between the boundary condition () and the initial value ( for the most part). This causes in turn the solution to overshoot just after the cool/fresh boundary layer.

On the largest part of the domain, this slight inaccuracy soon diffuses away and doesn’t generate much problems, but on the left part of the domain, where both the vertical left boundary and the bottom boundary have no-flux boundary conditions, the extra heat diffuses in the x-direction and results, in the long term, in a sliver of warm+fresh water all alongside the bedrock, which in turn generates spurious velocities down there. The combination of fresh+warm water is heavier than the surrounding area, so it doesn’t rise and stays at the bottom.

After 10 days, T reaches up to 0.42 degrees in that area, which is a 2% error. Given that there is no sign that this overshot would die out with further simulation time, it is reasonable to believe that, after 50 days, the error would be around 10% – grossly inaccurate.

What feels even weirder is that, in the bottom-left region, this overshot does not die out in time as it does on the rest of the ice shelf. It almost looks like there is a heat source from that left boundary.

Further comments & prospective solutions

• We have confirmed that the issue really comes from the boundary conditions. Reasons to believe are that:
  a) we observe a similar issue if we take away the flux terms and replace them with constant Dirichlet conditions, say with T = 0.39 and S = 34.9;
  b) we have tried applying the flux conditions only on the upper half of the ice shelf, and we have seen no overshot in the bottom-left (although the shock-like behavior seen in the previous animations was still there, for the upper part).

• For a simplified setup, where temperature and salinity were initialized as constant, instead of stratified as in this case, we tried making the initial conditions for T and S smoothly reach the boundary value, so that the boundary conditions would not create a discontinuous situation. This seemed to help a bit, but it’s hard to be sure also given the difference in setups – it’s something we should double check and retry.
• We thought it could be due to an abrupt change in boundary conditions from no-flux on the left boundary, and some-flux on the ice shelf. However, making the flux terms smoothly go to zero towards the end of the boundary did not seem to help.
• All throughout, we have used 2nd degree elements for velocity and 1st degree for pressure, temperature and salinity. Bumping everything up 1 degree (P3P2P2P2) did not seem to help, nor has the combination P3P2P1P1 performed better (this last setup seems to be able to solve some geometry-related instabilities, making the pressure and T/S elements compatible with each other).

At this point we turned towards Discontinuous Galerkin, in the hope that it would prevent that inaccuracy from building up in the first place. Given the insulated nature of the left and bottom boundaries, it seems like once a pocket of warmer water has been created, it will have a hard time being flushed, so a good approach seems to lie in avoiding this warmer water from showing up at all. Given the work involved in implementing DG, we gladly avoid pursuing this track if it doesn’t seem probable that it could be of help, of course. FEniCS, the framework we use, has some built-in stuff on DG, but our ignorance on the matter (and the poor documentation) makes it hard to evaluate how much there is and how much needs to be done, as well as the prospective benefits we could harvest from this change (also performance-wise).

The post A temperature instability in our FEM model appeared first on Quick Math Intuitions.