Hi all, On IRC today we noticed that Orion defines its ThermalEnergy field per unit volume but Enzo and FLASH define ThermalEnergy per unit mass. Is this a problem? Since yt defaults to the Enzo field names, should we try to make sure that all fields are defined using the same units as in Enzo? Is there a convention for how different codes should define derived fields that are aliased to Enzo fields? One problem for this particular example is that the Pressure field is defined in terms of ThermalEnergy in universal_fields.py so the units of ThermalEnergy become important if a user merely wants the gas pressure in the simulation. One possible solution for this issue would be the units overhaul we're planning. If all fields are associated with a unit object, we can simply query the units to ensure that units are taken care of correctly and code-to-code comparisons aren't sensitive to the units chosen for fields in the frontend. Personally, I think it would be best if we could make sure that all of the fields aliased to Enzo fields have the same units. Nathan Goldbaum Graduate Student Astronomy & Astrophysics, UCSC goldbaum@ucolick.org http://www.ucolick.org/~goldbaum
Hi Nathan. I'm also worried about this and I agree that fields with the same name should all be consistent. I would support some sort of cleanup of frontend fields, and I can get the Nyx fields in line and help with Enzo. I doubt we can do this, but I would prefer changing the field names as part of the removing enzo-isms and geometry handling refactoring pushes. For instance, the field in Orion could be thermal_energy_density and the field in Enzo could be specific_thermal_energy. I also noticed this issue when I was using "Density" in Enzo (proper density in cgs) and "density" in Nyx (comoving density in cgs). Best, Casey On Wed, Mar 28, 2012 at 1:47 PM, Nathan Goldbaum <goldbaum@ucolick.org>wrote:
Hi all,
On IRC today we noticed that Orion defines its ThermalEnergy field per unit volume but Enzo and FLASH define ThermalEnergy per unit mass. Is this a problem? Since yt defaults to the Enzo field names, should we try to make sure that all fields are defined using the same units as in Enzo? Is there a convention for how different codes should define derived fields that are aliased to Enzo fields?
One problem for this particular example is that the Pressure field is defined in terms of ThermalEnergy in universal_fields.py so the units of ThermalEnergy become important if a user merely wants the gas pressure in the simulation.
One possible solution for this issue would be the units overhaul we're planning. If all fields are associated with a unit object, we can simply query the units to ensure that units are taken care of correctly and code-to-code comparisons aren't sensitive to the units chosen for fields in the frontend.
Personally, I think it would be best if we could make sure that all of the fields aliased to Enzo fields have the same units.
Nathan Goldbaum Graduate Student Astronomy & Astrophysics, UCSC goldbaum@ucolick.org http://www.ucolick.org/~goldbaum
_______________________________________________ yt-dev mailing list yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
Hi Nathan and Casey, I agree with what both of you have said. The Orion/Nyx units should be made to be consistent, but more importantly I think we should continue breaking away from Enzo-isms in the code. As it stands, all of the universal fields call underlying Enzo-named aliases -- Density, ThermalEnergy, etc etc. I hope we can have a 3.0 out within a calendar year, hopefully by the end of this year. (I've been pushing on the geometry refactor, although recently other efforts have been paying off which has decreased my output there.) I am much, much less doubtful than Casey is that we cannot do this; in fact, I'm completely in favor of this and I think it would be relatively straightforward to implement. In the existing system we have a mechanism for aliasing fields. What we can do is provide an additional translation system where we enumerate the fields that are available for items in UniversalFields, and then construct aliases to those. This would mean changing what is aliased in existing non-Enzo frontends, and adding aliases in Enzo. The style of name Casey proposes is what I woudl also agree with: underscores, lower cases, and erring on the side of verbosity. The fields off hand that we would need to do this for (in their current enzo-isms): x-velocity => velocity_x (same for y, z) Density => density TotalEnergy => ? GasEnergy => thermal_energy_specific (and thermal_energy_density) Temperature => temperature and so on. Once we have these aliases in place, an overall cleanup of UniversalFields should take place. One place we should clean up is ensuring that there are no conditionals; rather than conditionals inside the functions, we should place those conditionals inside the parameter file types. So for instance, if you have a field that is calculated differently depending on the parameter HydroMethod (in Enzo for instance) you simply set a validator on the field requiring the parameter be set to a particular value, and then only the field which satisfies that validator will be called when requested. So we've gotten rid of a bunch of enzo-isms in the parameter files; after fields, what else can we address? And, I'd be up for sprinting on this (which should take just a few hours) basically any time next week or after. I'd also be up for talking more about geometry refactoring, if anyone is interested, but it's not quite to the point that I think I am satisfied enough with the architecture to request input / contributions. Sometimes (especially with big architectural things like this) I think it's a shame we do all of our work virtually, as I think a lot of this would be easier to bang out in person for a couple hours. -Matt On Wed, Mar 28, 2012 at 6:14 PM, Casey W. Stark <caseywstark@gmail.com> wrote:
Hi Nathan.
I'm also worried about this and I agree that fields with the same name should all be consistent. I would support some sort of cleanup of frontend fields, and I can get the Nyx fields in line and help with Enzo.
I doubt we can do this, but I would prefer changing the field names as part of the removing enzo-isms and geometry handling refactoring pushes. For instance, the field in Orion could be thermal_energy_density and the field in Enzo could be specific_thermal_energy. I also noticed this issue when I was using "Density" in Enzo (proper density in cgs) and "density" in Nyx (comoving density in cgs).
Best, Casey
On Wed, Mar 28, 2012 at 1:47 PM, Nathan Goldbaum <goldbaum@ucolick.org> wrote:
Hi all,
On IRC today we noticed that Orion defines its ThermalEnergy field per unit volume but Enzo and FLASH define ThermalEnergy per unit mass. Is this a problem? Since yt defaults to the Enzo field names, should we try to make sure that all fields are defined using the same units as in Enzo? Is there a convention for how different codes should define derived fields that are aliased to Enzo fields?
One problem for this particular example is that the Pressure field is defined in terms of ThermalEnergy in universal_fields.py so the units of ThermalEnergy become important if a user merely wants the gas pressure in the simulation.
One possible solution for this issue would be the units overhaul we're planning. If all fields are associated with a unit object, we can simply query the units to ensure that units are taken care of correctly and code-to-code comparisons aren't sensitive to the units chosen for fields in the frontend.
Personally, I think it would be best if we could make sure that all of the fields aliased to Enzo fields have the same units.
Nathan Goldbaum Graduate Student Astronomy & Astrophysics, UCSC goldbaum@ucolick.org http://www.ucolick.org/~goldbaum
_______________________________________________ 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
I'm down for a sprint on this next week. If others are interested in this one, we could poll for times. Maybe sit in a google hangout while we code? It's not quite pair-programming, but it's a big step up from IRC. Best, Casey On Thu, Mar 29, 2012 at 3:40 PM, Matthew Turk <matthewturk@gmail.com> wrote:
Hi Nathan and Casey,
I agree with what both of you have said. The Orion/Nyx units should be made to be consistent, but more importantly I think we should continue breaking away from Enzo-isms in the code.
As it stands, all of the universal fields call underlying Enzo-named aliases -- Density, ThermalEnergy, etc etc. I hope we can have a 3.0 out within a calendar year, hopefully by the end of this year. (I've been pushing on the geometry refactor, although recently other efforts have been paying off which has decreased my output there.) I am much, much less doubtful than Casey is that we cannot do this; in fact, I'm completely in favor of this and I think it would be relatively straightforward to implement.
In the existing system we have a mechanism for aliasing fields. What we can do is provide an additional translation system where we enumerate the fields that are available for items in UniversalFields, and then construct aliases to those. This would mean changing what is aliased in existing non-Enzo frontends, and adding aliases in Enzo. The style of name Casey proposes is what I woudl also agree with: underscores, lower cases, and erring on the side of verbosity. The fields off hand that we would need to do this for (in their current enzo-isms):
x-velocity => velocity_x (same for y, z) Density => density TotalEnergy => ? GasEnergy => thermal_energy_specific (and thermal_energy_density) Temperature => temperature
and so on.
Once we have these aliases in place, an overall cleanup of UniversalFields should take place. One place we should clean up is ensuring that there are no conditionals; rather than conditionals inside the functions, we should place those conditionals inside the parameter file types. So for instance, if you have a field that is calculated differently depending on the parameter HydroMethod (in Enzo for instance) you simply set a validator on the field requiring the parameter be set to a particular value, and then only the field which satisfies that validator will be called when requested.
So we've gotten rid of a bunch of enzo-isms in the parameter files; after fields, what else can we address? And, I'd be up for sprinting on this (which should take just a few hours) basically any time next week or after. I'd also be up for talking more about geometry refactoring, if anyone is interested, but it's not quite to the point that I think I am satisfied enough with the architecture to request input / contributions. Sometimes (especially with big architectural things like this) I think it's a shame we do all of our work virtually, as I think a lot of this would be easier to bang out in person for a couple hours.
-Matt
Hi Nathan.
I'm also worried about this and I agree that fields with the same name should all be consistent. I would support some sort of cleanup of frontend fields, and I can get the Nyx fields in line and help with Enzo.
I doubt we can do this, but I would prefer changing the field names as
of the removing enzo-isms and geometry handling refactoring pushes. For instance, the field in Orion could be thermal_energy_density and the field in Enzo could be specific_thermal_energy. I also noticed this issue when I was using "Density" in Enzo (proper density in cgs) and "density" in Nyx (comoving density in cgs).
Best, Casey
On Wed, Mar 28, 2012 at 1:47 PM, Nathan Goldbaum <goldbaum@ucolick.org> wrote:
Hi all,
On IRC today we noticed that Orion defines its ThermalEnergy field per unit volume but Enzo and FLASH define ThermalEnergy per unit mass. Is
a problem? Since yt defaults to the Enzo field names, should we try to make sure that all fields are defined using the same units as in Enzo? Is
a convention for how different codes should define derived fields that are aliased to Enzo fields?
One problem for this particular example is that the Pressure field is defined in terms of ThermalEnergy in universal_fields.py so the units of ThermalEnergy become important if a user merely wants the gas pressure in the simulation.
One possible solution for this issue would be the units overhaul we're planning. If all fields are associated with a unit object, we can simply query the units to ensure that units are taken care of correctly and code-to-code comparisons aren't sensitive to the units chosen for fields in the frontend.
Personally, I think it would be best if we could make sure that all of
On Wed, Mar 28, 2012 at 6:14 PM, Casey W. Stark <caseywstark@gmail.com> wrote: part this there the
fields aliased to Enzo fields have the same units.
Nathan Goldbaum Graduate Student Astronomy & Astrophysics, UCSC goldbaum@ucolick.org http://www.ucolick.org/~goldbaum
_______________________________________________ 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
+1. I'd also be up to help out with the sprint. Doing a virtual sprint using a google hangout might help mitigate some of the distance problems. While we're brining up Enzo-isms that we should get rid of, I think it might be a good idea to make a conceptual shift in the basic python UI. Instead referring to the interface between the user and the data as a parameter file, I think instead we should be talking about datasets. One would instantiate a dataset just like we do now with parameter files: ds = load(filename) A dataset would also have some universal attributes which would present themselves to the user as a dict, e.g. ds.units, ds.parameters, ds.basic_info (like current_time, timestep, filename, and simulation code), and ds.hierarchy (not sure how that would interfere with the geometry refactor). This may be a paintibg the bike shed discussion, but I think this shift will help new users understand how to access their data. Thoughts? On Mar 29, 2012, at 3:40 PM, Matthew Turk <matthewturk@gmail.com> wrote:
Hi Nathan and Casey,
I agree with what both of you have said. The Orion/Nyx units should be made to be consistent, but more importantly I think we should continue breaking away from Enzo-isms in the code.
As it stands, all of the universal fields call underlying Enzo-named aliases -- Density, ThermalEnergy, etc etc. I hope we can have a 3.0 out within a calendar year, hopefully by the end of this year. (I've been pushing on the geometry refactor, although recently other efforts have been paying off which has decreased my output there.) I am much, much less doubtful than Casey is that we cannot do this; in fact, I'm completely in favor of this and I think it would be relatively straightforward to implement.
In the existing system we have a mechanism for aliasing fields. What we can do is provide an additional translation system where we enumerate the fields that are available for items in UniversalFields, and then construct aliases to those. This would mean changing what is aliased in existing non-Enzo frontends, and adding aliases in Enzo. The style of name Casey proposes is what I woudl also agree with: underscores, lower cases, and erring on the side of verbosity. The fields off hand that we would need to do this for (in their current enzo-isms):
x-velocity => velocity_x (same for y, z) Density => density TotalEnergy => ? GasEnergy => thermal_energy_specific (and thermal_energy_density) Temperature => temperature
and so on.
Once we have these aliases in place, an overall cleanup of UniversalFields should take place. One place we should clean up is ensuring that there are no conditionals; rather than conditionals inside the functions, we should place those conditionals inside the parameter file types. So for instance, if you have a field that is calculated differently depending on the parameter HydroMethod (in Enzo for instance) you simply set a validator on the field requiring the parameter be set to a particular value, and then only the field which satisfies that validator will be called when requested.
So we've gotten rid of a bunch of enzo-isms in the parameter files; after fields, what else can we address? And, I'd be up for sprinting on this (which should take just a few hours) basically any time next week or after. I'd also be up for talking more about geometry refactoring, if anyone is interested, but it's not quite to the point that I think I am satisfied enough with the architecture to request input / contributions. Sometimes (especially with big architectural things like this) I think it's a shame we do all of our work virtually, as I think a lot of this would be easier to bang out in person for a couple hours.
-Matt
On Wed, Mar 28, 2012 at 6:14 PM, Casey W. Stark <caseywstark@gmail.com> wrote:
Hi Nathan.
I'm also worried about this and I agree that fields with the same name should all be consistent. I would support some sort of cleanup of frontend fields, and I can get the Nyx fields in line and help with Enzo.
I doubt we can do this, but I would prefer changing the field names as part of the removing enzo-isms and geometry handling refactoring pushes. For instance, the field in Orion could be thermal_energy_density and the field in Enzo could be specific_thermal_energy. I also noticed this issue when I was using "Density" in Enzo (proper density in cgs) and "density" in Nyx (comoving density in cgs).
Best, Casey
On Wed, Mar 28, 2012 at 1:47 PM, Nathan Goldbaum <goldbaum@ucolick.org> wrote:
Hi all,
On IRC today we noticed that Orion defines its ThermalEnergy field per unit volume but Enzo and FLASH define ThermalEnergy per unit mass. Is this a problem? Since yt defaults to the Enzo field names, should we try to make sure that all fields are defined using the same units as in Enzo? Is there a convention for how different codes should define derived fields that are aliased to Enzo fields?
One problem for this particular example is that the Pressure field is defined in terms of ThermalEnergy in universal_fields.py so the units of ThermalEnergy become important if a user merely wants the gas pressure in the simulation.
One possible solution for this issue would be the units overhaul we're planning. If all fields are associated with a unit object, we can simply query the units to ensure that units are taken care of correctly and code-to-code comparisons aren't sensitive to the units chosen for fields in the frontend.
Personally, I think it would be best if we could make sure that all of the fields aliased to Enzo fields have the same units.
Nathan Goldbaum Graduate Student Astronomy & Astrophysics, UCSC goldbaum@ucolick.org http://www.ucolick.org/~goldbaum
_______________________________________________ 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
!DSPAM:10175,4f74e5073356450621218!
While we're brining up Enzo-isms that we should get rid of, I think it might be a good idea to make a conceptual shift in the basic python UI. Instead referring to the interface between the user and the data as a parameter file, I think instead we should be talking about datasets. One would instantiate a dataset just like we do now with parameter files:
ds = load(filename)
+1
+1 on datasets. On 3/29/12 6:58 PM, Nathan Goldbaum wrote:
+1. I'd also be up to help out with the sprint. Doing a virtual sprint using a google hangout might help mitigate some of the distance problems.
While we're brining up Enzo-isms that we should get rid of, I think it might be a good idea to make a conceptual shift in the basic python UI. Instead referring to the interface between the user and the data as a parameter file, I think instead we should be talking about datasets. One would instantiate a dataset just like we do now with parameter files:
ds = load(filename)
A dataset would also have some universal attributes which would present themselves to the user as a dict, e.g. ds.units, ds.parameters, ds.basic_info (like current_time, timestep, filename, and simulation code), and ds.hierarchy (not sure how that would interfere with the geometry refactor).
This may be a paintibg the bike shed discussion, but I think this shift will help new users understand how to access their data. Thoughts?
On Mar 29, 2012, at 3:40 PM, Matthew Turk<matthewturk@gmail.com> wrote:
Hi Nathan and Casey,
I agree with what both of you have said. The Orion/Nyx units should be made to be consistent, but more importantly I think we should continue breaking away from Enzo-isms in the code.
As it stands, all of the universal fields call underlying Enzo-named aliases -- Density, ThermalEnergy, etc etc. I hope we can have a 3.0 out within a calendar year, hopefully by the end of this year. (I've been pushing on the geometry refactor, although recently other efforts have been paying off which has decreased my output there.) I am much, much less doubtful than Casey is that we cannot do this; in fact, I'm completely in favor of this and I think it would be relatively straightforward to implement.
In the existing system we have a mechanism for aliasing fields. What we can do is provide an additional translation system where we enumerate the fields that are available for items in UniversalFields, and then construct aliases to those. This would mean changing what is aliased in existing non-Enzo frontends, and adding aliases in Enzo. The style of name Casey proposes is what I woudl also agree with: underscores, lower cases, and erring on the side of verbosity. The fields off hand that we would need to do this for (in their current enzo-isms):
x-velocity => velocity_x (same for y, z) Density => density TotalEnergy => ? GasEnergy => thermal_energy_specific (and thermal_energy_density) Temperature => temperature
and so on.
Once we have these aliases in place, an overall cleanup of UniversalFields should take place. One place we should clean up is ensuring that there are no conditionals; rather than conditionals inside the functions, we should place those conditionals inside the parameter file types. So for instance, if you have a field that is calculated differently depending on the parameter HydroMethod (in Enzo for instance) you simply set a validator on the field requiring the parameter be set to a particular value, and then only the field which satisfies that validator will be called when requested.
So we've gotten rid of a bunch of enzo-isms in the parameter files; after fields, what else can we address? And, I'd be up for sprinting on this (which should take just a few hours) basically any time next week or after. I'd also be up for talking more about geometry refactoring, if anyone is interested, but it's not quite to the point that I think I am satisfied enough with the architecture to request input / contributions. Sometimes (especially with big architectural things like this) I think it's a shame we do all of our work virtually, as I think a lot of this would be easier to bang out in person for a couple hours.
-Matt
On Wed, Mar 28, 2012 at 6:14 PM, Casey W. Stark<caseywstark@gmail.com> wrote:
Hi Nathan.
I'm also worried about this and I agree that fields with the same name should all be consistent. I would support some sort of cleanup of frontend fields, and I can get the Nyx fields in line and help with Enzo.
I doubt we can do this, but I would prefer changing the field names as part of the removing enzo-isms and geometry handling refactoring pushes. For instance, the field in Orion could be thermal_energy_density and the field in Enzo could be specific_thermal_energy. I also noticed this issue when I was using "Density" in Enzo (proper density in cgs) and "density" in Nyx (comoving density in cgs).
Best, Casey
On Wed, Mar 28, 2012 at 1:47 PM, Nathan Goldbaum<goldbaum@ucolick.org> wrote:
Hi all,
On IRC today we noticed that Orion defines its ThermalEnergy field per unit volume but Enzo and FLASH define ThermalEnergy per unit mass. Is this a problem? Since yt defaults to the Enzo field names, should we try to make sure that all fields are defined using the same units as in Enzo? Is there a convention for how different codes should define derived fields that are aliased to Enzo fields?
One problem for this particular example is that the Pressure field is defined in terms of ThermalEnergy in universal_fields.py so the units of ThermalEnergy become important if a user merely wants the gas pressure in the simulation.
One possible solution for this issue would be the units overhaul we're planning. If all fields are associated with a unit object, we can simply query the units to ensure that units are taken care of correctly and code-to-code comparisons aren't sensitive to the units chosen for fields in the frontend.
Personally, I think it would be best if we could make sure that all of the fields aliased to Enzo fields have the same units.
Nathan Goldbaum Graduate Student Astronomy& Astrophysics, UCSC goldbaum@ucolick.org http://www.ucolick.org/~goldbaum
_______________________________________________ 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
!DSPAM:10175,4f74e5073356450621218!
_______________________________________________ yt-dev mailing list yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
+1 on datasets, although I would like to see the unit object(s) at the field level. On Thu, Mar 29, 2012 at 4:04 PM, Cameron Hummels < chummels@astro.columbia.edu> wrote:
+1 on datasets.
On 3/29/12 6:58 PM, Nathan Goldbaum wrote:
+1. I'd also be up to help out with the sprint. Doing a virtual sprint using a google hangout might help mitigate some of the distance problems.
While we're brining up Enzo-isms that we should get rid of, I think it might be a good idea to make a conceptual shift in the basic python UI. Instead referring to the interface between the user and the data as a parameter file, I think instead we should be talking about datasets. One would instantiate a dataset just like we do now with parameter files:
ds = load(filename)
A dataset would also have some universal attributes which would present themselves to the user as a dict, e.g. ds.units, ds.parameters, ds.basic_info (like current_time, timestep, filename, and simulation code), and ds.hierarchy (not sure how that would interfere with the geometry refactor).
This may be a paintibg the bike shed discussion, but I think this shift will help new users understand how to access their data. Thoughts?
On Mar 29, 2012, at 3:40 PM, Matthew Turk<matthewturk@gmail.com> wrote:
Hi Nathan and Casey,
I agree with what both of you have said. The Orion/Nyx units should be made to be consistent, but more importantly I think we should continue breaking away from Enzo-isms in the code.
As it stands, all of the universal fields call underlying Enzo-named aliases -- Density, ThermalEnergy, etc etc. I hope we can have a 3.0 out within a calendar year, hopefully by the end of this year. (I've been pushing on the geometry refactor, although recently other efforts have been paying off which has decreased my output there.) I am much, much less doubtful than Casey is that we cannot do this; in fact, I'm completely in favor of this and I think it would be relatively straightforward to implement.
In the existing system we have a mechanism for aliasing fields. What we can do is provide an additional translation system where we enumerate the fields that are available for items in UniversalFields, and then construct aliases to those. This would mean changing what is aliased in existing non-Enzo frontends, and adding aliases in Enzo. The style of name Casey proposes is what I woudl also agree with: underscores, lower cases, and erring on the side of verbosity. The fields off hand that we would need to do this for (in their current enzo-isms):
x-velocity => velocity_x (same for y, z) Density => density TotalEnergy => ? GasEnergy => thermal_energy_specific (and thermal_energy_density) Temperature => temperature
and so on.
Once we have these aliases in place, an overall cleanup of UniversalFields should take place. One place we should clean up is ensuring that there are no conditionals; rather than conditionals inside the functions, we should place those conditionals inside the parameter file types. So for instance, if you have a field that is calculated differently depending on the parameter HydroMethod (in Enzo for instance) you simply set a validator on the field requiring the parameter be set to a particular value, and then only the field which satisfies that validator will be called when requested.
So we've gotten rid of a bunch of enzo-isms in the parameter files; after fields, what else can we address? And, I'd be up for sprinting on this (which should take just a few hours) basically any time next week or after. I'd also be up for talking more about geometry refactoring, if anyone is interested, but it's not quite to the point that I think I am satisfied enough with the architecture to request input / contributions. Sometimes (especially with big architectural things like this) I think it's a shame we do all of our work virtually, as I think a lot of this would be easier to bang out in person for a couple hours.
-Matt
On Wed, Mar 28, 2012 at 6:14 PM, Casey W. Stark<caseywstark@gmail.com> wrote:
Hi Nathan.
I'm also worried about this and I agree that fields with the same name should all be consistent. I would support some sort of cleanup of frontend fields, and I can get the Nyx fields in line and help with Enzo.
I doubt we can do this, but I would prefer changing the field names as part of the removing enzo-isms and geometry handling refactoring pushes. For instance, the field in Orion could be thermal_energy_density and the field in Enzo could be specific_thermal_energy. I also noticed this issue when I was using "Density" in Enzo (proper density in cgs) and "density" in Nyx (comoving density in cgs).
Best, Casey
On Wed, Mar 28, 2012 at 1:47 PM, Nathan Goldbaum<goldbaum@ucolick.org> wrote:
Hi all,
On IRC today we noticed that Orion defines its ThermalEnergy field per unit volume but Enzo and FLASH define ThermalEnergy per unit mass. Is this a problem? Since yt defaults to the Enzo field names, should we try to make sure that all fields are defined using the same units as in Enzo? Is there a convention for how different codes should define derived fields that are aliased to Enzo fields?
One problem for this particular example is that the Pressure field is defined in terms of ThermalEnergy in universal_fields.py so the units of ThermalEnergy become important if a user merely wants the gas pressure in the simulation.
One possible solution for this issue would be the units overhaul we're planning. If all fields are associated with a unit object, we can simply query the units to ensure that units are taken care of correctly and code-to-code comparisons aren't sensitive to the units chosen for fields in the frontend.
Personally, I think it would be best if we could make sure that all of the fields aliased to Enzo fields have the same units.
Nathan Goldbaum Graduate Student Astronomy& Astrophysics, UCSC
goldbaum@ucolick.org http://www.ucolick.org/~**goldbaum <http://www.ucolick.org/~goldbaum>
______________________________**_________________ yt-dev mailing list yt-dev@lists.spacepope.org http://lists.spacepope.org/**listinfo.cgi/yt-dev-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<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<http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org>
!DSPAM:10175,**4f74e5073356450621218!
______________________________**_________________
yt-dev mailing list yt-dev@lists.spacepope.org http://lists.spacepope.org/**listinfo.cgi/yt-dev-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<http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org>
participants (5)
-
Cameron Hummels -
Casey W. Stark -
j s oishi -
Matthew Turk -
Nathan Goldbaum