On 11/24/2015 03:51 PM, Nathan Goldbaum wrote:
On Tuesday, November 24, 2015, Kacper Kowalik <xarthisius.kk@gmail.com> wrote:
On 11/24/2015 12:33 PM, Cameron Hummels wrote:
On Tue, Nov 24, 2015 at 9:10 AM, Kacper Kowalik <xarthisius.kk@gmail.com <javascript:;>> wrote:
I'd be strongly -1 on "force_units". In that scenario you invoke several costly calls to sympy just to disregard the result. IMO you should drop units at the very beginning and create YTArray during return in the derived field's definition.
By this you mean something like:
def _temperature(field, data): tr = array_of_wrong_units data.apply_units(tr, 'K') return tr
ds.add_field('temperature', function=_temperature, units='K')
Nope, if you change units of the array that's cheap (I think), but when you do:
def _temp(field, data): temp = data["foo"] * constant1 * constant2 return temp
only to disregard units, that's a huge waste of cycles.
If the constants here don't have units, there isn't any overhead, which I think is what Elizabeth was doing in her original email.
I meant that in general, I wasn't referring to Elizabeth's particular example. On the other hand: $ cat foo.py import yt import numpy as np c1 = 1.0 c2 = 1.0 tab = yt.YTArray(np.arange(100), '') def foo1(data, constant1, constant2): temp = data * constant1 * constant2 return temp def foo2(data, constant1, constant2): temp = data.d * constant1 * constant2 return yt.YTArray(temp, '') if __name__ == '__main__': import timeit print(timeit.timeit("foo1(tab,c1,c2)", setup="from __main__ import c1,c2,tab,foo1", number=10000)) print(timeit.timeit("foo2(tab,c1,c2)", setup="from __main__ import c1,c2,tab,foo2", number=10000)) Says that foo1() is 2 times slower than foo2() Cheers, Kacper
Cheers, Kacper
?
Or is the syntax wrong here? I'm not really sure how to use this.
Cheers, Kacper
On Tue, Nov 24, 2015 at 7:32 AM, Matthew Turk <matthewturk@gmail.com <javascript:;>> wrote:
If absolutely necessary, you can "force" units with:
data.apply_units(array_to_override, unit_string)
On Tue, Nov 24, 2015 at 9:31 AM, Cameron Hummels <chummels@gmail.com <javascript:;>> wrote: > I would be a fan of making a "force_units" kwarg to enable one to create a > new field with different units than those specified. This could resolve > some of the problems with native frontend fields being stuck in the wrong > unit, like I was running into last week. As long as force_unit is off by > default, it would just enable us to give full control to the user. > > On Tue, Nov 24, 2015 at 4:25 AM, Nathan Goldbaum < nathan12343@gmail.com <javascript:;>> > wrote: >> >> Hi Elizabeth, >> >> This is discussed in the docs here: >> >> >>
>> >> You can do one of two things. First, the way I'd handle this is to ensure >> that your field definition is returning data that have units of Kelvin. >> >> For example, something like: >> >> from yt.utilities.physical_constants import kb, mh >> >> mu = 0.6 >> >> @derived_field(name=‘Temp’, units=“K”) >> def _Temp(field, data): >> return data['thermal_energy'] / kb * mu * mh >> >> You could also make mu a field parameter rather than a constant, or if you >> have a simulation where mu varies with position, make a mean molecular >> weight derived field. >> >> You can also ensure that your field definition returning a dimensionless >> value by stripping the units: >> >> @derived_field(name=‘Temp’, units=“K”) >> def _Temp(field, data): >> ret = data['thermal_energy']) >> return ret.ndarray_view() >> >> We don't currently have a way to *force* the units to be whatever you >> specify in add_field. That said, I don't think it would be terribly hard to >> implement. >> >> We already have units='auto', which forces the units to be the same as the >> return value of your field function. We might add a keyword >> 'force_units=True' to add_field which does what you're looking for. I'd be >> happy to review a pull request adding this, or feel free to open an issue >> about it to add to our project backlog. >> >> Also, worth pointing out that this was designed this way not to anger >> users, but to protect them from making mistakes in their field units, which >> we found to be a common cause of bugs in yt-2. It does mean you need to "buy >> into" the unit system in your field definition, but the bonus is
http://yt-project.org/doc/developing/creating_derived_fields.html#defining-a... that
you >> can be much more sure that you're not making a mistake. >> >> Hope that helps, >> >> Nathan >> >> On Tue, Nov 24, 2015 at 12:41 AM, Elizabeth Tasker >> <tasker@astro1.sci.hokudai.ac.jp <javascript:;>> wrote: >>> >>> Hi everyone, >>> >>> While using yt-3, I created a derived field: >>> >>> @derived_field(name=‘Temp’, units=“K”) >>> def _Temp ….. >>> >>> It crashes with a YTFieldUnitError because it believes the units should >>> be cm**2/s**2. I understand why yt thinks this — I’m using thermal_energy in >>> the definition for Temp. However, the units are truly Kelvin and I think I >>> should be able to specify whatever I like in “units”! >>> >>> Is there a way to stop yt crashing when it disagrees with your life >>> choices? >>> >>> Elizabeth >>> _______________________________________________ >>> yt-users mailing list >>> yt-users@lists.spacepope.org <javascript:;> >>> http://lists.spacepope.org/listinfo.cgi/yt-users-spacepope.org >> >> >> >> _______________________________________________ >> yt-users mailing list >> yt-users@lists.spacepope.org <javascript:;> >> http://lists.spacepope.org/listinfo.cgi/yt-users-spacepope.org >> > > > > -- > Cameron Hummels > NSF Postdoctoral Fellow > Department of Astronomy > California Institute of Technology > http://chummels.org > > _______________________________________________ > yt-users mailing list > yt-users@lists.spacepope.org <javascript:;> > http://lists.spacepope.org/listinfo.cgi/yt-users-spacepope.org > _______________________________________________ yt-users mailing list yt-users@lists.spacepope.org <javascript:;> http://lists.spacepope.org/listinfo.cgi/yt-users-spacepope.org
_______________________________________________ yt-users mailing list yt-users@lists.spacepope.org <javascript:;> http://lists.spacepope.org/listinfo.cgi/yt-users-spacepope.org
_______________________________________________ yt-users mailing list yt-users@lists.spacepope.org <javascript:;> http://lists.spacepope.org/listinfo.cgi/yt-users-spacepope.org
_______________________________________________ yt-users mailing list yt-users@lists.spacepope.org <javascript:;> 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