Hi,
How one gets a reference to the effective "function" of a derived field at run time? I wish to know how the derived fields I use are calculated. Thus I need the source code either as a string or a source file/line number.
Thanks, --Boyan Hristov
Hi Boyan,
You can call "get_source" on a derived field object. For example, I just loaded up a test dataset and did:
print ds.fields.gas.velocity_magnitude.get_source()
def _magnitude(field, data): fn = field_components[0] mag = data[fn] * data[fn] for idim in range(1, registry.ds.dimensionality): fn = field_components[idim] mag += data[fn] * data[fn] return np.sqrt(mag)
On Sun, Apr 10, 2016 at 9:48 AM, bh11e bh11e@my.fsu.edu wrote:
Hi,
How one gets a reference to the effective "function" of a derived field at run time? I wish to know how the derived fields I use are calculated. Thus I need the source code either as a string or a source file/line number.
Thanks, --Boyan Hristov _______________________________________________ yt-users mailing list yt-users@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-users-spacepope.org
Hi,
I'm creating 1D profiles with as much bins as the top grid zones along the same axis:
ProfilePlot( ds.all_data(), 'z', field_name, weight_field=weight_field_name, x_log=False, y_log={field_name:False}, n_bins=ds.domain_dimensions[2] )
i.e. each bin should include a 1-zone thick slice of the top grid. All profiles created this way end up with the first and the last bins equal to zero. Am I not doing something wrong? Or is it because the bins' boundaries are created to be centered on the grid zones, This way the end grid zones fall on a bin boundary and are being filtered by the following lines :
profiles.py: class ProfileND: ... def _filter(self, bin_fields): ... for (mi, ma), data in zip(self.bounds, bin_fields): filter &= (data > mi) filter &= (data < ma) ...
The rightmost zone seems to be filtered out a second time by the np.digitize call in the following code:
profiles.py: class Profile1D: .... def _bin_chunk(self, chunk, fields, storage): ... bin_ind = np.digitize(bf_x, self.x_bins) - 1 ...
Above the 'right' argument to digitize is not being set and defaults to False (see: http://docs.scipy.org/doc/numpy-1.10.0/reference/generated/numpy.digitize.ht...)
My solution was to modify the "mi" and "ma" values (in the first code snippet) to match the grid left and right edges but that of course is a workaround only for this particular case. Any thoughts?
Thanks, --Boyan Hristov
On Sun, Apr 17, 2016 at 5:47 PM, bh11e bh11e@my.fsu.edu wrote:
Hi,
I'm creating 1D profiles with as much bins as the top grid zones along the same axis:
ProfilePlot( ds.all_data(), 'z', field_name, weight_field=weight_field_name, x_log=False, y_log={field_name:False}, n_bins=ds.domain_dimensions[2] )
i.e. each bin should include a 1-zone thick slice of the top grid. All profiles created this way end up with the first and the last bins equal to zero. Am I not doing something wrong? Or is it because the bins' boundaries are created to be centered on the grid zones, This way the end grid zones fall on a bin boundary and are being filtered by the following lines :
profiles.py: class ProfileND: ... def _filter(self, bin_fields): ... for (mi, ma), data in zip(self.bounds, bin_fields): filter &= (data > mi) filter &= (data < ma) ...
The rightmost zone seems to be filtered out a second time by the np.digitize call in the following code:
profiles.py: class Profile1D: .... def _bin_chunk(self, chunk, fields, storage): ... bin_ind = np.digitize(bf_x, self.x_bins) - 1 ...
Above the 'right' argument to digitize is not being set and defaults to False (see: http://docs.scipy.org/doc/numpy-1.10.0/reference/generated/numpy.digitize.ht... )
My solution was to modify the "mi" and "ma" values (in the first code snippet) to match the grid left and right edges but that of course is a workaround only for this particular case. Any thoughts?
Thanks, --Boyan Hristov
Hi Boyan,
Thanks for tracking down in the yt codebase where this is happening. Would you be interested in submitting a pull request to fix this issue? I'd be happy to share more information about contributing, but you can also look at the developer guide:
http://yt-project.org/docs/dev/developing/developing.html#how-to-develop-yt
While this is probably a behavior change, I think it might be a worthwhile one. Submitting a pull request will at least allow us to see what tests fail (if any) and evaluate the potential impact.
-Nathan
yt-users mailing list yt-users@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-users-spacepope.org
-
bh11e -
Matthew Turk -
Nathan Goldbaum