On Thu, Mar 28, 2013 at 4:18 PM, David Collins
I tried Nathan's suggestion, but I'm still getting fields in CGS. I did the following, and just ran it in a script (not messing with the plugins for now). Is there anything else I need to do? What I think is happening is that in D2, data['Density'] is already converted to cgs when it gets returned by D2. Is there an easy way to get the density conversion function that's getting used, so I can have the converter return the inverse? I added the ValidateGridType in order to try to force it to be read before the convert, that didn't work.
def D2(field,data): return data['Density'] def no_convert(data): return 1 add_field('D2',function=D2,convert_function=no_convert, validators=[ValidateGridType()])
Nathan's suggestion is a good one, as well. In principle I don't know why the conversion_factors option to the Enzo Static Output wouldn't work for this as well.
I dropped this method a while ago when other yt things started to break.
Break how?
I was doing something like this, but when I do it other things like "load" stop working. Even just creating this class, not actually doing anything with it, causes load to fail silently.
I suspect that what's happening is that it's probably reporting via the log (loglevel of error) that too many _is_valid routines succeeded, so it could not distinguish. Everything for Enzo is mediated by two functions: parse_parameter_file, which indirectly modifies conversion_factors when it stumbles across a Units entry in the parameter file (as long as it's not TemperatureUnits). This is overriden by conversion_override. However, note that this occurs *before* parsing the datalabels, which looks like an error to me, as that will then subsequently override conversion_factors again. Following this, _set_units is called. This will determine it's cosmological, and if so, call _setup_comoving_units. If the parameter LengthUnit is in the parameter file it calls _setup_getunits_units. If neither of those two things happens, it calls setup_nounits_units. This sets everything to 1.0, except for the length/time conversions, where everything is set to 1.0 cm == 1.0 in code units and 1.0 s == 1.0 in code units. So my guess is your dataset has a #CGSConversionFactor for Density.
class EnzoStaticOutputMHD(EnzoStaticOutput): def __init__(self,*args,**kwargs): Conversion=2.5e-9/4.32e-7 EnzoStaticOutput.__init__(self,*args,conversion_override={
'MagneticField_C_1': Conversion,
'MagneticField_C_2': Conversion,
'MagneticField_C_3': Conversion,
'MagneticField_F_1': Conversion,
'MagneticField_F_3': Conversion,
'MagneticField_F_2': Conversion}, **kwargs)
If we had your subclass or some type of test incorporated into yt, we would be able to verify that this functionality that you rely on continues to work. It can be difficult to anticipate all use cases for the code, but this seems like one that could be valuable.
On Thu, Mar 28, 2013 at 3:21 PM, Nathan Goldbaum
wrote: Hi David,
Another option would be to temporarily define a new field that has a null or trivial conversion function.
This field could live in your ~/.yt/my_plugins.py file so no need to touch the yt codebase.
-Nathan
On Mar 28, 2013, at 12:18 PM, David Collins
wrote: That reads a single grid from the hierarchy? Can I get yt to do projections and whatnot in those units?
Previously I had subclassed EnzoStaticOutput with customized conversion factors. It's a bit outdated.
Thanks! d.
On Thu, Mar 28, 2013 at 1:09 PM, Matthew Turk
wrote: On Thu, Mar 28, 2013 at 3:07 PM, David Collins
wrote: Hi!
Is there a way to get yt to not convert data to CGS? I'm doing some debugging, and its easier to see the code units.
Read the data directly.
pf.h.io._read_data_set(grid, field)
I had a work around for this a while ago, but there has been a bunch of code development since then.
What was your old way?
Thanks! d.
_______________________________________________ yt-users mailing list yt-users@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-users-spacepope.org
_______________________________________________ yt-users mailing list yt-users@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-users-spacepope.org
_______________________________________________ yt-users mailing list yt-users@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-users-spacepope.org
_______________________________________________ yt-users mailing list yt-users@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-users-spacepope.org
_______________________________________________ yt-users mailing list yt-users@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-users-spacepope.org
-- Sent from my computer. _______________________________________________ yt-users mailing list yt-users@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-users-spacepope.org