JeS24 on main
Updated README.rst to fix build… (compare)
pip install einsteinpy
. This would install einsteinpy-0.3.1 (AKA "stable"). What you want is einsteinpy-0.4.dev0 (AKA "latest"), that you can install via pip install git+https://github.com/einsteinpy/einsteinpy.git
. This pulls the most recent code from our GitHub repo. The documentation for this version can be found at https://docs.einsteinpy.org/en/latest .
pip uninstall einsteinpy
before you install the latest version.
tandersen@tomm1 bin % ./conda init zsh
no change /opt/homebrew/Caskroom/miniforge/base/condabin/conda
no change /opt/homebrew/Caskroom/miniforge/base/bin/conda
no change /opt/homebrew/Caskroom/miniforge/base/bin/conda-env
no change /opt/homebrew/Caskroom/miniforge/base/bin/activate
no change /opt/homebrew/Caskroom/miniforge/base/bin/deactivate
no change /opt/homebrew/Caskroom/miniforge/base/etc/profile.d/conda.sh
no change /opt/homebrew/Caskroom/miniforge/base/etc/fish/conf.d/conda.fish
no change /opt/homebrew/Caskroom/miniforge/base/shell/condabin/Conda.psm1
no change /opt/homebrew/Caskroom/miniforge/base/shell/condabin/conda-hook.ps1
no change /opt/homebrew/Caskroom/miniforge/base/lib/python3.9/site-packages/xontrib/conda.xsh
no change /opt/homebrew/Caskroom/miniforge/base/etc/profile.d/conda.csh
modified /Users/tandersen/.zshrc
==> For changes to take effect, close and re-open your current shell. <==
tandersen@tomm1 bin % pwd
/opt/homebrew/Caskroom/miniforge/base/bin
Hi! Sorry for bothering for the very first day, but I noticed that the pip installing is complaining that
einsteinpy requires Python '>=3.7' but the running Python is 2.7.17
while I just installed python 3.8, and also the alias "python" points to that one, so why does it search for the oldest python? How can I force it to choose the 3.8 version I installed?
Processing /project/6004969/mlai92/einsteinpy
Installing collected packages: UNKNOWN
Running setup.py install for UNKNOWN ... error
Complete output from command /usr/bin/python2 -u -c "import setuptools, tokenize;file='/tmp/pip-Ycu7Ai-build/setup.py';exec(compile(getattr(tokenize, 'open', open)(file).read().replace('\r\n', '\n'), file, 'exec'))" install --record /tmp/pip-oH81vU-record/install-record.txt --single-version-externally-managed --compile:
/usr/lib64/python2.7/distutils/dist.py:267: UserWarning: Unknown distribution option: 'setup_cfg'
warnings.warn(msg)
running install
running build
running install_egg_info
running egg_info
creating UNKNOWN.egg-info
writing UNKNOWN.egg-info/PKG-INFO
writing top-level names to UNKNOWN.egg-info/top_level.txt
writing dependency_links to UNKNOWN.egg-info/dependency_links.txt
writing manifest file 'UNKNOWN.egg-info/SOURCES.txt'
warning: manifest_maker: standard file '-c' not found
reading manifest file 'UNKNOWN.egg-info/SOURCES.txt'
reading manifest template 'MANIFEST.in'
warning: no files found matching '*.py' under directory 'src/einsteinpy/tests'
warning: no files found matching '*.html' under directory 'src/einsteinpy/tests'
no previously-included directories found matching 'docs/source/examples/.ipynb_checkpoints'
warning: no previously-included files matching '*.py[cod]' found anywhere in distribution
warning: no previously-included files matching '__pycache__' found anywhere in distribution
warning: no previously-included files matching '*.so' found anywhere in distribution
warning: no previously-included files matching '*.dylib' found anywhere in distribution
writing manifest file 'UNKNOWN.egg-info/SOURCES.txt'
Copying UNKNOWN.egg-info to /usr/lib/python2.7/site-packages/UNKNOWN-0.0.0-py2.7.egg-info
error: /usr/lib/python2.7/site-packages/UNKNOWN-0.0.0-py2.7.egg-info: Permission denied
----------------------------------------
Command "/usr/bin/python2 -u -c "import setuptools, tokenize;file='/tmp/pip-Ycu7Ai-build/setup.py';exec(compile(getattr(tokenize, 'open', open)(file).read().replace('\r\n', '\n'), file, 'exec'))" install --record /tmp/pip-oH81vU-record/install-record.txt --single-version-externally-managed --compile" failed with error code 1 in /tmp/pip-Ycu7Ai-build/
I believe, it is better to use the term "array" instead of "matrix" (rank-2 tensor).
RbcdaR^{a}_{bcd}Rbcda
Could you clarify this term? This does not look right (wrt indices repeating more than twice & their ordering).
a being the row of the outer matrix, b being columns, and then c&d being the respective indices for the inner matrices.
Right. This is how it should work in EinsteinPy, as long as the index labels are ordered first-to-last for a Riemann (or a general rank-4) tensor denoted as R_{abcd}
. Two things to note here:
R
(here) should not be understood to be covariant. abcd
could just as well denote upper / lower indices - this does not affect array-indexing.a, b, c, d
are just labels, that might change their ordering based on tensor operations (such as transpose), when mathematically represented in the Einstein notation. But these operations do not change the order in which the array elements are accessed / indexed, which remains first-to-last. The elements within the array are obviously altered.
For example, if you have a rank-4 tensor, T_{abcd}
, here a
& b
would denote the rows & columns of the outer array respectively, and c
& d
would denote the rows & columns for the inner arrays. However, if you transpose the last two indices to get T_{abdc}
in Einstein notation, this would swap elements along those axes, but the array-indexing order remains the same afterwards, which in turn means, c
no longer denotes the rows of the inner arrays & d
no longer denotes the columns of the inner arrays. Their roles are now reversed with c
denoting the columns and d
denoting the rows. Meanings of a
& b
of course do not change in this case.
What I'm noticing is a & d are the indices for the outer matrix, and then cb the row/column for the inner matrix. Is this correct?
If the order of indices in your array-indexing is a, b, c, d
, then this doesn't seem right. Could you please share the metric you used to generate the Riemann tensor and also how you are accessing the elements of the Riemann tensor in code? As stated above, tensor operations (transposition, contractions etc) change the meaning of the indices, but not the order in which the array elements are accessed / indexed. The symmetries of the Riemann tensor might also be playing in role in your confusion.
I am new to einsteinpy and have been reading a lot of documentation but there seems to be a lot of outdated stuff. I wanted to ask how to make use of the body module to get geodesics equivalent to the old geodesic = Geodesic(body = Particle,...
. For example, I have the following system :
cord = CartesianDifferential(t=0*u.s,x=20*u.km,y=100*u.km,z=0*u.km,v_x=10*u.km/u.s,v_y=0*u.km/u.s,v_z=0*u.km/u.s)
b1 = Body(name='Attractor',mass = 1e10*u.kg,R = 1e06*u.km)
part = Body(name='Particle',mass=16e-28*u.kg,R = 8e-18*u.km,parent=b1,differential=cord)
How do I calculate the geodesic here? And what if I have more bodies?
How do I calculate the geodesic here?
This API is from v0.3.1 and lower. Ensure that you are using 0.3.1 (pip install einsteinpy==0.3.1
should work), and try this code:
import astropy.units as u
from einsteinpy.coordinates import CartesianDifferential
from einsteinpy.geodesic import Geodesic
from einsteinpy.bodies import Body
from einsteinpy.plotting import GeodesicPlotter, StaticGeodesicPlotter
from einsteinpy.metric import Schwarzschild
# In EPy v0.3.1 and lower, CartesianDifferential does not take a `t` argument.
cord = CartesianDifferential(x=20*u.km,y=100*u.km,z=0*u.km,v_x=10*u.km/u.s,v_y=0*u.km/u.s,v_z=0*u.km/u.s)
b1 = Body(name='Attractor', mass=1e10*u.kg, R = 1e06*u.km)
part = Body(name='Particle', mass=16e-28*u.kg, R = 8e-18*u.km, parent=b1, differential=cord)
# Given the large distance between the test particle and the black hole, you will need a large step size to get results
# in a reasonable amount of time. Note that this means that the results will be less accurate, especially near the black hole.
geod = Geodesic(body=part, end_lambda=3000, step_size=5, metric=Schwarzschild) # metric=Schwarzschild by default
plotter = StaticGeodesicPlotter()
plotter.plot(geod)
plotter.show()
And what if I have more bodies?
If you want to have more test particles (vis-à-vis Particle
in your code), the only thing you need to ensure is that particle masses << the mass of the black hole (Attractor
in your code). So, the code should look something like this:
# imports and definitions as above
cord1 = CartesianDifferential(x=..., y=..., z=..., v_x=..., v_y=..., v_z=...)
cord2 = CartesianDifferential(x=..., y=..., z=..., v_x=..., v_y=..., v_z=...)
part1 = Body(name='Particle',mass=...,R = ...,parent=b1, differential=cord1)
part2 = Body(name='Particle',mass=...,R = ...,parent=b1, differential=cord2)
# and so on
geod1 = Geodesic(body=part1, end_lambda=..., step_size=...)
geod2 = Geodesic(body=part2, end_lambda=..., step_size=...)
# and so on
# plotting code as above
Multiple "attractors" with comparable masses will alter the background metric (Schwarzschild
in this case) and it will require solving the full Einstein field equations (or a perturbed / linearized form of them) to get the form of the metric that can define this new spacetime geometry with multiple gravitating masses.
step_size
and inaccurate results, we generally make use of Geometrized units in numerical relativity, which rescale SI quantities such that large distances and steps are not needed to explore interesting phenomena. This is also why we pivoted away from this API in later versions of EPy (which use M-units, G = c = M = 1).Geodesic
above, since not all metrics enjoy the generalizability given to Schwarzschild
-like metrics by the Birkhoff theorem.Hi folks, been a part of this community since 2020, but haven't contributed much. I'm looking to work with interesting open-source projects, hence I'm here.
About me:
GSoC'2021 at Stingray, GSoD'21/22. Ex: Sequoia Cap, Blume Ventures, Venture Highway.
I was looking at issues, and wished to pickup: einsteinpy/einsteinpy#626 to understand the codebase better