---
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\n\nThe structure of the present document is as follows:\n\
\n- Chapter [sasguide:par:analysis] introduces the investigator to the\n \
\ analysis of XMM-Newton\n (http://www.cosmos.esa.int/web/xmm-newton/technical-details)\
\ data.\n It provides a brief description of XMM-Newton\n (http://www.cosmos.esa.int/web/xmm-newton/technical-details)\n\
\ observation and calibration files and outlines the analysis steps\n required\
\ to produce calibrated event files and to extract scientific\n products.\n\
\n- Chapter [sasguide:par:gui] describes the SAS graphical user\n interface\
\ (GUI), a user friendly tool which enables SAS interactive\n analysis tasks\
\ to be run without using the command line.\n\n- Chapters [sasguide:par:epic],\
\ [sasguide:par:rgs] and\n [sasguide:par:om] describe the SAS analysis steps\
\ required to obtain\n EPIC\n (http://www.cosmos.esa.int/web/xmm-newton/technical-details-epic),\n\
\ RGS (http://www.cosmos.esa.int/web/xmm-newton/technical-details-rgs)\n \
\ and OM\n (http://www.cosmos.esa.int/web/xmm-newton/technical-details-om)\
\ data\n products, respectively, which can be used afterwards by standard\n\
\ astronomical software packages.\n\n- Chapter [sasguide:xmmextractor] gives\
\ an overview of a SAS procedure\n to produce high-level science products for\
\ XMM-Newton\n (http://www.cosmos.esa.int/web/xmm-newton/technical-details) cameras\n\
\ from the raw, uncalibrated, data files contained in the Observation\n \
\ Data File (ODF). The procedure allows for some interactivity which\n lets\
\ the user take decisions concerning the analysis process.\n"
- "ommosaic\n- Whilst tests have so far shown that scattered-light features do\
\ not\n effect the cross-correlation algorithm, further testing is underway\n\
\ and the method should be used with caution.\n\n- Tests using the cross-algorithm\
\ on aspect-corrected sky-images have\n so-far shown the computed offsets to\
\ be small (less than 0.2\n pixels). If both the aspect-correction and the\
\ cross-correlation\n algorithm were perfect, they should be zero. However\
\ the error in\n the aspect-correction can be up to 1 arc sec, and further\
\ testing\n needs to be done to evaluate any differences.\n\n- It would be\
\ desireable to perform a further aspect correction on the\n sky-images- this\
\ would require either a new OM task or, possibly, a\n modification to omsrclistcomb.\
\ Note that even if the sky-images have\n not been aspect-corrected, the coordinates\
\ of the sources in the\n observation source-list file may have.\n"
- '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) \n\n- This file contains a schematic image of\
\ the XMM-Newton telescope\n front end\n\n- This is a product of class PPSOBS\n\
\n- The product is delivered in PNG format\n\n- There is one file per observation.\
\ File size is 3KB.\n"
- "dpsssrc\n## Parameters\n\n**set** (Mandatory): EPIC Maximum-Likelihood source\
\ list, identifier\nTTTTTT = EMSRLI (Type: string, Default: P0123700101PNS003EMSRLI0000.FIT,\n\
Range: applies only for EPIC Maximum-Likelihood detection lists)\n\n**maxlikthresh**\
\ (Optional): threshold to set the source flag\n‘source likelihood below a certain\
\ threshold (Type: real value, Default: 50., Range: must be greater than 0.)’\
\ to T \n**prefix** (Optional): prefix for output name (‘prefix (Type: string,\n\
Default: flag_, Range: applies only for EPIC Maximum-Likelihood\ndetection lists)_\n\
[INPUT FILES]\ndpsssrc\n1. POOOOOOOOOODDSEEEEMSRLISXXX.FIT EPIC Maximum-Likelihood\
\ detection\n source List. The identifier for TTTTTT must be equal to EMSRLI.\
\ The\n naming convention given above is according to and SSC-LUX-TN-0038.\n\
\n[OUTPUT FILES]\ndpsssrc\n1. flag_POOOOOOOOOODDSEEEEMSRLISXXX.FIT\n\n Copy\
\ of a EPIC Maximum-Likelihood detection list. Three new column\n are created\
\ and the source flag setting for sources below a certain\n detection threshold\
\ is performed.\n\n[COMMENTS] dpsssrc\n- This task only applies for EPIC Maximum-Likelihood\
\ detection lists.\n[CAL USAGE] dpsssrc"
- "emosaicproc\nThe data preparation consists of:\n\n- transforming the sky coordinates\
\ by every event file corresponding\n to the different instruments and pointings\
\ to a common image centre,\n\n- extracting images per instrument, pointing\
\ and spectral selection,\n using common filtering and evtl. provided GTIs\n"
- 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\n North-aligned\
\ sky coordinates.\n\n- The files are identified using the keyword\n\n \
\ CONTENT = 'OM OSW SKY IMAGE' (SIMAGE)\n for default and User configurations\n\
\ or\n CONTENT = 'OM FULL-FRAME SKY IMAGE' (FSIMAG)\n for\
\ low and high resolution full-frame configurations\n or\n CONTENT\
\ = 'OM FAST MODE OSW SKY IMAGE' (SIMAGF)\n for FAST mode window\n\n-\
\ This is a product of class OMSW.\n\n- These images may be rectified against\
\ the USNO-B1 catalogue in which\n case keywords RA_OFF, DEC_OFF and POSCOROK\
\ are added to the header.\n\n- This product is used for comparison between\
\ optical and X-ray images\n (also in sky coordinates). It is used in the production\
\ of OM OSW\n PNG images.\n\n- There is one OM OSW FITS sky image for each\
\ OM OSW FITS image, and\n each file, on average, occupies ∼1.2MB uncompressed\
\ while the FAST\n mode image is typically 14KB uncompressed. For the full\
\ frame images\n the size is typically 22MB uncompressed.\n"
- "- In pn event lists this extension contains the CCD columns to which\n an\
\ additional offset is applied to reduce noise (the offset is later\n subtracted\
\ again by the SAS). In the MOS event lists this extension\n currently defines\
\ columns outside the sensitive CCD window, to which\n formal very high values\
\ of the offset are associated. These columns\n are discarded by the data processing.\n\
\n- For MOS imaging mode event lists this extension contains the\n following\
\ columns:\n\n Name Type Description\n --------- ----------------\
\ ----------------------------------------------------------\n RAWX \
\ 2-byte INTEGER Row or column of the bad offset\n OFFSETX 2-byte INTEGER\
\ amplitude of additional column offset (0 for row offset)\n OFFSETY \
\ 2-byte INTEGER amplitude of additional row offset (0 for column offset)\n\
\ CCDNR 1-byte CCD where the offset occurs\n\n- For MOS timing\
\ mode event lists this extension contains the\n following columns:\n\n \
\ Name Type Description\n --------- ---------------- ---------------------------------------\n\
\ RAWX 2-byte INTEGER Row or column of the bad offset\n OFFSETX\
\ 2-byte INTEGER amplitude of additional column offset\n CCDNR 1-byte\
\ CCD where the offset occurs\n\n- For pn imaging mode event lists\
\ this extension contains the\n following columns:\n\n Name Type\
\ Description\n --------- ---------------- ---------------------------------------\n\
\ RAWX 2-byte INTEGER Row of the bad offset\n OFFSETX 2-byte\
\ INTEGER amplitude of additional column offset\n CCDNR 1-byte \
\ CCD where the offset occurs\n\n- For pn timing mode event lists this\
\ extension contains the following\n columns:\n\n Name Type \
\ Description\n --------- ---------------- ---------------------------------------\n\
\ RAWX 2-byte INTEGER Row of the bad offset\n OFFSETX 2-byte\
\ INTEGER amplitude of additional column offset\n CCDNR 1-byte \
\ CCD where the offset occurs\n\n- Note that currently, the offset table\
\ is always empty and only the\n CCDNR column is present and it is unfilled.\
\ This may change in the\n future.\n"
- 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\n number\
\ of rejections of each column (discarded lines) of CCD nn over\n the course\
\ of the exposure.\n\n- There is one extension per CCD in the relevant mode\
\ (IMAGING or\n TIMING) during the exposure.\n\n- This extension contains\
\ the following columns:\n\n Name Type Description\n \
\ -------- ---------------- -----------------------------------------------\n\
\ DLIODF 4-byte INTEGER Number of rejections by onboard MIP algorithm\n\
\ DLISAS 4-byte INTEGER Number of subsequent rejections by the SAS\n\n\
- Each row corresponds to a column.\n"
- '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
---
# SentenceTransformer based on nomic-ai/modernbert-embed-base
This is a [sentence-transformers](https://www.SBERT.net) model finetuned from [nomic-ai/modernbert-embed-base](https://huggingface.co/nomic-ai/modernbert-embed-base). It maps sentences & paragraphs to a 768-dimensional dense vector space and can be used for semantic textual similarity, semantic search, paraphrase mining, text classification, clustering, and more.
## Model Details
### Model Description
- **Model Type:** Sentence Transformer
- **Base model:** [nomic-ai/modernbert-embed-base](https://huggingface.co/nomic-ai/modernbert-embed-base)
- **Maximum Sequence Length:** 8192 tokens
- **Output Dimensionality:** 768 dimensions
- **Similarity Function:** Cosine Similarity
### Model Sources
- **Documentation:** [Sentence Transformers Documentation](https://sbert.net)
- **Repository:** [Sentence Transformers on GitHub](https://github.com/UKPLab/sentence-transformers)
- **Hugging Face:** [Sentence Transformers on Hugging Face](https://huggingface.co/models?library=sentence-transformers)
### Full Model Architecture
```
SentenceTransformer(
(0): Transformer({'max_seq_length': 8192, 'do_lower_case': False}) with Transformer model: ModernBertModel
(1): Pooling({'word_embedding_dimension': 768, 'pooling_mode_cls_token': False, 'pooling_mode_mean_tokens': True, 'pooling_mode_max_tokens': False, 'pooling_mode_mean_sqrt_len_tokens': False, 'pooling_mode_weightedmean_tokens': False, 'pooling_mode_lasttoken': False, 'include_prompt': True})
(2): Normalize()
)
```
## Usage
### Direct Usage (Sentence Transformers)
First install the Sentence Transformers library:
```bash
pip install -U sentence-transformers
```
Then you can load this model and run inference.
```python
from sentence_transformers import SentenceTransformer
# Download from the 🤗 Hub
model = SentenceTransformer("sentence_transformers_model_id")
# Run inference
sentences = [
'What is the primary purpose of the FITS format?',
'FITS format\n\nAll of the ODF/SDF component files, with the exception of the summary\nfiles, reconstructed orbit file, and raw attitude file, are FITS files\nand conform to the standard. A description of the FITS format can be\nfound in , which is accessible also at the URL\nThe calibration files and the bulk of the PPS products also conform to\nthe FITS standard. Wherever possible and desirable the calibration files\nand the PPS products follow the conventions of the OGIP\n(http://heasarc.gsfc.nasa.gov/docs/heasarc/ofwg/ofwg_intro.html) (Office\nof Guest Investigator Programs) FITS working group. The HEASARC FITS\nWorking Group activities are described at the following URL:\nFor FITS files where OGIP FITS standards are not applicable or\navailable, new standards closely following the OGIP approach are used.\n\nThe FITS format is primarily designed to store scientific data sets\nconsisting of multidimensional arrays (1-D spectra, 2-D images or 3-D\ndata cubes) and 2-dimensional tables containing rows and columns of\ndata. A FITS data file is composed of a sequence of Header + Data Units\n(HDUs).\n\nThe general structure of a FITS file is as follows:\n\n- a primary header;\n\n- a primary data array of zero length;\n\n- zero or more extensions\n\nEach extension consists of an extension header and a data section.\nExtensions are named and can appear in any order. Only the following\nFITS extensions are used:\n\n- ASCII table: XTENSION=TABLE\n\n- binary table: XTENSION=BINTABLE\n\n- image: XTENSION=IMAGE\n\nThe header consists of keyword=value statements, which describe the\norganisation of the data in the HDU and the format of the contents. It\nmay also provide additional information, for example, about instrument\nstatus or the history of the data. The following block contains the\ndata, which are structured as specified in the header. The data section\nof the HDU may contain a digital image, a table or a multidimensional\nmatrix that is not an image. An HDU need not contain data.\n',
'ASCII\n\nASCII files are used to present script and some tabular information. In\nparticular, each ODF/SDF contains a single summary file, with a summary\nof the information relating to the observation or slew (see\nSect.\xa0[dfhb:par:odf]).\n',
]
embeddings = model.encode(sentences)
print(embeddings.shape)
# [3, 768]
# Get the similarity scores for the embeddings
similarities = model.similarity(embeddings, embeddings)
print(similarities.shape)
# [3, 3]
```
## Training Details
### Training Dataset
#### Unnamed Dataset
* Size: 3,625 training samples
* Columns: anchor and positive
* Approximate statistics based on the first 1000 samples:
| | anchor | positive |
|:--------|:----------------------------------------------------------------------------------|:-------------------------------------------------------------------------------------|
| type | string | string |
| details | - min: 2 tokens
- mean: 15.71 tokens
- max: 38 tokens
| - min: 2 tokens
- mean: 412.57 tokens
- max: 3755 tokens
|
* Samples:
| anchor | positive |
|:---------------------------------------------------------------------------|:---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
| What is the purpose of the document described in the preface? | Preface
This is the reference document describing the individual XMM-Newton
Survey Science Centre (SSC) data product files. It is intended to be of
use to software developers, archive administrators and to scientists
analysing XMM-Newton data. Please see the SSC data products Interface
Control Document (XMM-SOC-ICD-0006-SSC, issue 4.0) for a description of
the product group files and other related files that are sent to the
SOC.
This version (4.3) includes changes related to the upgrade to SAS16.0 in
the processing pipeline originally developped in 2012 to uniformly
process all the XMM data at that time, from which the 3XMM catalogue was
derived. Revisions and additions since version 4.2 are identified by
change bars at the right of each page.
This document will continue to evolve through subsequent issues, under
indirect control from the SAS and SSC configuration control boards.
This document is the result of the work of many people. Contributors
have included:
Hermann Brunner, G... |
| What version of the document is described in the preface? | Preface
This is the reference document describing the individual XMM-Newton
Survey Science Centre (SSC) data product files. It is intended to be of
use to software developers, archive administrators and to scientists
analysing XMM-Newton data. Please see the SSC data products Interface
Control Document (XMM-SOC-ICD-0006-SSC, issue 4.0) for a description of
the product group files and other related files that are sent to the
SOC.
This version (4.3) includes changes related to the upgrade to SAS16.0 in
the processing pipeline originally developped in 2012 to uniformly
process all the XMM data at that time, from which the 3XMM catalogue was
derived. Revisions and additions since version 4.2 are identified by
change bars at the right of each page.
This document will continue to evolve through subsequent issues, under
indirect control from the SAS and SSC configuration control boards.
This document is the result of the work of many people. Contributors
have included:
Hermann Brunner, G... |
| What is the main change in version 4.3 of the document? | Preface
This is the reference document describing the individual XMM-Newton
Survey Science Centre (SSC) data product files. It is intended to be of
use to software developers, archive administrators and to scientists
analysing XMM-Newton data. Please see the SSC data products Interface
Control Document (XMM-SOC-ICD-0006-SSC, issue 4.0) for a description of
the product group files and other related files that are sent to the
SOC.
This version (4.3) includes changes related to the upgrade to SAS16.0 in
the processing pipeline originally developped in 2012 to uniformly
process all the XMM data at that time, from which the 3XMM catalogue was
derived. Revisions and additions since version 4.2 are identified by
change bars at the right of each page.
This document will continue to evolve through subsequent issues, under
indirect control from the SAS and SSC configuration control boards.
This document is the result of the work of many people. Contributors
have included:
Hermann Brunner, G... |
* Loss: [CachedMultipleNegativesRankingLoss](https://sbert.net/docs/package_reference/sentence_transformer/losses.html#cachedmultiplenegativesrankingloss) with these parameters:
```json
{
"scale": 1.0,
"similarity_fct": "get_similarity"
}
```
### Evaluation Dataset
#### Unnamed Dataset
* Size: 30 evaluation samples
* Columns: anchor and positive
* Approximate statistics based on the first 30 samples:
| | anchor | positive |
|:--------|:-----------------------------------------------------------------------------------|:-------------------------------------------------------------------------------------|
| type | string | string |
| details | - min: 10 tokens
- mean: 16.73 tokens
- max: 31 tokens
| - min: 6 tokens
- mean: 655.37 tokens
- max: 6762 tokens
|
* Samples:
| anchor | positive |
|:-------------------------------------------------------------------------------------|:------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
| In pn imaging mode event lists, what is the type of the OFFSETX column? | - 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... |
| What are the three binary table extensions created per source used for? | - This product lists bright sources detected by EPIC which fall in the
RGS field of view. It also includes the entries for the proposal
position and the on-axis location. EPIC and RGS positions are given,
as well as RGS spatial and energy-dispersion angle extraction
regions for the sources and a background region.
- These files are identified using the keyword
CONTENT = 'RGS SOURCE LIST' / File content
in the primary header.
- There are two binary table extensions (SRCLIST and RGSn_BACKGROUND),
plus a further three binary table extensions per source
(RGSn_SRCm_SPATIAL, RGSn_SRCm_ORDER_1 and RGSn_SRCm_ORDER_2, where n
is the number of the RGS (1 or 2) and m is the number of the source.
- The SRCLIST extension has the following columns:
Name Type Description
-------------- ------------------ ---------------------------------------------------------
INDEX 2-byte INTEGER Source inde... |
| What is the purpose of the analysis steps outlined in the document? | 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-r... |
* Loss: [CachedMultipleNegativesRankingLoss](https://sbert.net/docs/package_reference/sentence_transformer/losses.html#cachedmultiplenegativesrankingloss) with these parameters:
```json
{
"scale": 1.0,
"similarity_fct": "get_similarity"
}
```
### Training Hyperparameters
#### Non-Default Hyperparameters
- `eval_strategy`: steps
- `per_device_train_batch_size`: 16
- `per_device_eval_batch_size`: 4
- `num_train_epochs`: 2
- `lr_scheduler_type`: constant
- `warmup_ratio`: 0.1
- `bf16`: True
- `batch_sampler`: no_duplicates
#### All Hyperparameters
Click to expand
- `overwrite_output_dir`: False
- `do_predict`: False
- `eval_strategy`: steps
- `prediction_loss_only`: True
- `per_device_train_batch_size`: 16
- `per_device_eval_batch_size`: 4
- `per_gpu_train_batch_size`: None
- `per_gpu_eval_batch_size`: None
- `gradient_accumulation_steps`: 1
- `eval_accumulation_steps`: None
- `torch_empty_cache_steps`: None
- `learning_rate`: 5e-05
- `weight_decay`: 0.0
- `adam_beta1`: 0.9
- `adam_beta2`: 0.999
- `adam_epsilon`: 1e-08
- `max_grad_norm`: 1.0
- `num_train_epochs`: 2
- `max_steps`: -1
- `lr_scheduler_type`: constant
- `lr_scheduler_kwargs`: {}
- `warmup_ratio`: 0.1
- `warmup_steps`: 0
- `log_level`: passive
- `log_level_replica`: warning
- `log_on_each_node`: True
- `logging_nan_inf_filter`: True
- `save_safetensors`: True
- `save_on_each_node`: False
- `save_only_model`: False
- `restore_callback_states_from_checkpoint`: False
- `no_cuda`: False
- `use_cpu`: False
- `use_mps_device`: False
- `seed`: 42
- `data_seed`: None
- `jit_mode_eval`: False
- `use_ipex`: False
- `bf16`: True
- `fp16`: False
- `fp16_opt_level`: O1
- `half_precision_backend`: auto
- `bf16_full_eval`: False
- `fp16_full_eval`: False
- `tf32`: None
- `local_rank`: 0
- `ddp_backend`: None
- `tpu_num_cores`: None
- `tpu_metrics_debug`: False
- `debug`: []
- `dataloader_drop_last`: False
- `dataloader_num_workers`: 0
- `dataloader_prefetch_factor`: None
- `past_index`: -1
- `disable_tqdm`: False
- `remove_unused_columns`: True
- `label_names`: None
- `load_best_model_at_end`: False
- `ignore_data_skip`: False
- `fsdp`: []
- `fsdp_min_num_params`: 0
- `fsdp_config`: {'min_num_params': 0, 'xla': False, 'xla_fsdp_v2': False, 'xla_fsdp_grad_ckpt': False}
- `fsdp_transformer_layer_cls_to_wrap`: None
- `accelerator_config`: {'split_batches': False, 'dispatch_batches': None, 'even_batches': True, 'use_seedable_sampler': True, 'non_blocking': False, 'gradient_accumulation_kwargs': None}
- `deepspeed`: None
- `label_smoothing_factor`: 0.0
- `optim`: adamw_torch
- `optim_args`: None
- `adafactor`: False
- `group_by_length`: False
- `length_column_name`: length
- `ddp_find_unused_parameters`: None
- `ddp_bucket_cap_mb`: None
- `ddp_broadcast_buffers`: False
- `dataloader_pin_memory`: True
- `dataloader_persistent_workers`: False
- `skip_memory_metrics`: True
- `use_legacy_prediction_loop`: False
- `push_to_hub`: False
- `resume_from_checkpoint`: None
- `hub_model_id`: None
- `hub_strategy`: every_save
- `hub_private_repo`: None
- `hub_always_push`: False
- `gradient_checkpointing`: False
- `gradient_checkpointing_kwargs`: None
- `include_inputs_for_metrics`: False
- `include_for_metrics`: []
- `eval_do_concat_batches`: True
- `fp16_backend`: auto
- `push_to_hub_model_id`: None
- `push_to_hub_organization`: None
- `mp_parameters`:
- `auto_find_batch_size`: False
- `full_determinism`: False
- `torchdynamo`: None
- `ray_scope`: last
- `ddp_timeout`: 1800
- `torch_compile`: False
- `torch_compile_backend`: None
- `torch_compile_mode`: None
- `dispatch_batches`: None
- `split_batches`: None
- `include_tokens_per_second`: False
- `include_num_input_tokens_seen`: False
- `neftune_noise_alpha`: None
- `optim_target_modules`: None
- `batch_eval_metrics`: False
- `eval_on_start`: False
- `use_liger_kernel`: False
- `eval_use_gather_object`: False
- `average_tokens_across_devices`: False
- `prompts`: None
- `batch_sampler`: no_duplicates
- `multi_dataset_batch_sampler`: proportional