Come analyze HEASARC, IRSA, and MAST data in the cloud! The Fornax Initiative is now welcoming all interested beta users.
Next: bbody, zbbody: blackbody Up: Additive Model Components Previous: apec, vapec, vvapec, bapec, Contents
atable: tabulated additive model
An additive table model component. The filename to be used must be given immediately after atable in the model command. For example:
XSPEC> model atable{mymod.mod}
uses mymod.mod as the input for the model. For specifications of the table model file, see the OGIP memo 92-009 on the FITS file format for table model files (available at https://heasarc.gsfc.nasa.gov/docs/heasarc/ofwg/docs/summary/ogip_92_009_summary.html. Example additive table model files are mekal.mod and raysmith.mod in $HEADAS/../spectral/modelData and testpo.mod in $HEADAS/../spectral/session.
Any number of tabulated model components (additive, multiplicative or exponential) may be used simultaneously.
The model value is assumed zero outside the tabulated energies unless the keywords LOELIMIT and HIELIMIT are given in the primary extension of the FITS file. In the latter case the value given in LOELIMIT will be used for energies below those tabulated and HIELIMIT for energies above those tabulated.
A table model file may also provide a neural network (NN) emulation of the tabulated spectra in place of the usual multi-linear interpolation on the parameter grid. This is indicated by the NNPTFILE keyword in the primary extension of the FITS file, which gives the name of a PyTorch (.pt) weights file. When such a file is loaded XSPEC automatically evaluates the model with the neural network — no special command or model type is required, the same atable is used. This requires XSPEC to have been built with libtorch support (the –with-libtorch configure option); without it an NN table model cannot be evaluated.
The network is a TorchScript module (saved with torch.jit.save) that XSPEC loads with libtorch and evaluates directly, so it must be trained and exported to follow the conventions XSPEC assumes:
- Inputs. The network takes a single
tensor
whose 
entries are the interpolation parameters (those not flagged as
“additional”), in the order they appear in the PARAMETERS extension of
the table file. Each parameter is normalized to the range ![$[0,1]$](img75.svg)
as
, where
and
are that parameter's minimum and
maximum values stored in the table file (the ends of the range over
which the model is defined). The training script must apply exactly the
same normalization. Parameter values are accepted only within
![$[\theta_{\min},\theta_{\max}]$](img262.svg)
; a request outside that range is
rejected, so the network is never asked to extrapolate beyond its
training limits.
- Outputs. The network returns a one-dimensional tensor of
values, one per energy bin; XSPEC raises ten
to each to recover the flux. The number of outputs is the number of
bins on the energy grid stored in the ENERGIES extension of the table
file (the number of tabulated energy boundaries minus one), and the
network must be trained to reproduce the model on that same grid.
Storing
rather than the flux itself keeps the
dynamic range manageable for the network.
- Frame. The network is trained on the rest-frame model on
the unscaled energy grid. A redshift parameter and an energy-scaling
(escale) parameter, if the model has them, are applied by XSPEC to the
network output and to the energy grid respectively — they are not seen
by the network.
The parameter definitions (names, initial values, hard and soft limits, and the minimum/maximum used for the normalization above) are still read from the PARAMETERS extension exactly as for an interpolated table, and the energy grid is still read from the ENERGIES extension, so an NN table file remains a valid OGIP table model file that simply carries the NNPTFILE keyword and weights file in addition.
Next: bbody, zbbody: blackbody Up: Additive Model Components Previous: apec, vapec, vvapec, bapec, Contents