<div dir="ltr">Yes, I think it would be impossible or at least very hard to support that in general.<div><br></div><div>In the current system, the user can specify the field units in the add_enzo_field call (for example). Right now a user can do that in a plugin file or the top of a script. Would something similar be possible in the new system?</div>
</div><div class="gmail_extra"><br><br><div class="gmail_quote">On Thu, Jan 23, 2014 at 2:23 PM, Matthew Turk <span dir="ltr"><<a href="mailto:matthewturk@gmail.com" target="_blank">matthewturk@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">On Thu, Jan 23, 2014 at 5:13 PM, Nathan Goldbaum <<a href="mailto:nathan12343@gmail.com">nathan12343@gmail.com</a>> wrote:<br>
> I think I have a use case that this design might make more difficult.<br>
><br>
> Let's say I'm adding new fields to an existing code for some reason (like<br>
> radiation, chemistry, or MHD). I'd like to make it so users can read in my<br>
> fields with yt and then make derived fields of their own using my fields.<br>
<br>
</div>Yes, that's an ideal use case we need to support.<br>
<div class="im"><br>
><br>
> Under your proposal, would I need to modify the yt source to be able to read<br>
> the fields in properly and assign them units? If so, that seems a bit<br>
> awkward to me since there would need to be upstream changes to yt that only<br>
> make sense relative to someone's private fork of a hydro code.<br>
<br>
</div>Hmm, reading in units for a field that yt does not know about, that is<br>
actually an outstanding problem with units that predates my changes to<br>
the field system. I don't know what to do about it.<br>
<div class="HOEnZb"><div class="h5"><br>
><br>
><br>
> On Thu, Jan 23, 2014 at 1:34 PM, Matthew Turk <<a href="mailto:matthewturk@gmail.com">matthewturk@gmail.com</a>> wrote:<br>
>><br>
>> Hi all,<br>
>><br>
>> The method for adding derived fields has somewhat changed in the<br>
>> unitrefactor of 3.0, and we have the opportunity to make it a bit<br>
>> easier to add new fields -- especially after a parameter file has been<br>
>> created, which previously has been a pain. Below is a brief summary.<br>
>><br>
>> The current way we do this is with:<br>
>><br>
>> add_field(...)<br>
>><br>
>> or<br>
>><br>
>> @derived_field<br>
>> def some_function(...<br>
>><br>
>> The field system is now plugin based, which means we load plugins for<br>
>> different things and fields are dynamically added. One big advantage<br>
>> is that logic for things like strides and whatnot doesn't need to<br>
>> happen inside the field functions, but it also provides some<br>
>> compartmentalization of things.<br>
>><br>
>> I haven't implemented @derived_field and add_field yet in this system,<br>
>> but my plan is to do so by creating a "custom" plugin, to which these<br>
>> will add field definitions, which will always get loaded. But if you<br>
>> do:<br>
>><br>
>> pf = ...<br>
>> pf.h.whatever...<br>
>><br>
>> @derived_field<br>
>> def func(...)...<br>
>><br>
>> currently, and in the proposed implementation, this will not let them<br>
>> be detected. But I want to make it so that we *can* do this:<br>
>><br>
>> pf.add_field( ... ) and @pf.derived_field, which will both dynamically<br>
>> add fields to existing parameter files. What this means:<br>
>><br>
>> * This will not change behavior of @derived_field and add_field, in<br>
>> that they only apply to pfs instantiated *after* the call happens.<br>
>> * There will be a way to dynamically add fields, with field<br>
>> dependencies and all, by using pf attributes.<br>
>> * Adding fields *specific to an output type* will no longer be<br>
>> possible outside of field plugins. This means there will be the<br>
>> ability to add pf-specific and universal fields dynamically in a<br>
>> script, but all fields that are specific to an output type will need<br>
>> to be added in the fields.py file for that frontend. So this means<br>
>> that anything you might have used add_enzo_field or add_orion_field on<br>
>> *in your scripts* (not in anything inside yt/frontends/*/fields.py)<br>
>> will no longer work.<br>
>><br>
>> I'm going to be implementing the uncontroversial part of this, which<br>
>> is the dynamic field adding to a "custom" plugin, and unless I hear<br>
>> otherwise I'll continue on this track with the dynamic pf field<br>
>> addition.<br>
>><br>
>> -Matt<br>
>> _______________________________________________<br>
>> yt-dev mailing list<br>
>> <a href="mailto:yt-dev@lists.spacepope.org">yt-dev@lists.spacepope.org</a><br>
>> <a href="http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org" target="_blank">http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org</a><br>
><br>
><br>
><br>
> _______________________________________________<br>
> yt-dev mailing list<br>
> <a href="mailto:yt-dev@lists.spacepope.org">yt-dev@lists.spacepope.org</a><br>
> <a href="http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org" target="_blank">http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org</a><br>
><br>
_______________________________________________<br>
yt-dev mailing list<br>
<a href="mailto:yt-dev@lists.spacepope.org">yt-dev@lists.spacepope.org</a><br>
<a href="http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org" target="_blank">http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org</a><br>
</div></div></blockquote></div><br></div>