Hi all,
I've just written functions to compute velocities of things in various ways,
primarily for halos. For example, one could use these to calculate the circular
velocity curve of a halo very easily. I do this by rotating and translating the
coordinates to make the velocity calculations very easy. I am not done with this
stuff, I need to write some code such that the vector output can be de-rotated
back into the original physical coordinates. For now it outputs velocities as 1D
speeds, which is good enough for me right now. Anyway, what I'm asking is, where
do we think is the best place to sick this in terms of the yt directory
hierarchy? I have a file named 'math_utils.py' which might be appropriate for
this. This will go in yt-dev for the near future. Ideas?
The heavily documented code:
http://paste.enzotools.org/show/1105/
_______________________________________________________
sskory(a)physics.ucsd.edu o__ Stephen Skory
http://physics.ucsd.edu/~sskory/ _.>/ _Graduate Student
________________________________(_)_\(_)_______________
>From the Kraken FAQ (thanks to Jeff for pointing this out to me):
Why am I getting "could not find *.so"? Or: can I use dynamic libraries?
These files are dynamic libraries, which exist on an NFS file system,
which is not visible to the compute nodes. Thus, when the dynamic
linker goes to add the library, it can not find it. In the past,
dynamic libraries were not supported on the compute nodes. Now, you
may be able to use dynamic libraries if you have the files on Lustre,
but it is recommended that you use static executables regardless. To
check if an executable has dynamic linking, use ldd executable
http://www.nics.tennessee.edu/faq
-Matt
Hi all,
Today at a meeting, it was mentioned that perhaps yt is having trouble
with parallelism. To everyone out there: how reflective is this of
your experience? Is yt okay with parallelism? (Excluding
projections, which I have a new engine ready to go on.)
-Matt
Hi Peter,
I've CC'd yt-dev on the reply.
I think that the total mass in a halo would also be a reasonable
proxy; calculating the virial radius is more expensive, but also
doable. If we added a total mass scaling, would you suggest scaling
the mass by using the implicit volume of the circle plotted?
-Matt
On Thu, Aug 5, 2010 at 2:14 PM, Peter Behroozi <pbehroozi(a)gmail.com> wrote:
> Hi Matt,
>
> Since Ji-hoon mentioned that the Yt recipe plots the maximum halo radius instead of Rvir, would there be a simple change to plot a different, more stable halo parameter instead? As shown below, the circles as currently plotted change quite a bit in size between timesteps. :)
>
> All best,
>
> Peter
>
>
Hi all,
I broke volume rendering (via yt.extensions.volume_rendering) some
time ago, and I only just realized it today when some people were
getting corrupted images. It took a while to come up because I
avoided re-generating the Cython/C code that actually conducts the
volume rendering; however, recently I updated this code and pushed it
to the repository, and that's when the errors started showing up.
The exact error was in mercurial changeset 3007999e2518 (May 30),
which I merged into trunk in revision 1754 (June 24). These dates are
not necessarily the dates at which the error showed up, however, as
the re-cythonization probably did not occur at those times. The error
was in the optimization of division by the inverse of the vector
direction; the rays to cast were passed to partitioned bricks and to
avoid too much division of 64-bit floats, I changed it to be a
multiplication against the inverse.
To calculate the inverse, I did something similar to this:
for i in range(3):
iv_dir[i] = 1.0/v_dir[0]
The error, of course, being that I was dividing by v_dir[0] for all
three values.
I identified this by using the hg bisect command, where I found a good
revision and a bad revision and it executed the necessary tests to
figure out where the code took a turn for the worse. I've committed
fixes in hg changeset f0960f4f6bed, svn trunk r1804 and svn yt-1.7
r1805.
I'm really sorry for the troubles, and I hope that it hasn't cost
anyone too much time. There may still be some lingering bugs, so
please let me know if you run into any more bad images or difficulties
with the volume rendering. You can get an updated yt by doing "yt
instinfo -u".
-Matt
