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
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
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
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
--- 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.
--- 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.
--- 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.
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)
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
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
