Here is a possible generic way to handle redshifts in model components. Allow any component to have a "z" prepended to its name eg pow-> zpow. The model parser strips off the z while setting a has-redshift flag. Any model component with the has-redshift flag set gets a redshift parameter added (after all the other parameters and before any normalization). When evaluating the model the function is passed a redshifted energy array if has-redshift is set. The output flux array could also be corrected for the (1+z) normalization factors although we would have to be careful to make this consistent with the flux and luminosity commands.
The only type of model where this would not work is one which uses the redshift for something in addition to the energy shift - I think the only such case is the cooling flow which needs the luminosity distance to convert the Mdot parameter to an amount of flux to add.
Thursday, October 30, 2008
Subscribe to:
Post Comments (Atom)
2 comments:
You could create a z model component which did this, e.g. z(pow+pow), perhaps automatically converting zpow->z(pow).
It wouldn't work for multiplicative models unless you allow for syntax such as (z(wabs))(pow) and allowed the model to switch between these cases.
I was thinking earlier of writing a redshift mixing model but the idea in this post was just to write zpow and have xspec interpret that as pow with a redshift added.
The new xspec will actually support mixing models applied to multiplicative models so your example (z(wabs))(pow) will work.
Post a Comment