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

Hsi-Yu Schive hyschive at ntu.edu.tw
Tue Oct 30 05:41:26 PDT 2012


Hi Matt,

Thanks for the help! I'll keep looking into the code and reply and question I have.
Also, I'll be more than willing to share the image once I have the implementation done!

Sincerely,
Hsi-Yu

  ----- Original Message ----- 
  From: Matthew Turk 
  To: yt-dev at lists.spacepope.org 
  Sent: Tuesday, October 30, 2012 8:29 PM
  Subject: Re: [yt-dev] Question: adding new fields for GAMER


  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
  >
  _______________________________________________
  yt-dev mailing list
  yt-dev at lists.spacepope.org
  http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.spacepope.org/pipermail/yt-dev-spacepope.org/attachments/20121030/a11dd46a/attachment.htm>


More information about the yt-dev mailing list