Model: lochhonest/finetuned_mbert
Author: lochhonest
Pipeline: sentence-similarity
Library: sentence-transformers
Tags: sentence-transformers, safetensors, modernbert, sentence-similarity, feature-extraction, generated_from_trainer, dataset_size:3625, loss:CachedMultipleNegativesRankingLoss, arxiv:1908.10084, arxiv:2101.06983, base_model:nomic-ai/modernbert-embed-base, base_model:finetune:nomic-ai/modernbert-embed-base, text-embeddings-inference, endpoints_compatible, region:us
Base models (finetune): id: nomic-ai/modernbert-embed-base
Card metadata: tags: sentence-transformers, sentence-similarity, feature-extraction, generated_from_trainer, dataset_size:3625, loss:CachedMultipleNegativesRankingLoss
base_model: nomic-ai/modernbert-embed-base
widget: source_sentence: What is the purpose of the analysis steps outlined in the document?
sentences: Structure of the document

The structure of the present document is as follows:

-   Chapter [sasguide:par:analysis] introduces the investigator to the
    analysis of XMM-Newton
    (http://www.cosmos.esa.int/web/xmm-newton/technical-details) data.
    It provides a brief description of XMM-Newton
    (http://www.cosmos.esa.int/web/xmm-newton/technical-details)
    observation and calibration files and outlines the analysis steps
    required to produce calibrated event files and to extract scientific
    products.

-   Chapter [sasguide:par:gui] describes the SAS graphical user
    interface (GUI), a user friendly tool which enables SAS interactive
    analysis tasks to be run without using the command line.

-   Chapters [sasguide:par:epic], [sasguide:par:rgs] and
    [sasguide:par:om] describe the SAS analysis steps required to obtain
    EPIC
    (http://www.cosmos.esa.int/web/xmm-newton/technical-details-epic),
    RGS (http://www.cosmos.esa.int/web/xmm-newton/technical-details-rgs)
    and OM
    (http://www.cosmos.esa.int/web/xmm-newton/technical-details-om) data
    products, respectively, which can be used afterwards by standard
    astronomical software packages.

-   Chapter [sasguide:xmmextractor] gives an overview of a SAS procedure
    to produce high-level science products for XMM-Newton
    (http://www.cosmos.esa.int/web/xmm-newton/technical-details) cameras
    from the raw, uncalibrated, data files contained in the Observation
    Data File (ODF). The procedure allows for some interactivity which
    lets the user take decisions concerning the analysis process.
, ommosaic
-   Whilst tests have so far shown that scattered-light features do not
    effect the cross-correlation algorithm, further testing is underway
    and the method should be used with caution.

-   Tests using the cross-algorithm on aspect-corrected sky-images have
    so-far shown the computed offsets to be small (less than 0.2
    pixels). If both the aspect-correction and the cross-correlation
    algorithm were perfect, they should be zero. However the error in
    the aspect-correction can be up to 1 arc sec, and further testing
    needs to be done to evaluate any differences.

-   It would be desireable to perform a further aspect correction on the
    sky-images- this would require either a new OM task or, possibly, a
    modification to omsrclistcomb. Note that even if the sky-images have
    not been aspect-corrected, the coordinates of the sources in the
    observation source-list file may have.
, emchain
The chain will adapt to the evolution of its constituents and to the
organisation of the pipeline.

The current implementation is a Perl script.
, source_sentence: What is the purpose of transforming the sky coordinates?
sentences: PRODUCT: SSC logo 1 (SSCLG1) 

-   This file contains a schematic image of the XMM-Newton telescope
    front end

-   This is a product of class PPSOBS

-   The product is delivered in PNG format

-   There is one file per observation. File size is 3KB.
, dpsssrc
## Parameters

**set** (Mandatory): EPIC Maximum-Likelihood source list, identifier
TTTTTT = EMSRLI (Type: string, Default: P0123700101PNS003EMSRLI0000.FIT,
Range: applies only for EPIC Maximum-Likelihood detection lists)

**maxlikthresh** (Optional): threshold to set the source flag
‘source likelihood below a certain threshold (Type: real value, Default: 50., Range: must be greater than 0.)’ to T 
**prefix** (Optional): prefix for output name (‘prefix (Type: string,
Default: flag_, Range: applies only for EPIC Maximum-Likelihood
detection lists)_
[INPUT FILES]
dpsssrc
1.  POOOOOOOOOODDSEEEEMSRLISXXX.FIT EPIC Maximum-Likelihood detection
    source List. The identifier for TTTTTT must be equal to EMSRLI. The
    naming convention given above is according to and SSC-LUX-TN-0038.

[OUTPUT FILES]
dpsssrc
1.  flag_POOOOOOOOOODDSEEEEMSRLISXXX.FIT

    Copy of a EPIC Maximum-Likelihood detection list. Three new column
    are created and the source flag setting for sources below a certain
    detection threshold is performed.

[COMMENTS] dpsssrc
-   This task only applies for EPIC Maximum-Likelihood detection lists.
[CAL USAGE] dpsssrc, emosaicproc
The data preparation consists of:

-   transforming the sky coordinates by every event file corresponding
    to the different instruments and pointings to a common image centre,

-   extracting images per instrument, pointing and spectral selection,
    using common filtering and evtl. provided GTIs
, source_sentence: In pn imaging mode event lists, what is the type of the OFFSETX column?
sentences: Observation summary products
, -   The FITS format OM OSW images are rotated and rebinned to
    North-aligned sky coordinates.

-   The files are identified using the keyword

        CONTENT = 'OM OSW SKY IMAGE'  (SIMAGE)
        for default and User configurations
        or
        CONTENT = 'OM FULL-FRAME SKY IMAGE'  (FSIMAG)
        for low and high resolution full-frame configurations
        or
        CONTENT = 'OM FAST MODE OSW SKY IMAGE'  (SIMAGF)
        for FAST mode window

-   This is a product of class OMSW.

-   These images may be rectified against the USNO-B1 catalogue in which
    case keywords RA_OFF, DEC_OFF and POSCOROK are added to the header.

-   This product is used for comparison between optical and X-ray images
    (also in sky coordinates). It is used in the production of OM OSW
    PNG images.

-   There is one OM OSW FITS sky image for each OM OSW FITS image, and
    each file, on average, occupies ∼1.2MB uncompressed while the FAST
    mode image is typically 14KB uncompressed. For the full frame images
    the size is typically 22MB uncompressed.
, -   In pn event lists this extension contains the CCD columns to which
    an additional offset is applied to reduce noise (the offset is later
    subtracted again by the SAS). In the MOS event lists this extension
    currently defines columns outside the sensitive CCD window, to which
    formal very high values of the offset are associated. These columns
    are discarded by the data processing.

-   For MOS imaging mode event lists this extension contains the
    following columns:

      Name      Type             Description
      --------- ---------------- ----------------------------------------------------------
      RAWX      2-byte INTEGER   Row or column of the bad offset
      OFFSETX   2-byte INTEGER   amplitude of additional column offset (0 for row offset)
      OFFSETY   2-byte INTEGER   amplitude of additional row offset (0 for column offset)
      CCDNR     1-byte           CCD where the offset occurs

-   For MOS timing mode event lists this extension contains the
    following columns:

      Name      Type             Description
      --------- ---------------- ---------------------------------------
      RAWX      2-byte INTEGER   Row or column of the bad offset
      OFFSETX   2-byte INTEGER   amplitude of additional column offset
      CCDNR     1-byte           CCD where the offset occurs

-   For pn imaging mode event lists this extension contains the
    following columns:

      Name      Type             Description
      --------- ---------------- ---------------------------------------
      RAWX      2-byte INTEGER   Row of the bad offset
      OFFSETX   2-byte INTEGER   amplitude of additional column offset
      CCDNR     1-byte           CCD where the offset occurs

-   For pn timing mode event lists this extension contains the following
    columns:

      Name      Type             Description
      --------- ---------------- ---------------------------------------
      RAWX      2-byte INTEGER   Row of the bad offset
      OFFSETX   2-byte INTEGER   amplitude of additional column offset
      CCDNR     1-byte           CCD where the offset occurs

-   Note that currently, the offset table is always empty and only the
    CCDNR column is present and it is unfilled. This may change in the
    future.
, source_sentence: What is the minimal time resolution with which entries into the AHF can be made in case of instantaneous excursions in the stable pointing mode?
sentences: -   This extension is only present in pn event files. It gives the
    number of rejections of each column (discarded lines) of CCD nn over
    the course of the exposure.

-   There is one extension per CCD in the relevant mode (IMAGING or
    TIMING) during the exposure.

-   This extension contains the following columns:

      Name     Type             Description
      -------- ---------------- -----------------------------------------------
      DLIODF   4-byte INTEGER   Number of rejections by onboard MIP algorithm
      DLISAS   4-byte INTEGER   Number of subsequent rejections by the SAS

-   Each row corresponds to a column.
, Attitude & Orbit Control Subsystem (AOCS)

The AOCS determines the attitude of the  while in orbit, based on the
information from one of ’s two star trackers (which are operated in cold
redundancy) and its “Fine Sun Sensors”. During slews and the post-slew
phase (comprising attitude determination, trim, and settling of the
spacecraft), entries are made into the Attitude History File (AHF) every
10 seconds. Note that during slews the AHF will not contain attitudes
reconstructed from actual AOCS telemetry, but the results of a slew
time/path predictor, based on the actually observed slew start/end times
and attitudes. The accuracy of the attitude reconstruction during slews
is expected to be better than 1′.

In the “stable pointing mode” (i.e., after the slews and the post-slew
phase), the conditions under which entries into the AHF are made are
optimised parameters. An entry is made into the AHF only in case of
Relative Pointing Errors (RPEs) exceeding the programmed limit. The
minimal programmable limit (i.e., the smallest programmable deviation
from the nominal boresight) is 1″. The minimal time resolution with
which entries into the AHF can be made in case of such instantaneous
excursions is 2 seconds. For a single nominal pointing entry, only a
mean RPE will be provided.

The AOCS attitude information is independent of that from the OM
(http://www.cosmos.esa.int/web/xmm-newton/technical-details-om) ’s star
tracking windows (§ [uhb:par:omwindows]).

The AHF is a file containing processed AOCS telemetry. Clipped to the
start/end times of an observation or slew, the complete AHF for the
relevant revolution becomes an ODF or SDF component which is delivered
to the observer. For “stable pointing periods” the data records identify
intervals of time during which the spacecraft’s boresight did not
deviate by more than a configurable limit from the mean boresight during
that period. For open loop slews and post-slew attitude trims, the AHF
provides the instantaneous boresight at equidistant points in time
(typically 10 seconds). It should be noted that attitudes for open loop
slews are derived from a “slew model” into which the boundary conditions
(actual start/end times and attitudes) have been entered, i.e., the
intermediate attitudes provided for slews are not based on sensor data
telemetered during the slews.

It should be noted that there is an additional file that holds attitude
data, which can be used by the
http://www.cosmos.esa.int/web/xmm-newton/sas
(http://www.cosmos.esa.int/web/xmm-newton/sas). This is the so called
Raw Attitude File (RAF) which provides the attitude information at the
maximum possible rate (one entry every 0.5 s). The AHF is in fact a
smoothed and filtered version of the RAF. The online documentation of
the http://www.cosmos.esa.int/web/xmm-newton/sas
(http://www.cosmos.esa.int/web/xmm-newton/sas) package oal (section on
SAS_ATTITUDE) gives further info on how to select amongst the AHF and
RAF source of ODF attitude data.
, Generating EPIC images

EPIC (http://www.cosmos.esa.int/web/xmm-newton/technical-details-epic)
images can be created from an event file with the evselect
(http://xmm-tools.cosmos.esa.int/external/sas/current/doc/evselect/index.html)
task from the command line or with the xmmselect
(http://xmm-tools.cosmos.esa.int/external/sas/current/doc/xmmselect/index.html)
task in an interactive GUI driven way.
, source_sentence: What is the primary purpose of the FITS format?
sentences: Scope: xrt

There will be three instances of each of these files.

Calibration type: XAreaEf
Description: X-ray effective area of a single mirror module versus
energy, field angle, and azimuth

Calibration type: XEncirEn
Description: X-ray encircled energy function of a single mirror module
versus energy, field angle, and azimuth

Calibration type: XPSF
Description: X-ray point spread function of a single mirror module
versus energy, field angle, and field azimuth
, ASCII

ASCII files are used to present script and some tabular information. In
particular, each ODF/SDF contains a single summary file, with a summary
of the information relating to the observation or slew (see
Sect. [dfhb:par:odf]).
, FITS format

All of the ODF/SDF component files, with the exception of the summary
files, reconstructed orbit file, and raw attitude file, are FITS files
and conform to the standard. A description of the FITS format can be
found in , which is accessible also at the URL
The calibration files and the bulk of the PPS products also conform to
the FITS standard. Wherever possible and desirable the calibration files
and the PPS products follow the conventions of the OGIP
(http://heasarc.gsfc.nasa.gov/docs/heasarc/ofwg/ofwg_intro.html) (Office
of Guest Investigator Programs) FITS working group. The HEASARC FITS
Working Group activities are described at the following URL:
For FITS files where OGIP FITS standards are not applicable or
available, new standards closely following the OGIP approach are used.

The FITS format is primarily designed to store scientific data sets
consisting of multidimensional arrays (1-D spectra, 2-D images or 3-D
data cubes) and 2-dimensional tables containing rows and columns of
data. A FITS data file is composed of a sequence of Header + Data Units
(HDUs).

The general structure of a FITS file is as follows:

-   a primary header;

-   a primary data array of zero length;

-   zero or more extensions

Each extension consists of an extension header and a data section.
Extensions are named and can appear in any order. Only the following
FITS extensions are used:

-   ASCII table: XTENSION=TABLE

-   binary table: XTENSION=BINTABLE

-   image: XTENSION=IMAGE

The header consists of keyword=value statements, which describe the
organisation of the data in the HDU and the format of the contents. It
may also provide additional information, for example, about instrument
status or the history of the data. The following block contains the
data, which are structured as specified in the header. The data section
of the HDU may contain a digital image, a table or a multidimensional
matrix that is not an image. An HDU need not contain data.

pipeline_tag: sentence-similarity
library_name: sentence-transformers
Likes: 0 | All-time downloads: 137
Created: 2025-02-25 10:52:19