Question: adding new fields for GAMER
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"? Thanks in advance for the help!! Sincerely, Hsi-Yu
Hi Hsi-Yu,
On Mon, Oct 29, 2012 at 9:54 AM, Hsi-Yu Schive
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@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
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.
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?
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")?
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)?
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 !!
Sincerely,
Hsi-Yu
----- Original Message -----
From: Matthew Turk
To: yt-dev@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
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@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
_______________________________________________ yt-dev mailing list yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
Hi Hsi-Yu,
On Tue, Oct 30, 2012 at 3:26 AM, Hsi-Yu Schive
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@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
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@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
_______________________________________________ yt-dev mailing list yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
_______________________________________________ yt-dev mailing list yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
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@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
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@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
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@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
_______________________________________________ yt-dev mailing list yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
_______________________________________________ yt-dev mailing list yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
_______________________________________________ yt-dev mailing list yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
participants (2)
-
Hsi-Yu Schive
-
Matthew Turk