# BigData Cup Challenge 2020: Flare Prediction — Data

来源：https://www.kaggle.com/competitions/bigdata2020-flare-prediction/data

本地 Meta Kaggle 快照；不是本次实时页面。

# Dataset Description

Download the entire dataset from [[https://dmlab.cs.gsu.edu/solar/data/data-comp-2020/](https://dmlab.cs.gsu.edu/solar/data/data-comp-2020/)]

----

### Flare Classes

Solar flares are automatically detected and classified by the National Oceanic and Atmospheric Administration’s (NOAA) constellation of GOES satellites based on their peak flux in soft X-ray wavelengths on a logarithmic scale as A-, B- ,C- , M-, and X-class solar flares, from weakest to the strongest. The most intense of these classes, namely M and X, are most often targeted for prediction due to their potentially adverse space-weather ramifications. In this competition, the dataset consists of 5 classes, namely X, M, C, B, and FQ. The last one represents the flare-quiet regions where no flare has been detected within the observation period. Note that we do not include A class flares for the reason given above.


### Dataset

The data in each of the following files are formatted as sets of json objects.  Each one containing a unique identifier within the file, a class label if one of the training folds, and an array of time series values used for prediction.  Each sample multi-variate time series has 60 values representing an observation taken at 12-minute intervals.  The first value in the array is the sample observation taken at the furthest point in time from the predication period and the last value in the array is the sample observation taken at the closest point in time to the prediction period. The period of observations represented by each labeled time series is a 12 hour window of observations sliced from a longer time series.

Since the dataset is a set of partially overlapping sliced samples pulled from larger multi-variate time series, sampling decisions can have deleterious effects to the generalization of models trained using different strategies. For this reason, each of the training folds are temporally disjoint sets of samples so as to mitigate any possible over-fitting issues that may arise from sampling decisions made by the participants.  If a standard ⅔ training ⅓ testing sampling strategy is utilized to determine a model for use as your final submission (i.e. selecting 2 folds for training and 1 fold for testing), it is guaranteed that no partially overlapping samples will be selected for both the training and testing sets and therefore the resultant trained model is more likely to generalize to the final test set used for scoring. This is not to say that using all three training folds for training your final model will not be beneficial, it is simply providing a way for participants to train/test their models independently from having to submit a result set for evaluation (which teams are limited to 2 per day), and avoid common over-fitting errors.  

### File Description
* **Training Sets:**
  * `train_partition1_data.json`
  * `train_partition2_data.json`
  * `train_partition3_data.json`
* **Testing Set:**
  * `test_4_5_data.json`
* **Sample Submission**:
  * A sample submission file in the correct format: `sampleSubmission.csv`

### Data Structures
* In training data: `{<id>: {"label": <lab>, "values": <mvts_dict>}}`
* In testing data: `{<id>: {"label": none, "values": <mvts_dict>}}`

where `<mvts_dict>` is a dictionary representing the mvts.

For more details, see `data_demo` notebook in the Notebooks page.
----------