Hi Matt,<div><br></div><div>That helps a lot to clarify things. Unfortunately it also makes it clear that right now I think (and others could chime in) that this would be difficult to get full functionality out of yt for your data. Right now yt is only capable of handling particle or rectangular solid zones (elements, cells), and doesn't know how to handle complicated mesh geometries. This means that things like slices, projections, and volume renderings would be difficult to get going.</div>
<div><br></div><div>However, I think you might be able to get minimal functionality for things like profiles. You would need to over-ride how x,y,z positions are calculated, but you could then do things like </div><div>
<a href="http://yt-project.org/doc/cookbook/simple_plots.html#simple-phase-plots">http://yt-project.org/doc/cookbook/simple_plots.html#simple-phase-plots</a></div>
<div><br></div><div>Anyways, I think this would be difficult right now until yt handles meshes in a more explicit fashion. Does anyone else have thoughts on this?</div><div><br></div><div>Best,</div><div>Sam</div><div><br>
<br><div class="gmail_quote">On Wed, Aug 8, 2012 at 11:37 AM, Matt Terry <span dir="ltr"><<a href="mailto:matt.terry@gmail.com" target="_blank">matt.terry@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
The basic ideas is that you have a simple x,y,z mesh with logical<br>
indexes i,j,k. The Lagrangian part is that the spatial grid moves<br>
with the fluid flow. Logically Cartisian meas that an i, j, k index<br>
makes sense. If you make several of these meshes, you can stitch them<br>
together to make a mesh where a global i, j, no longer makes sense.<br>
My mesh looks like this:<br>
<br>
<a href="http://visitusers.org/images/4/44/Enhanced_reduced.jpg" target="_blank">http://visitusers.org/images/4/44/Enhanced_reduced.jpg</a><br>
<br>
The boundary between blocks 012 has reduced connectivity. The 12345<br>
boundary has enhanced connectivity.<br>
<div class="im"><br>
> 1. By "logically rectangular", do you mean that each computational element<br>
> has 6 neighbors that share a face, but the element itself can have a<br>
> deformed shape?<br>
<br>
</div>Yes. In 3D cartesian, each zone (volume defined by 8 mesh mesh<br>
vertexes) shares faces with 6 other zones. The zones are generally<br>
strangely shaped. Aspect ratios (assuming a vaguely rectangular<br>
shape) can of order dy/dx ~ 100. Generally smaller, but can be<br>
larger.<br>
<div class="im"><br>
> 2. Does reduced/enhanced connectivity zones mean one element can share a<br>
> face with, say, 4 elements? This would make it behave a bit like and<br>
> adaptive mesh refinement setup, which shouldn't be too bad.<br>
<br>
</div>A single zone (element?) will always have 6 neighbors, however more<br>
(or less) than 6 zones may share a vertex.<br>
<div class="im"><br>
> If the shapes of the elements change, I think it might be a little bit<br>
> tricky, but if they are all geometrically rectangular then it would be<br>
> easier.<br>
<br>
</div>Geometrically rectangular zones are novel.<br>
<div class="im"><br>
> Another big determinant of how easy this will be to implement is what the<br>
> data format looks like. Is there a method paper or other reference that<br>
> explains a bit more of the code/data structure?<br>
<br>
</div>Data structures are very simple. Each block is effectively a 3d<br>
numpy.ndarray. On disk, each block is contained within a single<br>
binary file. Multiple blocks may reside in the same file.<br>
<br>
Hope that helps. Happy to answer more questions.<br>
<div class="HOEnZb"><div class="h5"><br>
-matt<br>
_______________________________________________<br>
yt-dev mailing list<br>
<a href="mailto:yt-dev@lists.spacepope.org">yt-dev@lists.spacepope.org</a><br>
<a href="http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org" target="_blank">http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org</a><br>
</div></div></blockquote></div><br></div>