yt-users January 2021

yt-users@python.org

4 participants
6 discussions

Porting .ply files to Blender with colors?
by Jill P. Naiman 14 Aug '22

14 Aug '22

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 11 Dec '21

11 Dec '21

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 01 Feb '21

01 Feb '21

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 31 Jan '21

31 Jan '21

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 22 Jan '21

22 Jan '21

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 20 Jan '21

20 Jan '21

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

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

yt-users January 2021