yt-dev December 2012

yt-dev@python.org

14 participants
18 discussions

NumberDensity in clumps and on FLASH data

by Matthew Turk

Hi all, Mark Richardson wrote to the yt_analysis project with a problem with clumps on FLASH datasets. Here's his email: "Below includes my script and the output (it wouldn't let me attach two files). I get some output in the clump file up until I'd expect to see the Jeans Mass dumped. The output makes me think that it can't calculate this point because Gamma is unknown, or some other essential variable needed to get the number density. I've attempted to change the data_structure.py frontend for Flash to alias Gamma to gamc and game but I still get the 'cannot find Gamma' when loading my dataset." The issue from the traceback is that JeansMassMsun requires MeanMolecularWeight which needs NumberDensity. This can't be generated for his data. I am not an expert on FLASH, but it seems that this should be straightforward to fix, I just don't know how. Anybody from the FLASH or Clump side have any ideas? -Matt

8 years, 6 months

streamlines, magnetic field loops, and such

by j s oishi

Hi all, I was wondering what the status of streamlines in yt's volume renderer is. I looked at Sam's talk from last year, and I was wondering if anyone has been working on them. I'd really like to make diagrams like figure 5 of this paper: http://arxiv.org/pdf/1212.5612v1.pdf I'd like to integrate streamlines into other kinds of visualizations, putting them in the same scene as (opaque) volume renders, but I honestly have zero knowledge of how graphics works, both inside and outside yt. I'm going to be working on some projects this year that would make great use of streamline visualization. I'd be happy to lend a hand to this effort, so if anyone has any suggestions on how I could get started, even basic resources, I'd be much appreciative. thanks, j

9 years

Four big YTEPs right now, plus a couple PRs

by Matthew Turk

Hi all, I'm trying to clean off my plate before disappearing for a few days, and I wanted to round up some outstanding PRs and YTEPs. So far I'm quite happy with how YTEPs have been going, as I think that constructing these living documents will pay dividends over time. YTEPs: There are currently four outstanding YTEPs, even if one has been accepted and the discussion has moved. I would like to solicit comments on these from the community. * Casey proposed new field names. One issue Devin brought up today is pretty interesting, which is that a big area we have not really discussed is in naming of molecular and atomic species. https://bitbucket.org/yt_analysis/ytep/pull-request/3/ytep-0003 * Kacper has some vector field ideas: https://bitbucket.org/yt_analysis/ytep/pull-request/4/ytep-0004 * I just submitted a YTEP documenting Octree support: https://bitbucket.org/yt_analysis/ytep/pull-request/5/initial-import-of-oct… (Related N-body/SPH notebook: http://hub.yt-project.org/nb/h2tvp7 ) * And finally, the profiling YTEP has been accepted, but discussion of specifics has moved over to the pull request itself: https://bitbucket.org/yt_analysis/yt/pull-request/369/new-profile-objects-t… Once the discussions there (specifically, now about weighting) have been resolved I will update the YTEP to reflect them. -- All of these are really places where contributions of thoughts and ideas (and code!) are greatly appreciated. Many of them relate to yt 3.0, but the profiling one specifically will be a part of the now-delayed yt 2.5 release. There are also two additional outstanding pull requests: * Sam has re-written the kD-tree code to be much cleaner and nicer. (I made the mistake of misreading his PR and providing line by line comments -- sorry, Sam!) Testing of this PR would be greatly appreciated. https://bitbucket.org/yt_analysis/yt/pull-request/383/amrkdtree-rewrite-vol… * Nathan has addressed some issues with FLASH domains, which I think needs some insight from individuals more experienced with FLASH than I am. https://bitbucket.org/yt_analysis/yt/pull-request/382/checking-if-a-user-sp… -- Okay, that's all. Please comment on the YTEPs, PRs, etc etc. I'll be high-latency for a few days, as I suspect many others will too, but if you feel like providing feedback it's a good time to do so. One additional thought to put out there is, should we be doing outreach to the community of people who don't consider themselves developers as we create these YTEPs and PRs? To solicit feedback, for instance? -Matt

9 years

Definition of the Radius field

by Nathan Goldbaum

This is a discussion that began on yt-users but since I'm going to speculate about how to change the code, I'm replying over here on yt-dev. I see now that it's difficult to check for periodic boundary conditions in a code-independent way in the middle of a field definition. There are a number of places where yt assumes periodic boundary conditions (mostly in plotting routines) but I don't see any places that programatically check the boundary conditions that the simulation was run with. Am I missing something somewhere? I feel like this functionality should be there but I'm not sure what the best solution is. Just spitballing: perhaps there be something like pf.periodic which is True or False? This would have to be defined in the individual code frontends by looking at runtime parameters. It's not obvious to me that this will be easy to do for codes that don't have self-describing data formats. Another issue is that a binary Periodic attribute won't be sufficient for simulations run with mixed boundary conditions. Does anyone else have any thoughts on this? I don't want to cause a huge disruption but I'm strongly -1 on the way the Radius field is currently written since it quietly produces incorrect results on a large number of test problem-like datasets. It won't be a problem in cosmological simulations so I worry that inexperienced users will tend to get bit by it. Cheers, Nathan On 12/21/12 4:26 PM, Geoffrey So wrote: > I've seen and used something similar in my ellipsoids, where the > domain width (DW) is used to calculate the shortest distance between > two points due to periodic boundary condition. So if you do not have > a periodic box then that line (involving DW) should be changed. This > is part of the reason why my ellipsoid container is limited to > periodic box only. > > I'm hoping to put in a flag to turn it off and on later, but if a flag > is put in to turn it off maybe I'll imitate it for the ellipsoids, too. > > From > G.S. > > On Fri, Dec 21, 2012 at 4:18 PM, Nathan Goldbaum > <nathan12343(a)gmail.com <mailto:nathan12343@gmail.com>> wrote: > > Hi all, > > I encountered a bit of odd code deep in the field definition code > and I need some help to understand why it is the way it is. > > The field I'm curious about is the Radius field (defined on line > 796 of universal_fields.py): > > def _Radius(field, data): > center = data.get_field_parameter("center") > DW = data.pf.domain_right_edge - data.pf.domain_left_edge > radius = np.zeros(data["x"].shape, dtype='float64') > for i, ax in enumerate('xyz'): > r = np.abs(data[ax] - center[i]) > radius += np.minimum(r, np.abs(DW[i]-r))**2.0 > np.sqrt(radius, radius) > return radius > > In particular, I don't understand this line: > > radius += np.minimum(r, np.abs(DW[i]-r))**2.0 > > Is this supposed to correct for some effect in periodic simulations? > > The reason I bring this up is because it caused some very weird > behavior in a 1D FLASH simulation. In this simulation, the domain > went from x = -.01 pc to x = +500 pc. Since the middle of the > domain wasn't lined up with the 'center' of the simulation at x = > 0, the offending line in the radius calculation led to an > incorrect calculation of the radius beyond x = 250 pc. In that > case, I was able to fix it by changing the offending line to > > radius += r**2.0 > > Before I issue a patch, I want to see why it's defined the way it > is currently and see if we can come up with a workaround. > > Cheers, > > Nathan > _______________________________________________ > yt-users mailing list > yt-users(a)lists.spacepope.org <mailto:yt-users@lists.spacepope.org> > http://lists.spacepope.org/listinfo.cgi/yt-users-spacepope.org > > > > > _______________________________________________ > yt-users mailing list > yt-users(a)lists.spacepope.org > http://lists.spacepope.org/listinfo.cgi/yt-users-spacepope.org

9 years, 1 month

[yt_analysis/yt] Fields don't know about periodic boundary conditions (issue #484)

by Nathan Goldbaum

--- you can reply above this line --- New issue 484: Fields don't know about periodic boundary conditions https://bitbucket.org/yt_analysis/yt/issue/484/fields-dont-know-about-perio… Nathan Goldbaum: Right now it's hard to figure out whether a simulation was run using periodic boundary conditions. Since some of the fields (in particular, Radius) need to know about the boundary conditions, right now yt assumes periodic boundary conditions. Unfortunately, this leads to incorrect results when (for example) one makes a profile versus Radius of non-periodic data that is near the domain boundaries. There needs to be some way of passing in the periodicity to the field definition. See this discussion on yt-dev: http://lists.spacepope.org/pipermail/yt-dev-spacepope.org/2012-December/002… A workaround is to locally redefine the various radius fields in a my_plugins.py file or at the top of a script: http://paste.yt-project.org/show/3024/ -- This is an issue notification from bitbucket.org. You are receiving this either because you are the owner of the issue, or you are following the issue.

9 years, 1 month

[yt_analysis/yt] Volume Rendering Rotation Issues (issue #483)

by salvesen

--- you can reply above this line --- New issue 483: Volume Rendering Rotation Issues https://bitbucket.org/yt_analysis/yt/issue/483/volume-rendering-rotation-is… salvesen: Hi, The camera.rotate functionality is not working properly. I've attached a script and the resulting renderings for a test that in order (1) takes a snapshot, (2) rotates the camera by 1/2 pi and takes a snapshot, and (3) rotates the camera by 3/2 pi and takes a snapshot. I *think* that subsequent rotations are meant to add onto the previous rotation, rather than inducing a rotation relative to the initial camera setup. Therefore, the series of steps described above should produce snapshots with rotations of 0, pi/2, and 2pi relative to the initial snapshot. However, this is clearly not the case from inspection of the output renderings. The 0 rotation and 2pi rotation do not match up like they should. I repeated this test for the assumption that the rotations are made relative to the original camera object orientation, rather than relative to the previous rotation. This also produced incorrect results. I'd also like to address the issue of documentation regarding the volume rendering tools. In my recent experience playing around with the various camera routines, I've found that the documentation often suffers from a lack of and/or ambiguous description. For instance, as mentioned above, it was unclear to me how sequential rotations are performed. Does the next rotation build off the last rotation or is each rotation made relative to the initial camera object? The most confusing notation issue I've come across thus far is how the center point, looking vector, north vector, (and rotation vector) work together to produce a volume rendering. Being confused on this front results in a lot of random guessing about how these all operate together. My current understanding is as follows: The center point defines the coordinate origin from which looking vectors, north vectors, and rotation vectors point radially away from. The north vector effectively defines the coordinate system to be used. If left alone, the camera will pick a north vector, which is perhaps not what the user is expecting. The looking vector is drawn from the origin (defined by the center point) with respect to the coordinate system (defined by the north vector). So, it seems to me that specifying a looking vector without knowing the north vector is equivalent to choosing an arbitrary looking vector (because you have no idea what the coordinate system is yet). Now, if one explicitly chooses the center point, north vector, and looking vector, the result is sensible (so that's good news). I think users would hugely benefit from a schematic vector illustration of what is going on here and they should be told upfront that the coordinate system is not pre-defined when they choose a looking vector, which often causes confusing viewing angles. Additionally, as described above, the rotation angle does not seem to work as advertised, which adds to the confusion of how one is supposed to go about producing a rendering with specific and deliberate camera motions. An example that does some semi-complex and intentional camera movements (including rotations and changing one's looking vector) would be very helpful. Thanks! - greg -- This is an issue notification from bitbucket.org. You are receiving this either because you are the owner of the issue, or you are following the issue.

9 years, 1 month

[yt_analysis/yt] Volume rendering the logarithm of a field (issue #482)

by salvesen

--- you can reply above this line --- New issue 482: Volume rendering the logarithm of a field https://bitbucket.org/yt_analysis/yt/issue/482/volume-rendering-the-logarit… salvesen: Hi, I am a new yt (and Python) user who uses the Athena code. I am trying to make a simple volume rendering of the logarithm of the density field. I am able to do this just fine for the density field alone, but the problem arises when wanting to render its log. For whatever reason, only the zero values of log(density) are being rendered. I've attached my code, the density rendering, the log(density) rendering, and the transfer function being used. The only difference between the density and log(density) rendering is changing the use_log variable from False to True in the volrender.py script. Thanks so much, - greg Responsible: samskillman -- This is an issue notification from bitbucket.org. You are receiving this either because you are the owner of the issue, or you are following the issue.

9 years, 1 month

DarkMatter Particles in Enzo + yt 3.0

by Stephen Skory

Hi all, I am starting to have potentially useful active particles in Enzo 3.0, and I'd like to look at them with yt 3.0. However, I'm still running into some problems accessing the active particles (APs). Specifically, the problems seems to be that in frontends/enzo/data_structures.py it's only looking for APs identified through parameter_file.parameters["AppendActiveParticleType"], but "DarkMatter" isn't listed as an AP type in the Enzo parameter file. Also, the inner loop over HDF5 AP group members in _detect_active_particle_fields(self) includes the "DarkMatter" field, which isn't expected, and causes a KeyError for the dict that is being built there. I think that there are a couple potential fixes for this (that I'm willing to do/help with), and I'd like your thoughts on them, please: 1. Modify yt such that the "DarkMatter" AP field is treated more like the non-AP fields, meaning that instead of using the "AppendActiveParticleType" parameter as the driver for searching, instead auto-detect "DarkMatter". Unlike other APs, "DarkMatter" should be in most grids and random auto-detection should work. 2. In Enzo include "DarkMatter" as a dummy AP type which would have the main/only effect of including "DarkMatter" as a "AppendActiveParticleType" parameter. I think that this would address all of the present issues with yt. Or perhaps even better, introduce a new Enzo parameter "ParticleTypesPresent" that would be ("AppendActiveParticleType") + "DarkMatter" most of the time. Thank you for your thoughts! -- Stephen Skory s(a)skory.us http://stephenskory.com/ 510.621.3687 (google voice)

9 years, 1 month

Bitbucket Issues Notification

by Sam Skillman

Hi all, I'd like to propose enabling the issue tracker notification system on bitbucket to send an email to yt-dev whenever an issue is raised. This is a new feature that they have recently added. +/- 1 ? Sam

9 years, 1 month

universal_fields field names

by Casey W. Stark

Hi all. I'm working on the unit system in yt-3.0 and I realized I have to touch a lot of the universal_fields module. I thought this might be a good time to clean up the rest of the module, since one of the 3.0 goals is to remove enzo-isms. We discussed this in a hangout and it's part of the 3.0 goals doc, but I want to get a final word before I start. The idea is to make all universal field names lowercase underscored. I was not planning on changing names otherwise, but it would be a good time. This is definitely breaking compatibility, so we should get some consensus. 3.0 is a good time for this, but do we definitely want to? I wrote up a very small YTEP on this, but I don't have write access. Should we do pull requests for this too, or grant access as needed? - Casey

9 years, 1 month

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

yt-dev December 2012