Shell variables can be set depending on your shell. In bash, for WFI simulations:

export XMLDIR=$SIXTE/share/sixte/instruments/athena-wfi/wfi_wo_filter/

The examples in this repository usually use SIXTE_INSTRUMENTS as the root directory for instrument files. setup.sh then sets INSTRUMENT_PATH to the relevant instrument subdirectory and XML to the specific XML file used for the simulation.

You can try to follow the instructions here: https://heasarc.gsfc.nasa.gov/docs/software/lheasoft/docker.html .

For a quick check, use command-line tools such as fstruct or fdump.

Most examples use the SIXTE_INSTRUMENTS environment variable as the root directory for instrument files.

In setup.sh, INSTRUMENT_PATH is set to the relevant subdirectory, and XML points to the specific XML file used for the simulation.

To change the setup, adjust INSTRUMENT_PATH if you want to use a different instrument file directory, and adjust XML if you only want to switch to another XML file in the same directory.

Alternatively, you can pass the desired XML file directly to sixtesim:

XMLFile=/path/to/instrument.xml

When changing the XML, also check how many event files the detector setup will produce. For example, switching WFI from the single-chip setup to ld_wfi_ff_all_chips.xml uses the full four-chip geometry.

In that case, sixtesim writes one event file per chip. With Prefix=sim_ and EvtFile=evt.fits, the output files are:

sim_chip0_evt.fits
sim_chip1_evt.fits
sim_chip2_evt.fits
sim_chip3_evt.fits

These files can then be merged for later analysis.

There are currently no plans to implement Einstein Probe from our side. We are not part of the Einstein Probe consortium.

The simulator at https://epfxt.ihep.ac.cn/simulation uses SIXTE in the background. However, we do not have detailed information about how the setup, XML files, and related configuration are implemented.

For the SIMPUT file, RA and Dec define the source position on the sky. Therefore, RA=Dec=0 places the source at those coordinates.

For the simulation, RA and Dec specify the telescope pointing. If the SIMPUT file does not contain a source in the pointing direction, no flux will be measured.

It depends. SIXTE does not simulate extinction and astrophysical background by itself. You need to define these effects as part of your SIMPUT file.

We are working on putting the eROSITA sources in a single SIMPUT file, which you will then be able to add to a simulation. That will take a little while, though.

There are large AGN catalogues available at http://www.bo.astro.it/~gilli/mock.html. If the X-ray background matters to you, you may want to put your source in the area covered by these catalogues.

No. Emin and Emax set the energy band in which the flux is defined.

Elow and Eup are somewhat instrument-dependent, because they give the energy range over which the source spectrum is defined. If Elow to Eup does not completely cover the instrument energy range, SIXTE will throw a warning.

Yes. More precisely, the SRC_CAT extension inside the SIMPUT FITS file is the source catalog.

The whole .fits or .simput file is commonly referred to as the SIMPUT source catalog.

Yes, in the band defined by Emin and Emax.

The total normalization of the XSPEC spectrum is overridden, while the relative normalizations of multiple components are preserved.

If you provide an XSPEC file and no srcFlux, simputfile tries to calculate the source flux for you in the given flux band. However, we recommend always setting srcFlux manually to make sure the correct flux is simulated.

Not necessarily. The energy band of the simulation is whatever the mission can do.

The SIMPUT file should cover this instrument range. It does not hurt to have broader coverage.

Yes. See the extended_sources/mixing example.

In particular, 02_build_simputs creates two extended SIMPUTs with different spectra, and 03_run_sim passes both files to sixtesim as a comma-separated Simput list.

Yes. For a small number of spatially varying spectral parameters, simputmultispec is the relevant approach.

See: extended_sources/multispec.

For many free spectral parameters, simputmultispec becomes cumbersome, so photon-list SIMPUTs or 3D grids can be more suitable.

See: extended_sources/photon_lists and extended_sources/data_cube.

Yes. This is demonstrated in extended_sources/data_cube, for example with a cube of RA, Dec, and Energy.

SIXTE does not read pyXSIM HDF5 photon or event-list files directly. The robust interface is a SIMPUT source catalog.

The direct pyXSIM workflow is to first project the 3D photon list to the desired line of sight:

pyxsim.project_photons(...)

Then load the projected event list as an EventList and export it to SIMPUT:

write_to_simput(...)

Pass the resulting SIMPUT catalog file to SIXTE:

Simput=...

SOXS can also be used to construct photon-list SIMPUT catalogs directly. See extended_sources/photon_lists, especially create_photlist_simput.py and 02_run_xifu.

By adding many background AGN, clusters, and similar sources to your SIMPUT file.

A set of background SIMPUTs has been created by Marchesi et al. here: http://www.bo.astro.it/~gilli/mock.html.

It is the length of the generated light curves in seconds. A shorter value covers only part of the values in example_lightcurve.dat.

This is the flux as a fraction of the value given in the FLUX column of the source.

The warning is given if the spectrum in the SIMPUT file has an energy range, given by Elow and Eup, that does not contain the nominal energy range of the instrument.

*** The spectrum 'mcrab.fits[SPECTRUM,1]' does not cover the full energy range of the ARF! ***

For some examples, the single-chip setup is used. In this setup, one chip is centered on the optical axis.

This is useful for quick tests or compact-source simulations where the full four-chip geometry and chip gaps are not relevant for the analysis.

They are based on the mirror PSFs, but sensor effects are taken into account in the simulation.

The simulation is done with the full PSF resolution. One can output an impact file containing the locations where photons hit the chip. When reconstructing images, the position is spread over the pixel where the charge was registered.

Providing a custom PSF is possible. More information is given in Section 4.1 on PSF randomization and Appendix C.1 on telescope XML configuration in the manual.

The provided PSFs are used to trace photons from the sky and map them onto the detector. Afterwards, detector effects are applied.

The physics of bright-source events in WFI is different from that in X-IFU.

In WFI, bright sources are mainly affected by pile-up, as shown in: bright_sources/pileup.

Crosstalk is not really an issue for WFI.

xifupipeline is deprecated. It was used before sixtesim was created.

sixtesim can now simulate all instruments supported by SIXTE. The same applies to tools such as erosim and athenawfisim.

Yes. They are already merged.

Have a look at the PH_ID column, which should have two entries for this event. This column contains the unique IDs of the photons that were merged into the event.

Whenever you are not pointing at RA=Dec=0.

Essentially, CRVAL1 defines the sky coordinate corresponding to the pixel value CRPIX1. The same applies to CRVAL2 and CRPIX2.

EventFilter is a filtering expression using the FITS extended filename syntax.

It is described in more detail in the manual and by:

fhelp rowfilter
fhelp colfilter

Yes. There is a regfile option that takes the path to a region file.

To use region files, you first need to define a WCS in the event file. This can be done with the radec2xy tool.

An example is given in extended_sources/simple_extsource/02_run_sim, which adds WCS coordinates with radec2xy.

Another example is extended_sources/simple_extsource/04_extract_spec, which uses:

regfile=input/${reg}.reg

No. The SIMPUT light curve changes the source photon rate itself.

The light curve extracted with makelc contains the simulated source variability plus counting statistics, detector effects, optional background, and any other sources included in the selected event region.

All variable sources in your catalog should be simulated at the same time.

If your extraction region contains flux from any variable or non-variable source, you would see it in your light curve.

SIXTE traces the origin of each photon, and this is collected in the SRC_ID column in the event list. This means you can check the contribution from other sources by selecting all photons in the source region and counting how many come from a source with a SRC_ID different from yours.

Yes. See the regfile option, which exists in makespec, makelc, and other tools.

You also need a WCS system defined in the event file. You can use the radec2xy tool for this.

An example is given in extended_sources/simple_extsource/02_run_sim, which adds WCS coordinates with radec2xy.

Another example is extended_sources/simple_extsource/04_extract_spec, which uses:

regfile=input/${reg}.reg

No. The ARF generation does not consider this effect. This is believed to also be the case for real XRISM data, where the general approach is very similar.

You can estimate the recovered flux using quantities such as the GRADING columns or the NGRAD1 and related header keywords.

No. We currently do not perform RMF generation.

To account for grading effects, you could in principle extract one spectrum per grade and fit them simultaneously, although you would need to take care of normalizations.

Crosstalk is best handled through the choice of observation strategy and filtering.