[yt-users] non-converted fields?

David Collins dcollins4096 at gmail.com
Thu Mar 28 13:33:23 PDT 2013


Ah, the conversion factors change with time, so that "inverse conversion
factor" idea won't work.   Is there a way to get to the grid, through
add_field, before the convsersion is applied?


On Thu, Mar 28, 2013 at 2:24 PM, Nathan Goldbaum <nathan12343 at gmail.com>wrote:

> Hi Dave,
>
> You can see the conversion factors yt applies by inspecting
> pf.conversion_factors.
>
> -Nathan
>
> On Mar 28, 2013, at 1:18 PM, David Collins <dcollins at physics.ucsd.edu>
> wrote:
>
> > 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.  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.
> >
> > 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 <nathan12343 at gmail.com>
> 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 <dcollins4096 at gmail.com>
> 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 <matthewturk at gmail.com>
> wrote:
> >>>>
> >>>> On Thu, Mar 28, 2013 at 3:07 PM, David Collins <
> dcollins4096 at gmail.com>
> >>>> 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 at lists.spacepope.org
> >>>>> http://lists.spacepope.org/listinfo.cgi/yt-users-spacepope.org
> >>>>>
> >>>> _______________________________________________
> >>>> yt-users mailing list
> >>>> yt-users at lists.spacepope.org
> >>>> http://lists.spacepope.org/listinfo.cgi/yt-users-spacepope.org
> >>>
> >>>
> >>> _______________________________________________
> >>> yt-users mailing list
> >>> yt-users at lists.spacepope.org
> >>> http://lists.spacepope.org/listinfo.cgi/yt-users-spacepope.org
> >>>
> >>>
> >>>
> >>> _______________________________________________
> >>> yt-users mailing list
> >>> yt-users at lists.spacepope.org
> >>> http://lists.spacepope.org/listinfo.cgi/yt-users-spacepope.org
> >>>
> >> _______________________________________________
> >> yt-users mailing list
> >> yt-users at lists.spacepope.org
> >> http://lists.spacepope.org/listinfo.cgi/yt-users-spacepope.org
> >
> >
> >
> > --
> > Sent from my computer.
> > _______________________________________________
> > yt-users mailing list
> > yt-users at lists.spacepope.org
> > http://lists.spacepope.org/listinfo.cgi/yt-users-spacepope.org
>
> _______________________________________________
> yt-users mailing list
> yt-users at lists.spacepope.org
> http://lists.spacepope.org/listinfo.cgi/yt-users-spacepope.org
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.spacepope.org/pipermail/yt-users-spacepope.org/attachments/20130328/e57ab631/attachment.html>


More information about the yt-users mailing list