[yt-users] Gadget blocks' configuration

Nathan Goldbaum nathan12343 at gmail.com
Mon Sep 26 08:24:39 PDT 2016


On Mon, Sep 26, 2016 at 10:15 AM, Bernhard Röttgers <
broett at mpa-garching.mpg.de> wrote:

> Hi Britton,
>
> thanks for the answer and sorry for my late answer!
>
> No, I don’t have OWLS/EAGLE/Gizmo snapshots. I actually just wanted to
> compare my results with yt/trident, but your solution does not seem to be
> too complicated. How, am I supposed to use it? (Sorry for asking dump
> questions. I’m not familiar with yt.) I understood that I can load a Gadget
> snapshot with like:
>
> ds = yt.load(YT_FNAME, unit_base=UNIT_BASE, bounding_box=bbox)
> ds.index
>
> The data structure `ds` then is what is passed to trident. Where does the
> new frontend come into play?
>

Right now yt makes certain assumptions about the structure and meaning of
data in Gadget output files. The assumptions currently used in yt are based
on the public data the yt developers have access to (e.g. the datasets on
yt-project.org/data) and are only valid in so far as those datasets are
representative of Gadget data in general. Due to the history of the
Gadget's code, there are in reality many different flavors of Gadget that
make different assumptions about what the data they write to disk means,
and it seems yt doesn't currently make incorrect assumptions for your
flavor of Gadget data.

Do you happen to have a test dataset that you can share? In principle the
necessary modification should be simple, and having a dataset to test with
would be helpful. One way to share files with us is to use the yt curldrop:

https://docs.hub.yt/services.html#curldrop


>
> And some more questions:
> What exactly are the code metallicity units? In my case yt says its in
> units of 1. Is this interpreted as absolute units or in solar metallicity?
>

In units of solar metallicity. There is also the metal_density, which
should have units of g/cm**3 (by default, if may be different if you
specified a value for the `unit_system` keyword when you called the load()
function.


>
> Cheers,
> Bernhard
>
>
> On 19 Sep 2016, at 15:04, Britton Smith <brittonsmith at gmail.com> wrote:
>
> Hi Bernhard,
>
> Does your data come from a specific flavor of Gadget that is supported by
> yt?  For example, we currently support OWLS, EAGLE, and Gizmo data that
> have fields for individual elements.  If not, then it is probably best to
> try and put together a new frontend for this data.  If the type of data
> that you're working with is not public or widely used, the best thing may
> be to create a frontend that exists as a yt extension (an external module
> not inside the main yt codebase).  Here is an example of one that I created
> a while back for the FIRE simulation data:
> https://bitbucket.org/brittonsmith/yt_fire
>
> If the only thing that is different about your data is the way that the
> metallicity fields are defined, then it shouldn't be too difficult to
> create a subclass of an existing Gadget frontend that overrides the field
> definitions.  Please, let us know if you're interested in pursuing this and
> we can work with you.
>
> Britton
>
> On Sat, Sep 17, 2016 at 11:45 AM, Bernhard Röttgers <
> broett at mpa-garching.mpg.de> wrote:
>
>> Hello!
>>
>> I am trying to use trident
>> <https://bitbucket.org/trident-project/trident> (yt-based code) to
>> generate spectra out of my Gadget simulations (stored in HDF5). I could get
>> the code running, but the spectra are scaled weirdly. I was able to track
>> the problem down to a weirdly scaled metallicity block within yt. I am
>> guessing that the issue is related to the fact, that my block “Metallicity”
>> is in fact element masses for individual elements, i.e. for each particle I
>> have an array of masses for the 12 elements He, C, Mg, O, Fe, Si, H, N, Ne,
>> S, Ca, and the rest (I know, a crappy naming for such a block, but that’s
>> the way it is).
>>
>> Is there a way to force yt to create the metallicity block correctly?.
>>
>> Cheers,
>> Bernhard
>>
>> _______________________________________________
>> yt-users mailing list
>> yt-users at lists.spacepope.org
>> http://lists.spacepope.org/listinfo.cgi/yt-users-spacepope.org
>>
>>
> _______________________________________________
> yt-users mailing list
> yt-users at lists.spacepope.org
> http://lists.spacepope.org/listinfo.cgi/yt-users-spacepope.org
>
>
>
> _______________________________________________
> yt-users mailing list
> yt-users at lists.spacepope.org
> http://lists.spacepope.org/listinfo.cgi/yt-users-spacepope.org
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.spacepope.org/pipermail/yt-users-spacepope.org/attachments/20160926/9b594f77/attachment.html>


More information about the yt-users mailing list