## 6996 Reputation

16 years, 214 days

## Remove with(Physics)...

@Ahmed111 As Carl has pointed out, the trouble in Maple 18 may be due to "with(Physics)".  But that package is not needed in Linearize.mw.   Remove and try it again.

## Linearize...

@Carl Love I misunderstood the question.  Then perhaps this is what is wanted:  >  In replace by the symbol , etc., linearize with respect to those symbols,

and then restore the symbols to their original meanings:

 >   ## Geodesics and shortest paths...

@Earl The opening paragraph of the Wikipedia page that you referred to in your original message, begins with:

In geometry, a geodesic is commonly a curve representing
in some sense the shortest path between two points in a surface.

Note the qualifier "in some sense" there; it is not making an absolute statement that a geodesic is the shortest path!

Technically, a geodesic curve on a surface is defined to be the generalization, in a very precise technical sense, of a straight line in the plane. For instance, a great circle on a sphere is a geodesic; it's the closest thing to a straight line that lies on a sphere. There is no appeal here to "two points" or "shortest distance".

The shortest length property of a geodesic is a consequence (i.e., it is proved as a theorem) of the "straight line" definition alluded to above. It holds under certain circumstances but it is not always valid without qualifications.

Have a look at the picture of the green cone in my previous message. The shortest path between the two orange points is the obvious little arc (not drawn) that connects those points. However, look at the red curve which also connects those two points. Imagine this as a real physical cone and the red curve as a (loose) rope that winds around the cone as shown, and goes through those two points. What would happen if you pulled that rope real tight? You will be minimizing the rope's length! The rope will take the shape as drawn. So yes, that shape is also a "shortest distance" between those two points. It is the shortest among all curves that wind around the cone once. It is shortest because if you try to pull any harder, the rope will break; you cannot make it any shorter.

This should clarify my statement that there may be multiple geodesics between two curves on a surface.  In that connection, have a look at the red and cyan geodesics on the animated torus in my earlier reply.

## Geodesic on a cone...

@Earl Okay, here it is: A geodesic on a cone ## A different approach...

@Earl Yes, there is an idea there which I had not thought about, and which can be useful in some situatios.   Specifically, if the surface is parametrized such that geodesics are single-valued functions of one of the surface's parameters, then we may characterize those geodesics as solutions of boundary values problems of a 2nd order ODE obtained through the Euler-Lagrange equations. This works particularly well with toruses as in the illustrated answer which I am going to post next.  It should work in the case of some other interesting surfaces but I haven't tried.

## References...

@Earl I don't see an easy way to modify the code to do what you have asked.

There is some literature on the subject.  Perhaps a good way is to Google for "how to calculate the geodesic going through two given points".  I just did that and obtained two promising articles.

1. This one appears to have been written by undergraduates.  Their methods seem to work but are computationally inefficient.
2. This one appears to be more sophisticated. I haven't looked at the details but it seems to be worth a look.

I may give this question a try when I have some more time but not now.

## Colon missing...

@ecterrab That works!. Thanks!

PS: In the first of the two maplinit lines that you have provided, the "=" should be ":=".

## Thanks for the quick fix...

@ecterrab Thanks for the quick fix, as always!

## Nice enhancement...

Edgardo, that's a very nice enhancement.

Would it be possible to let users make the subscripted variables the default by setting some kind of environment variable in mapleinit?

## Enhanced pdsolve...

@vv Yes, pdsolve() does return the correct general solution.  Something goes wrong when it tries to apply the initial condition.

Here is a possible enhancement to Maple pdsolve().  In the same way that dsolve() offers an implicit option. it would be helpful if pdsolve() also offered that option.  Then the solution of the initial value problem ut + u ux = 0, u(x,0) = f(x) would be expressed as f(x − ut) = u which is more pleasant than the RootOf expressions to look at.

## Looks good...

@Earl That looks good.  Good job!

## Drawing the trace...

@Preben Alsholm I like that.  Very nice!

## More on the boundary flux...

@acer Thanks for getting to the bottom of this.  Now it's clear to me why D(U)(0,t) does not return a value .

So now we have two ways for calculating the boundary flux.  One way is through the boundary_flux() function which I described earlier.  Another way is to calculate −D(U,h,t) where h=Float(1,−Digits/2).  That actually calculates the flux at y=h, but since h is so small, the value calculated here is practically the same as the flux at the boundary.

As long as we are at it, let me point out that a more accurate version of the boundary_flux() function may be obtained by replacing the 1st order finite difference by a 2nd order finite difference, as in:

```h := Float(1,-Digits/2);
boundary_flux := t -> - ( -3/2*U(0, t) + 2*U(h,t) - 1/2*U(2*h,t) ) / h;```

This would be my preferred method of calculating the boundary flux if I had a need for it in my work.

## Calculating the boundary flux...

@Moqifang I don't know what prevents the evaluation of the y derivative at the boundary.  It's not a version issue, since it doesn't work on my Maple 2022 either.  Nevertheless, there is an easy workaround as we see in the following fragment corresponding to your screenshot:

 > vals := sol1:-value(u(y,t), output=listprocedure); This proc captures the value of the solution :

 > U := eval(u(y,t), vals); Here is the solution evaluated at :

 > U(0,0.1); Here is the flux, , evaluated at :

 > -D(U)(1,0.5); That evaluation fails at the boundary, I don't know why:

 > -D(U)(0,0.5); But we can work around that.  We approximate the derivative at through
the finite difference for a small value of .  Experiemnts

show that provides a good enough accuracy.  Reducing to make no noticeable change.

 > eps := 1e-3; > boundary_flux := t -> -(U(eps,t) - U(0,t))/eps; > plot(boundary_flux(t), t=0..Pi); Note: The boundary flux goes to infinity as .  That's due to the discontinuity

which has been discussed earlier.

## Observation...

@wmcnally I see that in the case of the pendulum equations you have

`sys := A:-Linearize(format=all)`

while in the case of the RLC circuit you also specify params and paramcheck.  Perhaps that's the reason for the pendulum case not working?  That's just an observation; I know nothing about Maplesim.

If you don't receive further suggestions to your question here, you may want to ask for help by emailing <support@maplesoft.com>.

﻿