<div dir="ltr">Hi Matthew,<div class="gmail_extra"><br></div><div class="gmail_extra">This is super cool.</div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Mar 28, 2017 at 2:23 PM, Matthew Horton <span dir="ltr"><<a href="mailto:mkhorton@lbl.gov" target="_blank">mkhorton@lbl.gov</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><div dir="auto" style="word-wrap:break-word"><div dir="auto" style="word-wrap:break-word"><div>Hi Nathan,</div><div><br></div><div>Thanks very much for this response!</div><span class=""><div><br></div><div>> it would help if you can give a little bit more detail about what sort of boundary conditions you need.</div><div><br></div></span><div>Sure, basically, the simulation box is exactly the same as the orthogonal case currently implemented by `yt.load_uniform_gird(data, … periodicity=(True,True,True)` *except* that in some cases the box has been deformed/sheared… in technical terms, the simulation box is defined by three basis vectors a, b and c which define its axes, and e.g. for a cubic crystal with lattice constant 4Å you’d have a=(4,0,0), b=(0,4,0), c=(0,0,4) and they'd correspond to the x, y and z axes… but in the general case, a b and c could be anything.</div></div></div></div></blockquote><div><br></div><div>Ah!  This is interesting, and kind of like (I think) the way NIFTI files store their transformations.  I spent some time implementing this at one point; basically, there are a few places that this comes up, both on the visualization and the analysis sides.</div><div><br></div><div>One the analysis side, which is likely easier to fix, there are fields like "x" "y" "z" and the corresponding "cell_volume" fields.  These would just need to have their volume elements computed correctly, which I think would be straightforward.</div><div><br></div><div>On the visualization side, there are two things that would need addressing.  The first of these, which is probably much more straightforward than the other, is coming up with a pixelization routine.  I made some headway into this at one point, where I tried to plot in "real" space versus "reference" space some fMRI datasets, but I ended up having to take other projects on and didn't complete it.  The pixelization routines are not terribly difficult to write; given boundaries, some reference information and the datapoints, it just has to produce a buffer.  Any mapping of f(a, b, c) => (x, y, z) can be used; for instance, we have pixelizers that do non-cartesian coordinates, and so a basis vector transformation wouldn't be so bad.</div><div><br></div><div>The other issue is coming up with a plotting API that allows for both reference and real space plotting, but that can be longer term.</div><div><br></div><div>I'd be interested to get more information from you about this, and we can see if the necessary work can be outlined and maybe taken on.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><div dir="auto" style="word-wrap:break-word"><div dir="auto" style="word-wrap:break-word"><div><br></div><div>Internally, the data is always stored as a uniform grid/array, but the points of the grid don’t correspond to (x,y,z) co-ords, but to fractional (a,b,c) co-ords.</div><div><br></div><div>In practical terms, currently trying to visualize this in yt would lead to a ‘correct’ but distorted/deformed visualization.</div><span class=""><div><br></div><div>> us = UnitSystem('custom', 'angstrom', 'me', 's', current_mks_unit='1.6e-19*A')</div><div><br></div></span><div>This looks like it should work, with my projection plots having axes labelled Angstroms, but units still seem to be cm (e.g. it’s showing axes in 10^9 Angstroms)… this may be user error on my part, I think I’m passing the correct length unit arguments etc., but I’ll continue to experiment. </div><div><br></div><div>I can share a datafile if that’d be helpful at all?</div></div></div></div></blockquote><div><br></div><div>If you have one you don't mind sharing, it could go on <a href="http://hub.yt">hub.yt</a> and we can take a look there.  Thanks!</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><div dir="auto" style="word-wrap:break-word"><div dir="auto" style="word-wrap:break-word"><div><br></div><div>I discovered yt while looking for a way to automate volumetric rendering of these CHGCAR files…the typical way to visualize these is either slice or isosurface, which loses a lot of information… but it looks like yt would be really useful for doing some more rigorous analysis of these datasets too, so it’d be great if we could get it to work :-)</div><div><br></div><div>Best regards,</div><div><br></div><div>Matthew</div><div><div class="h5"><br><div><blockquote type="cite"><div>On Mar 27, 2017, at 4:41 PM, Nathan Goldbaum <<a href="mailto:nathan12343@gmail.com" target="_blank">nathan12343@gmail.com</a>> wrote:</div><br class="m_-4646118010867779636Apple-interchange-newline"><div><div dir="ltr">Hi Matthew,<div><br></div><div>First this is the first I've heard of anyone using yt to look at crystallagraphic charge density data, so I'm glad you were able to get as far as you were.</div><div><br></div><div>Right now yt is mostly used by astrophysicists and there are still plenty of places where we make assumptions that are only really valid for astrophysics simulation data. We have long-term goals to improve this situation. Getting input on places where yt makes poor assumptions for data from new domains is very valuable for informing our long-term plans for yt development, so thank you for writing in :)</div><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Mar 27, 2017 at 5:50 PM, Matthew Horton <span dir="ltr"><<a href="mailto:mkhorton@lbl.gov" target="_blank">mkhorton@lbl.gov</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hello all,<br>
<br>
I’m a new user to yt looking for some general guidance.<br>
<br>
1. I have files describing the charge density in a crystal (CHGCAR files for any DFT/VASP users on the mailing list). I can import these with yt as generic (periodic) unigrid data, however the axes are not always orthogonal… In cubic crystals, `yt.load_uniform_grid` works perfectly, but in some crystals this would give a distorted visualization. What would be the best way to import this kind of data?<br></blockquote><div><br></div><div>Right now yt only supports periodic and isolated boundary conditions. Adding support for additional boundary conditions is a longstanding issue, but most of the time we get requests to add e.g. reflecting, inflow, or diode boundary conditions, not what you're asking about here.</div><div><br></div><div>Unfortunately I'm not terribly familiar with crystallography (the last I thought about this was in a solid state physics course I took in undergrad) so it would help if you can give a little bit more detail about what sort of boundary conditions you need.</div><div><br></div><div>Unfortunately it's not terribly easy right now to add new boundary conditions, so it might take some work to get yt fully working for non-cubic crystal structures. I don't think anyone is working on making it easier to add new boundary conditions but it's definitely on our long-term roadmap. If you'd like to work on this I'd be happy to chat further about what needs to be done in terms of code changes to get this working.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
2. Regarding units, the units in my file are nominally fractional electrons per grid cell volume, e/Angstrom^3 … importing into yt as a density field, what units should I use? Would be good to keep the data in its natural units, rather than converting to SI/cgs, because they’d be very very small floats otherwise.</blockquote><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
I tried 'unit_system = yt.UnitSystem('custom', 'Angstrom', 'g', 's’)' and this works as expected for the length units in my plots, but how do I set the custom Charge unit? What ‘units’ string would I then use for the density field? It doesn’t seem to want to accept ‘Angstrom’, ‘C’ etc.<br></blockquote><div><br></div><div><div>I *think* this will work:</div><div><br></div><div>us = UnitSystem('custom', 'angstrom', 'me', 's', current_mks_unit='1.6e-19*A')<br></div><div><br></div><div>Here 'me' is the electron mass.</div></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
Many thanks for any help!<br>
<br>
Best regards,<br>
<br>
Matthew<br>
______________________________<wbr>_________________<br>
yt-users mailing list<br>
<a href="mailto:yt-users@lists.spacepope.org" target="_blank">yt-users@lists.spacepope.org</a><br>
<a href="http://lists.spacepope.org/listinfo.cgi/yt-users-spacepope.org" rel="noreferrer" target="_blank">http://lists.spacepope.org/lis<wbr>tinfo.cgi/yt-users-spacepope.<wbr>org</a><br>
</blockquote></div><br></div></div>
______________________________<wbr>_________________<br>yt-users mailing list<br><a href="mailto:yt-users@lists.spacepope.org" target="_blank">yt-users@lists.spacepope.org</a><br><a href="http://lists.spacepope.org/listinfo.cgi/yt-users-spacepope.org" target="_blank">http://lists.spacepope.org/<wbr>listinfo.cgi/yt-users-<wbr>spacepope.org</a><br></div></blockquote></div><br></div></div></div></div></div><br>______________________________<wbr>_________________<br>
yt-users mailing list<br>
<a href="mailto:yt-users@lists.spacepope.org">yt-users@lists.spacepope.org</a><br>
<a href="http://lists.spacepope.org/listinfo.cgi/yt-users-spacepope.org" rel="noreferrer" target="_blank">http://lists.spacepope.org/<wbr>listinfo.cgi/yt-users-<wbr>spacepope.org</a><br>
<br></blockquote></div><br></div></div>