Closed aryaakmal closed 1 year ago
Thanks Arya, this is great!!
We recently added support dynamically tracking spins in REBOUND/REBOUNDx. I'm not too familiar with the details here--is there a feedback torque on the spin at this same level of approximation? I can certainly imagine you don't care about this effect in many scenarios, but it might be useful to refactor the code in a way that at least makes it straightforward to add that capability later.
I can help with that, but not until after the semester ends. Do you need this now as a dependency for another project, or is this independent / can wait a couple weeks?
Hi Dan,
I certainly don't need this immediately, and there is no rush at all. Matt has a grant to implement an N-body ephemeris (I am not a part of it) but I was looking for low-hanging fruit from the park er al. DE440 paper, and this seemed like the most straightforward element, so I went ahead and coded it up. Feel free to incorporate it in reboundx if you feel be it may be useful. I need to think a bit more into the feedback torque question to give you a confident authoritative answer - I would guess it is the same level of approximation. But Matt may have more input in the meantime.
All the best,
Arya
On Wed, Apr 26, 2023, 8:05 AM Dan Tamayo @.***> wrote:
Thanks Arya, this is great!!
We recently added support dynamically tracking spins in REBOUND/REBOUNDx. I'm not too familiar with the details here--is there a feedback torque on the spin at this same level of approximation? I can certainly imagine you don't care about this effect in many scenarios, but it might be useful to refactor the code in a way that at least makes it straightforward to add that capability later.
I can help with that, but not until after the semester ends. Do you need this now as a dependency for another project, or is this independent / can wait a couple weeks?
— Reply to this email directly, view it on GitHub https://github.com/dtamayo/reboundx/pull/107#issuecomment-1523579205, or unsubscribe https://github.com/notifications/unsubscribe-auth/AOMJBQ6BY6DTMS5FDWBRPK3XDE2SRANCNFSM6AAAAAAXI2VSXM . You are receiving this because you authored the thread.Message ID: @.***>
Hi Dan-
Having thought about this for a few days, I think I've reached a tentative conclusion. Since this effect is closely analogous to a magnetic dipole interaction, I don't think there would be an associated torque in the case where the spins of the objects are aligned or (exacly) anti-aligned. I believe the torque would be present if the spins are mis-aligned, although this effect should be very small, unless the two objects are both very massive and/or spinning very rapidly.
So, for the "relatively" (;-) mundane physics the ephemeris and S.S. dynamics people are concerned with, this would not be important. However, the effect would be significant for less prosaic objects and systems. I need to delve more deeply into the GR to convince myself more fully, but I do believe that there would be more significant relativistic effects of lower order than this interaction. If you have any insights into this, please let me know.
I think it would be very cool to try to incorporate higher order general relativistic effects into reboundx, but this obviously needs to be approached systematically, not in the simplistic ad hoc way I have proceeded.
best Arya
On Wed, Apr 26, 2023 at 11:33 AM Arya Akmal @.***> wrote:
Hi Dan,
I certainly don't need this immediately, and there is no rush at all. Matt has a grant to implement an N-body ephemeris (I am not a part of it) but I was looking for low-hanging fruit from the park er al. DE440 paper, and this seemed like the most straightforward element, so I went ahead and coded it up. Feel free to incorporate it in reboundx if you feel be it may be useful. I need to think a bit more into the feedback torque question to give you a confident authoritative answer - I would guess it is the same level of approximation. But Matt may have more input in the meantime.
All the best,
Arya
On Wed, Apr 26, 2023, 8:05 AM Dan Tamayo @.***> wrote:
Thanks Arya, this is great!!
We recently added support dynamically tracking spins in REBOUND/REBOUNDx. I'm not too familiar with the details here--is there a feedback torque on the spin at this same level of approximation? I can certainly imagine you don't care about this effect in many scenarios, but it might be useful to refactor the code in a way that at least makes it straightforward to add that capability later.
I can help with that, but not until after the semester ends. Do you need this now as a dependency for another project, or is this independent / can wait a couple weeks?
— Reply to this email directly, view it on GitHub https://github.com/dtamayo/reboundx/pull/107#issuecomment-1523579205, or unsubscribe https://github.com/notifications/unsubscribe-auth/AOMJBQ6BY6DTMS5FDWBRPK3XDE2SRANCNFSM6AAAAAAXI2VSXM . You are receiving this because you authored the thread.Message ID: @.***>
Hi Arya,
Thanks again for this, and sorry this fell off my radar. I've sent you a pull request merging some recent changes in the rest of REBOUNDx. I've also made a couple changes to the effect.
I've hard-coded things so that particles[0] is always the central body. Do you know if the LT effect due to the Earth or other planets is ever important in ephemerides applications? We noticed that as REBOUNDx grows, one of the biggest bottlenecks is going through the list of registered params, so this should make things a bit faster, and as far as I'm aware, LT is never important in planetary applications beyond the solar system since we don't have sufficiently accurate observations. I agree that it would be nice to build up post-newtonian corrections systematically, but I think people have devoted their careers to doing that and would take some serious effort. I also think you're right about the back-reaction onto the spin of the Sun. It's obviously quite negligible even on long timescales, so I don't see an application where you'd ever want to pay the computational cost of integrating the spins alongside the orbits, so I like the way you've done it.
In a recent paper led by Tiger Lu, @hannorein and I added some functionality in REBOUND for manipulating vectors to work with spin vectors. To keep things consistent, I rewrote LT to use a spin vector Omega (Omega_x, Omega_y, Omega_z) rather than a magnitude and 3 unit vector components, and to use the total moment of inertia. I'm hoping to make the naming conventions consistent soon, but for now I just named them Omega and I to match the tides implementation.
I'm not sure whether this affects the ASSIST implementation or other code that you have, but in trying to match the correct L-T precession rate quoted in the Park paper, I caught a typo that the final acceleration needed to multiply the entire quantity by 2 (the 2 was just multiplying the first term).
I have also started using astropy for all my own unit conversions, so I added those to the notebook (while trying to match the correct precession rate). I can't decide whether or not to add astropy as a dependency and use it in all the examples, since I do think that's probably the most convenient way of doing things that I have found, and it comes up with every REBOUNDx effect. I could also hardcode in all the values in the examples, and add a single Units.ipynb where I give that as a suggestion. Would be curious what you and @hannorein think.
Once you take a look and are happy with things, I'm happy to merge!
The astropy units package seems great and the community seems to be using it a lot. But I wish it were a standalone package. I don't like how astropy is become the new IDL where nothing can be done without it. There seem plenty of alternatives out there which do only unit conversions. I've heard good thing about pint. I'd rather make pint (500k) a dependency than astropy (35MB).
Thank you for cleaning this up, Dan. To the best of my knowledge this effect is not significant other than for the sun. At least, I haven't seen any implementations beyond that, so I would guess that it is of such high order that noone has bothered to consider it. If and when you and Hanno are ok with it, please feel free to incorporate it as you see fit.
-A.
On Mon, Jun 19, 2023 at 3:24 PM Dan Tamayo @.***> wrote:
Hi Arya,
Thanks again for this, and sorry this fell off my radar. I've sent you a pull request merging some recent changes in the rest of REBOUNDx. I've also made a couple changes to the effect.
I've hard-coded things so that particles[0] is always the central body. Do you know if the LT effect due to the Earth or other planets is ever important in ephemerides applications? We noticed that as REBOUNDx grows, one of the biggest bottlenecks is going through the list of registered params, so this should make things a bit faster, and as far as I'm aware, LT is never important in planetary applications beyond the solar system since we don't have sufficiently accurate observations. I agree that it would be nice to build up post-newtonian corrections systematically, but I think people have devoted their careers to doing that and would take some serious effort. I also think you're right about the back-reaction onto the spin of the Sun. It's obviously quite negligible even on long timescales, so I don't see an application where you'd ever want to pay the computational cost of integrating the spins alongside the orbits, so I like the way you've done it.
In a recent paper led by Tiger Lu, @hannorein https://github.com/hannorein and I added some functionality in REBOUND for manipulating vectors to work with spin vectors. To keep things consistent, I rewrote LT to use a spin vector Omega (Omega_x, Omega_y, Omega_z) rather than a magnitude and 3 unit vector components, and to use the total moment of inertia. I'm hoping to make the naming conventions consistent soon, but for now I just named them Omega and I to match the tides implementation.
I'm not sure whether this affects the ASSIST implementation or other code that you have, but in trying to match the correct L-T precession rate quoted in the Park paper, I caught a typo that the final acceleration needed to multiply the entire quantity by 2 (the 2 was just multiplying the first term).
I have also started using astropy for all my own unit conversions, so I added those to the notebook (while trying to match the correct precession rate). I can't decide whether or not to add astropy as a dependency and use it in all the examples, since I do think that's probably the most convenient way of doing things that I have found, and it comes up with every REBOUNDx effect. I could also hardcode in all the values in the examples, and add a single Units.ipynb where I give that as a suggestion. Would be curious what you and @hannorein https://github.com/hannorein think.
Once you take a look and are happy with things, I'm happy to merge!
— Reply to this email directly, view it on GitHub https://github.com/dtamayo/reboundx/pull/107#issuecomment-1597655021, or unsubscribe https://github.com/notifications/unsubscribe-auth/AOMJBQ6LORZ6ZEXBATF3IWLXMCRPJANCNFSM6AAAAAAXI2VSXM . You are receiving this because you authored the thread.Message ID: @.***>
Great, thanks @aryaakmal! @hannorein, that's a good point. How about adding neither of them as dependencies, hard-coding all the values in the examples, and adding a Units.ipynb example that isn't tracked by the github workflow that gives a couple examples using both astropy and pint? I think as a new student trying to get up and running quickly I would find that quite helpful.
Also I guess we need to remove python 2.7 from the tests!
That sounds good. We could still include it in a separate workflow. On Jun 19, 2023, at 7:09 PM, Dan Tamayo @.***> wrote: Great, thanks @aryaakmal! @hannorein, that's a good point. How about adding neither of them as dependencies, hard-coding all the values in the examples, and adding a Units.ipynb example that isn't tracked by the github workflow that gives a couple examples using both astropy and pint? I think as a new student trying to get up and running quickly I would find that quite helpful.
—Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you were mentioned.Message ID: @.***>
An implementation of the relativistic Lense-Thirring effect due to a massive rotating body.