Mailman 3 January 2021 - yt-users

Porting .ply files to Blender with colors?
by Jill P. Naiman Aug. 14, 2022

Aug. 14, 2022

Hi All, I was curious if anyone has had any luck porting .ply files generated with yt into Blender with colors? It seems to port in the surfaces just fine, but they are a uniform color. From what I can gather, Blender imports .ply files with face color instead of vertex so I tried the surf.export_ply routine with "face" instead of "vertex" for sample_type, but no luck ("vertex" doesn't work either). Let me know if I can provide any more useful info. Thanks for any help, -J

3 2

Stars on volume rendering
by Elizabeth Harper-Clark Dec. 11, 2021

Dec. 11, 2021

Hi all, Thanks for all your help over the last couple of days. One more question: - Can I plot particles on a volume rendered image? I have stars and I want to show where they are! Thanks, Libby -- Elizabeth Harper-Clark MA MSci PhD Candidate, Canadian Institute for Theoretical Astrophysics, UofT Sciences and Engineering Coordinator, Teaching Assistants' Training Program, UofT www.astro.utoronto.ca/~h-clark <http://www.astro.utoronto.ca/%7Eh-clark> h-clark(a)cita.utoronto.ca Astronomy office phone: +1-416-978-5759

8 14

3D field and spherical object
by Salome Mtchedlidze Feb. 1, 2021

Feb. 1, 2021

Hello! 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) def _elec_den(field,data): 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: dd['elec_den'] 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? Thanks, Salome

2 8

Issue with stereo-spherical lens for plotting merging galaxies
by david.smolinski＠hs.uni-hamburg.de Jan. 31, 2021

Jan. 31, 2021

Hi yt-Users, 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: data=yt.load(…) 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? Many thanks, David Smolinski

2 1

yt-4: Migration to a new configuration system | action required on your side
by Corentin CADIOU Jan. 22, 2021

Jan. 22, 2021

Dear all, 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: https://yt-project.org/docs/dev/reference/configuration.html. *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 | Per-folder configuration 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 ~/.config/yt/yt.toml # or yt config set yt log_level 40 --local # this will write in ./yt.toml Naming convention 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 (https://yt-project.org/docs/dev/reference/configuration.html). 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 # yt.toml [fields] cmap = "arbre" [fields.gas] cmap = "viridis" [fields.gas.temperature] 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. Best, Corentin -- Dr. Corentin Cadiou Post Doctoral Research Assistant Cosmoparticle Initiative Hub, desk 27 University College London (UCL) Gower St, Bloomsbury, London WC1E 6BT mobile: +33.6.43.18.66.83

1 0

Branch name change
by Matthew Turk Jan. 20, 2021

Jan. 20, 2021

Hi folks, As a quick update, the primary branch for yt-project/yt is now "main", renamed from "master". This should be minimally invasive, but if you run into any troubles, let us know! -Matt

1 0