Christoffel symbols and symbolic variables

[Ninetrees]

Quite some time ago, I did some work with symbolics that led mt to try to create Christoffel symbols in Mathcad. (I can do it in Mathematica, though I am not very good with it, and I can do it in MATLAB, using MATLAB symbolics, but it is not very clean, and certainly not very readable.) I gave it several shots in M15, and have attached the results.

The pieces seem to work, but not the aggregate...should I just do it in Mathematica instead of beating myself up here? Part of the problem here seems to be that symbolics are not handled as well as in Mathematica and MATLAB, at least as far as initial declarations go. I tried simply not declaring t,r,theta,phi, and living with the undeclared complaint, but no joy there either.

~R~

[AndyWesterman]

Hi,

Not sure, exactly, what the output should be.

Attached are a few ideas to try.

Can you show examples of the results that you get from Matlab?

Regards

Andy

[Ninetrees]

Following your example, I eventually got to the correct solution. I forgot that M15 would not do more than 2D matrices. It let's one /specify/ 3 indices, and looks like it's running OK, but the results are bogus. I had hoped to avoid all this work, but the items that made it more work are the shortcomings of M15 handling symbolics, and the restriction on matrix indicies.

The result is that I must read each page of the result, and "decode" it into the correct multipliers that I need.

Thanks to all who responded...I do appreciate the time and effort.

~R~

[Ninetrees]

Andy,

Sorry for the delay in posting...got distracted...here is the MATLAB code that parallels the Mathcad code. It is all symbolic; no attempt is made to use it to generate real coefficients. I posted it on the MATLAB code exchange, too.

~R~

[AlanStevens]

And here's my attempt.

Alan

[Werner_E]

And here is mine.

Compared to the others is look quite too tricky, though.

I was a bit confused about the definition of the Christoffel symbol in your sheet - would have rather used the definition Andy had chosen (w/o using gi) as it seems you are looking for the Christoffel symbols of first kind.

But even if I would replace the sum(gi) for 1/2 as Andy did, I would not get matrices consisting of all zeros!?

EDIT: Replace attachment by a (very slightly) more efficient routine

[Ninetrees]

I think that your results are the same as mine, but I have not compared the trig results.There are some good techniques in the file, if I can understand them 😉

~R~

[Ninetrees]

I reviewd your doc, and thought afer a bit that I understood it. It seemed that the func make_gamma (and others) does not need the dimension (t,r,...) names passed on the parm list. I deleted them, and the result was the same.

Then I thought that I'd try your method of substituting. I see now why it works, I think, and it is a good tool. I seem to recall using it years ago, but could not remember how or why.

But it doesn't work full for me. It seems to do the first substitution correctly, but will not take the derivative.

Please see attached...

~R~

[Werner_E · Accepted solution]

It seemed that the func make_gamma (and others) does not need the dimension (t,r,...) names passed on the parm list. I deleted them, and the result was the same.

Yes, thats true. Personally I like to create generic functions and use them to calculate variable values rather than assigning programs directlyto variables as you do in your sheet. A matter of personal taste I guess and no harm, if the evaluation is needed only once in the sheet. Using a function you could evalaute easily for different matrices in the same sheet which obviously is not needed in your case. That was also the reason I made the four dimension names customizeable at the price of a more clumsy argument list. If you are sure you never will change them from t,r,theta and phi to anything else its sure OK to delete them in the argument list. My idea when writing a generic utility function is that everything the routine is using should be either a local variable or be passed as argument to the routine. The routine should not rely on anything outside, not on that a variable with a specific name exists on the worksheet level nor that functions used (in g for example) are using specific argument names (t,r,theta and phi in this case).

I noticed that in the worksheet I posted not all symbolical evals in the program are necessary - only the two using the substitute are.

Then I thought that I'd try your method of substituting. I see now why it works, I think, and it is a

Its tricky and I don't know if it would work in Prime - I fear, no, but I haven't tried so far. I think I used this way of substitution (is necessary because the variable you differentiate wrt can't be a true variable but must be "hardcoded") was when I wrote a routine to solve simple linear ODEs of first order symbolically automatically..

But it doesn't work full for me. It seems to do the first substitution correctly,

No, it doesn't. It looks correct on first sight, but you are assigning g[i,j to g.ij and then you symbolically evaluate that assignment. That way g.ij is assigned the expression without any substitution. Whats needed is to evaluate and substitute g[i,j symbolically first and only thereafter assign the result to g.ij. The same error in the next line, you must first substitute and then assign.

See the attached sheet for a corrected and an even shorter version.

Afterthought: Instead of the simple z as variable to differentiate wrt its adviseable to take something more complicated, preferrably constructed using special character inserted via CTRL-K to be on the safe side. The program would fail if a variable of name z is assigned a value in the worksheet before the definition of the routine. And we can't do a z:=z inside a program. z <-- z would simply assign the value of the worksheet variable z (RHS) to a local variable z.

[Ninetrees]

Generic functions: yes, a very good point. I am inclined this way, too, but I was so caught up in the details that I didn't get that far. In truth, the routine needs to be flexible.

>>The routine should not rely that a variable with a specific name exists outside on the worksheet level.

Also a good point. This sheet evolved from points not shown, but I appreciate the reminder...

>>Its tricky and I don't know if it would work in Prime

I don't use Prime much...it's pretty slow, and Help is also awkward. I do try to keep my hand in with it though, and I'll try this in Prime as well once I am happy with it. It needs, too, a bit of a writeup.

>>It looks correct on first sight, but you are assigning g[i,j to g.ij and then you symbolically evaluate that assignment

Whoa! Nice catch. I /did/ see that effect, but didn't understand the implications. I am working in M15, BTW. I built the expression outside of the routine because I couldn't seem to get it to edit properly inside the routine. That is, I could not get the substitute to add to the expression. But I didn't create the whole expressin that way, just the RHS. I tried this several times after your post...

Ahh, this last time worked. I typed g[i,j, clicked Substitute from the Symbolic toolbar, entered x[xn and z, and ///left the expression///. That was the only thing that I did differently. Then when I pasted it, it worked correctly! I suppose (??) that this is because it actually did the symbolic evaluation before the copy|paste?

Great help! I'll keep a copy of this with all the comments and flaws for future reference. I'll post a cleaned up and annotated version for the list. I'll try it in Prime, and post the results.

~R~

[Werner_E]

I suppose (??) that this is because it actually did the symbolic evaluation before the copy|paste?

Not sure, but I don't think so. As long as you copy it including the evaluation arrow (which you sure had done) it should work OK. I think its the way how we insert th ecopied expression in the program. If you type dx <--- first and copy to te placeholder to the right there should be no problem. But if you copy in a new line of the program first and then add the local assignment, it depends on which expression is highlighted (blue underline cursor) when you type the local assignment. If only the part to the left oft "substitute" is underlined (and this happens if you click at the front of the line) you will end up with the wrong version.

BTW, I usually don't use Prime, too for various reasons (performance, visability, useability, missing features, ..) but regardless of what users demand, Prime and the direction Prime is heading seems to be the future of Mathcad. So my comment was just to remark that it might not be the best idea when we create a new worksheet not to use features and tricks not available in Prime - especially when there are compatible alternatives.

[Ninetrees]

>>the best idea when we create a new worksheet not to use features and tricks not available in Prime - especially when there are compatible alternatives.

Completely agree. That is why I intend to port the final version of this to Prime, and see what happens. I'll post it here, and we'll see how it is discussed. I am simply not as familiar with Prime.

Also: We discussed the speed of the various routines. Experience with other programming languages suggests that, in general, the more abstract the program, the slower it runs to completion. I wanted a generic solution (recall the discussion about passing the dimension labels in the formal parm list (FPL)), and that meant replacing the hard-coded dim labels in Dx() with either Dx2() or Dx3(). The price for flexibility is 50% increase in execution time. Fortunately, anyone looking for a generic Christoffel symbol program will not be unhappy with the difference twixt 1.5 s and 2.5 s (approx) to generate a set of them. Anyone looking to embed Christoffel symbol in a much larger program where much attention is given to calculating different geometries will likely choose the faster method. I intend to discuss both in detail in my final doc, because I intend it as a reference, and you know how I will forget a year from now that we had this discussion. 😉 I am so very grateful for having it, but (sigh), so busy putting so many things into my brains. Yep, I said brains. Someone once told me that I am smart enough to have two brains: one the size of a BB, and the other just a little bitty thing. 😉

~R~

[Werner_E]

In the last version Dx2 and Dx3 also hard coded dimension labels, but could easily changed to accomodate for those additional arguments (which Dx can't without introducing symbolic substitution). I suspected in the file I posted that Dx2/3 are slower than Dx and this seems to be confirmed by you. I guess its because of the two symbolic evalautions used in those routines biút am not sure why they should take up that much time.

If it takes you a full year to forget about a thread - congratulations! Your memory seems to be way ahead of mine, maybe thats the drawback of just being single brained. 🙂

PS: I just was curious and converted the sheet I posted last (v.0108) in Prime3 format. Not sure why but the converter refused to convert the definition of the matrix g! After retyping it it shows that was right. While Dx seems to work, the tricky verisions Dx2 and Dx3 don't Welcome to the new era of Mathcad

Not only the definitions of Dx2 and Dx3 but also every expression/routine using Dx2 or Dx3 is not converted at all but inserted as a picture and has to be retyped completely. Dx2 and Dx3 cannot be recreated in Prime using those symbolic evals in a program - CTRL-V simply won't insert anything.

[Ninetrees]

Well, here is my result. Because this is just an aid (Christoffel symbols and geodesics being well-understood in their own realm), I think that it is the end for now.

The MATLAB equivalent is pretty sloppy at this point. I may clean it up and post it for others, but its output is not pretty at all...clear enough to one reading MATLAB output, but not even close to Mathcad.

Mathematica handled the project with way fewer lines of code, primarily because it manages range vars better than Mathcad...as do MATLAB and Maple. I think that Mathematica is great for stuff like this, but then the interface and output are both clunky, despite the impressions given by the canned ads for the product...ditto Maple. And both still are dismal at handling units. I'd jump on either in a heartbeat if they measured up, but I can't see learning one of them just for some of the features.

I too imported the M15 version into Prime, and almost nothing of the real stuff converted. Dunno if I have the patience to type it all in just to see what happens. So I'm posting my latest here...I think that it meets my requirements of explaining Christoffel symbols and geodesics using Mathcad, in case anyone wants to see how they relate to one another or wants to play with the symbols. Much of the end of the doc is hand entered because Mathcad doesn't have the symbolic handling capability to do the fancy stuff with the geodesics...or maybe I just don't know enough. At any rate, it should be clear how the symbols are generated and how they are combined into the geodesics, and that was my intent. I'll prolly post a pdf on my website, too. so that the web can index it.

~R~

[Ninetrees]

As I thught about the purpose of the document, which is simply a way to use Mathcad to calculate Christoffel symbols and the geodesic equation, I decided to rewrite it to better agree with the equation that I put at the beginning. I also came to the conclusion that the symbolic method was not the right tool for 2 reasons: it is much slower, and it contantly rewrites the page. In fact, that very rewriting is responsible for performance hits, as screen rendering is a known performance hit.

The program is much cleaner now, and runs much faster. I think the less cluttered logic, though not so generic, is easier to follow and map to the 2nd equation, which is the one that I use to calculate the symbols. And that, as an educational tool, is the goal. I left in the symbolic stuff so that others may use it if they wish.

I also noted that the image that is at the top right of page 1 changes color after I run the symbolic version!

~R~

Edit 2014-03-06: Replace file.

Edit 2014-03-16: Replace file. Corrected errors in text. Rewrote Dx to be more intuitive (I thought) with respect to the equation it models. Expanded explanations for the Mathcad novice. Provided text reference for general relativity used as a basis for the document.

~R~