Problems with lorentz transform (symbolic module)

ritzvik commented 4 years ago

🐞 Problem There is a lot to be desired regarding lorentz_transform function in the classes of symbolic module. This issue consolidates a number of problems into a single issue.

🎯 Goal

[ ] Devise a testing strategy for lorentz_transform across all the classes and implement them.
[ ] lorentz_transform implemented in ChristoffelSymbols is probably incorrect, Christoffel Symbols being a pseudo-tensor. Research about this, and change the implementation along with suitable tests.
[ ] Currently, "parent metric" is not preserved while during lorentz transformation. Do something about this. (This issue duplicates #355 )

💡 Possible solutions

This issue needs extensive research. Comment on the problem being addressed and discuss in the comments before opening a PR.

📋 Steps to solve the problem

Comment below about what you've started working on.
Add, commit, push your changes
Submit a pull request and add this in comments - Addresses #<put issue number here>
Ask for a review in comments section of pull request
Celebrate your contribution to this project 🎉

ritzvik commented 4 years ago

@spino17 Can you help in any way ?

ritzvik commented 4 years ago

That’s a collection of issues, each requiring deep theoretical knowledge. I wouldn’t recommend that you take these up. Good first issues, maybe??

Regards, Ritwik

On 02-Feb-2020, at 3:06 PM, sagnik-chatterjee notifications@github.com wrote:

Can i take up this issue ?

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub, or unsubscribe.

gimseng commented 4 years ago

Hi, I know how "lorentz transformation" of Christoffel symbols should work, since they are not actual tensors. However, I am new to this project, so would be happy if someone wants to work together on it, I can provide some references and formula for that.

ritzvik commented 4 years ago

Hi, I know how "lorentz transformation" of Christoffel symbols should work, since they are not actual tensors. However, I am new to this project, so would be happy if someone wants to work together on it, I can provide some references and formula for that.

I would love to collaborate, let's get things done with #427 first. BTW, it would be great help!

ritzvik commented 4 years ago

@gimseng However, I am thinking of deprecating lorentz transform and implementing change of basis vectors, lorentz transform being a special case of the latter.

What do you say?

gimseng commented 4 years ago

Sure, I think doing a general coordinate transformation (or you call it basis change) is more relevant and useful for a GR package. I could start working on this. However, I wanted to do it probably with git and stuff so maybe it will be a little slower, and I will ask lots of questions to make sure I don't screw with master and I want to do rebase and squashing properly. If its ok with you all, I will go dig around to figure out how and what should be done.

On another note, I think for Lorentz transformation, the Christoffel will transform like appropriate Lorentz tensors, since the "extra terms" vanish for Lorentz-transfomation. So they are Lorentz tensors but not general-covariant tensors. If need be, and if some points me towards the right place, I could write a few lines to explain this in a doc or issue ticket or something.

Finally, what is this issue with "parent metric"? Is this a class inheritance thing or some GR thing?

ritzvik commented 4 years ago

Okay then! Have a look at the symbolic module. There are many examples on their usage. Let’s start with general coordinate transform then. With this we won’t have the luxury of ignoring extra terms for pseudo-tensors. Also we need to devise a strategy on how to implement them!

Regards, Ritwik

On 12-Feb-2020, at 1:21 PM, Gim Seng notifications@github.com wrote:

Sure, I think doing a general coordinate transformation (or you call it basis change) is more relevant and useful for a GR package. I could start working on this. However, I wanted to do it probably with git and stuff so maybe it will be a little slower, and I will ask lots of questions to make sure I don't screw with master and I want to do rebase and squashing properly. If its ok with you all, I will go dig around to figure out how and what should be done.

On another note, I think for Lorentz transformation, the Christoffel will transform like appropriate Lorentz tensors, since the "extra terms" vanish for Lorentz-transfomation. So they are Lorentz tensors but not general-covariant tensors. If need be, and if some points me towards the right place, I could write a few lines to explain this in a doc or issue ticket or something.

Finally, what is this issue with "parent metric"? Is this a class inheritance thing or some GR thing?

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub, or unsubscribe.

ritzvik commented 4 years ago

See from_metric classmethod in ChristoffelSymbols, you would understand what parent_metric is about. It actually preserves the metric from which other quantities are derived.

gimseng commented 4 years ago

I see, if I understood correctly, the structure of implementations are such that you do something.from_somethingelse(...) to actually calculation, say Christoffel / Riemann / Ricci from the appropriate object (say metric/Christoffel/Riemann).

So the Christoffel method has a from_metric method, which computes the Christoffel symbol, and return as a tensor class.

If I understood the issue correctly, now under Lorentz/general coordinate transformations, do we want to keep track of which metric a Christoffel symbol was constructed from? If we did, when we applied a transformation/basis change to the Christoffel symbol, returning the Christoffel symbol in a new coordinate/basis, the question/issue is then: do we transform the original metric (in original coordinates/basis) to the metric in new coordinate and assigning this to be the parent metric of the Christoffel symbol in new coordinate?

ritzvik commented 4 years ago

@gimseng Yes, you understood this right. Along with transformation of the derived quantity, we also need to transform the metric from which it is derived, and set the new metric as parent_metric.

But we would need to decide on whether to drop lorentz altogether in favor of general transformation. I say yes! If it is yes from your side also, we can first work on general transformation, and later drop lorentz, saving us the efforts here!

ritzvik commented 4 years ago

And this parent_metric thing would also apply in general transformations. There's no running from this problem :(

ritzvik commented 4 years ago

Also, here is a link detailing mathematics behind transformation of christoffels

gimseng commented 4 years ago

hi I am a little busy these two weeks, maybe I will check in again after I finished my busy weeks?

ritzvik commented 4 years ago

Sure ! Open source is people coming together to contribute at their own convenience.

Regards, Ritwik

On 14-Feb-2020, at 2:24 PM, Gim Seng notifications@github.com wrote:

hi I am a little busy these two weeks, maybe I will check in again after I finished my busy weeks?

— You are receiving this because you modified the open/close state. Reply to this email directly, view it on GitHub, or unsubscribe.

JeS24 commented 1 year ago

I think, it is better to have mathematical operations as mixins that suitable objects can then derive from. Perhaps one can look into this.

Also ref: https://github.com/einsteinpy/einsteinpy/issues/497#issuecomment-1295053256.

einsteinpy / einsteinpy

Problems with lorentz transform (symbolic module) #374