[yt-dev] Fwd: [astropy-dev] Adding optional information to models

[Matthew Turk]

This thread on astropy-dev might be of interest to people here,
particularly those of you working on simulated observations.


---------- Forwarded message ----------
From: Perry Greenfield <stsci.perry at gmail.com>
Date: Fri, Mar 7, 2014 at 11:31 AM
Subject: [astropy-dev] Adding optional information to models
To: astropy-dev at googlegroups.com



We've been looking how to merge the capabilities of models with the
spectral objects we've been using for pysynphot (a topic that will be
raised in a separate thread) and one of the issues that has surfaced
has been how do we handle the "waveset" info we have some of our
current analytic models in pysynphot.

To explain a bit, the analytic models have a method, that returns a
set of input values that is judged to sample the feature reasonably
well. The purpose of this is that when one is combining such models
and then binning, integrating, or plotting them later, it is possible
to lose fine structure in any random sampling scheme. A classic
example is for a Gaussian. If the Gaussian has a small sigma such that
if it is evaluated on a regular grid or some other source of points to
sample, it may not appear in an integration or plot of the result if
its main structure falls in between those samples.

Pysynphot gets around this by making a union of all wavelength samples
present in all tabular data. But analytic components don't have a
wavetable by default since they can be evaluated at any wavelength.
Still, it is useful for them to have some equivalent to that so that a
feature like a Gaussian isn't missed in the other existing wavelength
tables. So we added an optional waveset to analytic models that had
features that might be missed. For a Gaussian, that means giving a set
of points that sample the peak reasonably well (what is "reasonable"
is of course a somewhat murky concept). Perhaps it could be called the
sampleset.

In our reworking of pysynphot, the design under consideration would
need this info in the model itself. So we want to consider an
attribute for models that provide a set of samples to cover such a
need. If the analytic model doesn't need it (e.g., a power law), it
can default to be an empty array. When models are combined (e.g.,
adding two different Gaussians), the resulting sample set would be the
union of the two input models (this is a recursive model). For
pysynphot, this union was computed recursively on the fly when
requested, though a more static approach could be used as well, or
some caching scheme.

People that wanted to add a new model wouldn't have to handle this if
it wasn't needed for their use. But for some kinds of models, it can
be quite useful for the same purposes (binning, integration, or
plotting).

For 1-d models, it is a very straightforward thing to implement. For
2-d and higher dimensions, there are a few alternatives for saving the
info (gridded vs ungridded?).

Any reason we shouldn't add this capability to models?

Perry

--
You received this message because you are subscribed to the Google
Groups "astropy-dev" group.
To unsubscribe from this group and stop receiving emails from it, send
an email to astropy-dev+unsubscribe at googlegroups.com.
For more options, visit https://groups.google.com/d/optout.