I want to create 3D field within a spherical object. For example, I create 3D electron density in the following manner:
ds = yt.load("DATA")
dd = ds.all_data()
max_level = ds.index.max_level
ref = 2**max_level
low = ds.domain_left_edge
dims = ds.domain_dimensions*ref
nx, ny, nz = dims
L = (ds.domain_right_edge - ds.domain_left_edge).d
all_data_level_max = ds.covering_grid(level=max_level,left_edge=low,dims=dims)
N_A = 1/1.6726219e-24
X = 0.70
return ((all_data_level_max['gas','density'])*N_A*(1+X)/2/ds.quan(1,'g') )
ds.add_field(('gas','elec_den'), function=_elec_den, units='auto', dimensions=dimensions.number_density)
Then if I do:
it will give me a 3D field which will have the same dimensions as the root grid of the dataset. However, if I create spheres and then a spherical object between these two spheres:
rvir = 4.2454307068129566e+24 #virial radius of a halo [cm].
xyz = [0.4208984375, 0.2216796875, 0.5185546875] #centre of a halo.
sph1 = ds.sphere(xyz, (2*rvir, 'cm'))
sph2 = ds.sphere(xyz, (4*rvir, 'cm'))
cutout_obj = sph2 - sph1
cutout_obj['elec_den'] or sph1['elec_den'] and sph2['elec_den'] will have the same dimensions as dd['elec_den'] ; but this cannot be true since sph1 and sph2 include less grid points.
Is there a way I can create 3D field and use it within a different yt objects?
I have an issue with the stereo-spherical lens in volume rendering. I am simulating galaxy collusions with the Enzo Code and now I want to try to visualize these collusions in VR with the help of the stereo-spherical lens. My problem right now is that my box I am simulating the galaxies in, is much bigger than the galaxies itself. So, the galaxies are very small in the end and the plot is quite inexpressive. My approach to solve this problem was to reduce the volume, by putting a sphere around my galaxies like:
ds= data.h.sphere(‘max’, (100, ‘kpc’)
(Please feel free to check the whole code on: https://cloud.hs.uni-hamburg.de/s/NZMiAWkSX9Zztse)
But in the end this doesn´t changed the look of plot at all. The galaxies were as small as before.
Do you have an idea how to solve this problem and getting a better view on the merging galaxies?
TLDR; We recently migrated yt's configuration system from the yt-3
format to a new and more flexible format in yt-4 (the toml format, see
https://github.com/yt-project/yt/pull/2981). *This requires a manual
intervention to perform the migration (see details below).*
*What does it change for users?*
The new configuration system is documented online here:
*Performing the migration*
The change requires a one-time manual intervention on your side to
perform the migration automatically. To perform the migration, simply
type in your console
yt config migrate
This should migrate your old configuration to the new format (stored in
~/.config/yt/yt.toml) and store a backup of your old configuration file
in ~/.config/yt/ytrc.bak should any error happen. Please report any
issue you may encounter in the migration procedure so that we can fix
them before releasing officially yt-4.
If you get an error about a missing toml package, you may also have to
install the toml package manually|
| conda install -c conda-forge toml # if you are using conda
pip install toml # otherwise
The new configuration system allows you to configure yt per-folder. In
particular, if a file named yt.toml is present in your current working
folder, this file will override the global configuration. You can easily
configure yt from the command line using
yt config set yt log_level 40 --global # this will write in
yt config set yt log_level 40 --local # this will write in ./yt.toml
We have also rationalized the naming convention of configurable keys in
the configuration file: all keys now use snake case (i.e. words
separated by an underscore). For example loglevel has become log_level.
This is handled automatically by the configuration script, but bear that
in mind if you modify the configuration file. For reference, all
configurable keys can currently be found online
https://github.com/yt-project/yt/blob/main/yt/config.py#L12 and the most
important ones are documented online
What does it change for developers?
The new format should allow more flexible configuration options. In
particular, it supports nested configuration blocks and allows to find
the most specific key in the configuration file
cmap = "arbre"
cmap = "viridis"
cmap = "plasma"
In Python, you can then query the "most specific" key matching a given path:
from yt.config import ytcfg
ytcfg.get_most_specific("fields", "gas", "temperature", "cmap") == "plasma"
ytcfg.get_most_specific("fields", "gas", "density", "cmap") == "viridis"
ytcfg.get_most_specific("fields", "io", "velocity_x", "cmap") == "arbre"
This isn't used anywhere /yet/. The other breaking change compared to
the old configuration system is that ytcfg.get returns typed quantities
(as read by the toml parser) instead of strings.
Dr. Corentin Cadiou
Post Doctoral Research Assistant
Cosmoparticle Initiative Hub, desk 27
University College London (UCL)
Gower St, Bloomsbury, London WC1E 6BT