dtamayo / reboundx

A library for adding additional forces to the REBOUND N-body integration package
GNU General Public License v3.0
80 stars 60 forks source link

Extras not attatching to sim for Rebound 4.3.2 #122

Closed Rmelikyan closed 5 months ago

Rmelikyan commented 5 months ago

I just update rebound from 4.0.3 to 4.3.2 and now I get an error "Need to attach reboundx.Extras instance to simulation before setting params." raised by params.py. With some digging I found that sim.extras remained NoneType even after rebx = reboundx.Extras(sim) for rebound v4.3.2

Switching back to 4.0.3 everything is working fine again. I'm not exactly sure where along the version history that the bug was introduced.

I'll be able to continue working in v4.0.3 for now but just wanted to bring this to your attention.

Cheers, -Robert M

hannorein commented 5 months ago

Did you recompile REBOUNDx after upgrading REBOUND? You can find out with:

import rebound
import reboundx
print(rebound.__build__)
print(reboundx.__build__)
dtamayo commented 5 months ago

thanks @Rmelikyan . Like @hannorein said, this sounds more likely a version compatibility issue, otherwise none of the unit tests would work. Please feel free to reopen if you think it's something else

Rmelikyan commented 5 months ago

Of course the tests would catch this... must be a me problem. Here's what I get for with the versions of rebound and reboundx that are working together

print(f"Rebound Version: {rebound.__version__} and build: {rebound.__build__}")
print(f"ReboundX Version: {reboundx.__version__} and build: {reboundx.__build__}")

Rebound Version: 4.0.3 and build: Jan 5 2024 16:13:23 ReboundX Version: 4.1.0 and build: Feb 3 2024 13:08:37

Then if I pip ugrade rebound:

pip install --upgrade rebound

The above code gives:

Rebound Version: 4.3.2 and build: Feb 19 2024 16:24:51 ReboundX Version: 4.1.0 and build: Feb 3 2024 13:08:37

I'll take it that having a rebound build that is younger than reboundx is a problem. Assuming that reboundx rebuilds when it is installed, I've been trying to pip install and upgrade reboundx and have noticed that it is always drawing rebx from a cached source on my computer (I've used rebx across a number of projects on separate virtual enironments).

Is it necessary for me to get rebx from source and rebuild locally or is there a way to get an updated build with pip commands?

Thanks to you both for your insight @hannorein @dtamayo !

hannorein commented 5 months ago

You're not the first in this python/pip dependency nightmare. I don't know the right commands out of my head to get out of this mess (maybe something like pip cache purge?).

I think we've convinced ourselves in the past that there is no "perfect" way to avoid this. I personally just built everything from source when I work with REBOUNDx.

Rmelikyan commented 5 months ago

Yes something like that worked for me!

Following the documentation here:

I executed pip cache remove rebound and pip cache remove reboundx then reinstalled the libraries.

Oddly rebound still reinstalled using a cache of 4.3.2 which I couldn't track down nor remove, but reboundx completely reinstalled and rebuilt (reboundx.build = Apr 2 2024 17:35:17)

Now it's all working! Hopefully this discussion helps others that get trapped in the pip dependency nightmare. It's nice to be able to simply pip install when you're working with a project across multiple machines though it's not too much trouble to install from source.

Cheers!

hannorein commented 5 months ago

Glad you found a way to make it work.

dtamayo commented 5 months ago

An alternative approach is to for each project (or at least when you run into problems) make a new conda environment (or virtual environment) and pip install reboundx. If that doesn't work then there's definitely an issue we need to fix. Thanks for opening issues to help us fix bugs and help other users!