[yt-dev] Question: adding new fields for GAMER

[Matthew Turk]

Hi Hsi-Yu,

On Tue, Oct 30, 2012 at 3:26 AM, Hsi-Yu Schive <hyschive at ntu.edu.tw> wrote:
> Hi Matt,
>
> Thanks for the explanation! Now it's clearer to me.
>
> Let me describe what I understand so far, and please correct me if there is
> anything wrong.
>
> When I use "add_gamer_field" to add a build-in field in GAMER,
> in principle I DON'T need to set the "function" parameter since the field
> values can
> be set directly to the loaded values, but I DO need to provide the
> "convert_function"
> parameter to properly convert unit to cgs.

Yup, that's right.  But it's probably a good idea to set the function
to NullFunc, as there may be places where the code checks to see if a
field has a "real" function or not.  So to be on the safe side:

add_gamer_field("SomeFieldInYourOutput", function=NullFunc,
convert_function = ...)

>
> On the other hand, when I use "add_field" to define a derived field, I DO
> need to set
> the "function" parameter to describe how to get the new derived field from
> the
> existing fields, but in principle I DON'T need to provide the
> "convert_function" again
> since all existing fields are already in cgs units. Is that correct?

In principle, yes.  I think in practice there are one or two fields
that are derived fields that also specify a conversion factor, but
most are because of things like converting to Msun and Mpc.

>
> One more question. In the field.py file of flash, I saw the following lines.
>
>    def _get_convert(fname):
>        def _conv(data):
>            return data.convert(fname)
>     return _conv
>     add_flash_field("divb", function=NullFunc, take_log=False,
>                                convert_function=_get_convert("divb"),
>                                 units = r"\mathrm{Gau\ss}\/\rm{cm}")
>
> My question is:
> 1. Where can I explicitly set the operations performed by
> data.convert("divb")?

data.convert(key) will look in the StaticOutput instance affiliated
with the data, specifically in its conversion_factors dictionary, and
find "key" in it.  So if you want data.convert(key) to work, set
self.conversion_factors[key] to be a floating point value inside the
StaticOutput instantiation -- you can see this in the FLASH and Enzo
frontends where it sets up units.

>
> 2. What "field" variables can be put into data["field"] (may all the fields
> that have been added by add_field and gamer_add_field)?
>

Yup!  Any real or derived field can be requested.

>
> Thank you very much for the help. The YT group is so active and I
> will be more than willing to have GAMER supported in YT ASAP !!
>

That's great to hear!  And once you do have it supported, send an
image from a recent simulation and we'll put it on the home page.  :)
Please feel free to ask any other questions you might have.

-Matt

> Sincerely,
> Hsi-Yu
>
>
>
> ----- Original Message -----
> From: Matthew Turk
> To: yt-dev at lists.spacepope.org
> Sent: Monday, October 29, 2012 10:42 PM
> Subject: Re: [yt-dev] Question: adding new fields for GAMER
>
> Hi Hsi-Yu,
>
> On Mon, Oct 29, 2012 at 9:54 AM, Hsi-Yu Schive <hyschive at ntu.edu.tw> wrote:
>> Dear all,
>>
>> I'm trying to add new fields used in GAMER by editing the file "field.py",
>> but I'm confused about the following declarations.
>>
>>    KnownGAMERFields = FieldInfoContainer()
>>    add_gamer_field = KnownGAMERFields.add_field
>>
>>    GAMERFieldInfo = FieldInfoContainer.create_with_fallback(FieldInfo)
>>    add_field = GAMERFieldInfo.add_field
>>
>> What is the difference between "KnownGAMERField" and "GAMERFieldInfo"?
>> To me, it seems that they are both instantiations of the class
>> FieldInfoContainer,
>> except that GAMERFieldInfo has a fallback function "FieldInfo".
>> Similarly, what's the difference between "add_gamer_field" and
>> "add_field"?
>
> Ah, this is something that should be made a bit clearer in the
> documentation.  The distinction is somewhat subtle, and relies on
> whether a field is something that could reasonably be expected to
> exist in a file, or
>
> A "known" field would be one that can exist in an output file.  The
> others are fields that could be derived from output from the
> particular code.  It's a bit of a semantic difference, but it helps
> with how derived fields are detected.  So if you know a field is going
> to (potentially) exist inside a data dump, it gets added with
> add_gamer_field.  As an example, FLASH has the field "dens".  We want
> to be able to access this field with either "dens" or "Density", so we
> do:
>
> add_flash_field("dens", function=NullFunc, ...)
>
> and then we add a translation (i.e., a *flash-specific* derived field) with:
>
> add_field("Density", function=TranslationFunc("dens"))
>
> I hope that helps!
>
> Also, thanks for adding support for GAMER!
>
> -Matt
>
>>
>> Thanks in advance for the help!!
>>
>> Sincerely,
>> Hsi-Yu
>>
>>
>>
>> _______________________________________________
>> yt-dev mailing list
>> yt-dev at lists.spacepope.org
>> http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
>>
> _______________________________________________
> yt-dev mailing list
> yt-dev at lists.spacepope.org
> http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
>
>
> _______________________________________________
> yt-dev mailing list
> yt-dev at lists.spacepope.org
> http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
>