esa-sceva/satcom-chunk-collection huggingface dataset:
# Research on Dual-Emotion Feature Fusion and Performance Improvement in Rumor Detection
## 3 Methodology
### Model Architecture  
The experimental steps are as follows and the frame diagram of the model is shown in Figure 4:  
1. Firstly, the emotion classification model and emotion dictionary are selected to identify emotion words that can represent the characteristics of rumors and comments to the greatest extent. Secondly, the Numberbatch word vector is applied; the emotional feature information is combined in the Numberbatch word vector, and the words representing the emotional features of rumors and texts are transformed into the form of an emotion vector, which is convenient for the computer system to recognize and use.
2. Different from rumor texts, comments have a large amount of data, and the emotion vector needs to transform each comment feature. To avoid a vector dimension disaster, mean pooling is used to calculate the average emotional signal of N comments, max pooling is used to obtain the extreme emotional signal of N comments, and then the comment emotion vector of two dimensions is output, and Concat is used to concatenate the two vectors. Finally, it is used to represent the emotional characteristics and social-emotional characteristics of the publisher.
3. By comparing the values between the two emotional characteristics, two phenomena can be obtained: the first is emotional resonance, where the emotional and social-emotional characteristics of the publisher are the same or similar; the second is emotional disharmony, where the emotional characteristics between the two are inconsistent. When the emotional features are inconsistent, the differences between the publisher's emotional features and the two feature dimensions of social emotions are used to obtain two dimensions of the emotion gap. The dual-emotion features are composed of the publisher's emotional feature, social-emotional features, and emotion gap.
4. The semantic embedded word vector is used to represent the lexical features of the rumors, and the semantic vector is input twice into the BiGRU model and the CNN model for semantic feature extraction.
5. The domain features of rumors are extracted and analyzed, and semantic features are combined with domain features through the attention mechanism to extract finer-grained features.
6. The dual-emotion features are spliced with BiGRU model features, CNN model features, and domain features, then input into the MLP, and finally classified through softmax to output the results.
# A Generic Automated Surface Defect Detection Based on a Bilinear Model
## 3 Experiments
### Datasets Description
#### 3.2.4 Fluorescent Magnetic Powder Surface Defect Dataset  
Fluorescent magnetic powder nondestructive testing is a common method for the detection of any surface and near-surface defects of ferromagnetic materials such as aero-turbines [29], turbines [30], and train bearings [31] in the aerospace, military and civil industry. Its working principle is that after the ferromagnetic material work-piece is magnetized, the magnetic force line will be locally distorted when there are defects on the surface and near-surface of the work-piece. It leads to magnetic leakage, absorbing fluorescent magnetic particles suspended on the surface of the work-piece, and the forming of visible magnetic marks under ultraviolet light. In the experiment, the image acquisition system consisted of an industrial camera with XIMEA MQ042 CG-CM, a fixed focus lens with a focal length of 6 mm and an ultraviolet light. The system was used to detect surface cracks of the ferromagnetic cylindrical work-pieces with the height of 100 mm and diameter of 45 mm, in which the width and height of the crack range from 0.3 mm to 1.0 mm and from 7 mm to 90 mm, respectively. The experiment collected 800 defects and 1000 defects-free color images, and the size of the image is \(468\times 1324\) pixels, and the pixel precision is 24 bits. Examples of defect images are shown in Figure 7.
# Estimating the Thermal Conductivity of Unsaturated Sand
## 3 Model Development
### A Mathematical Model of \(\lambda_{es}^{dry}\)  
The measures of thermal conductivity of dry sand were obtained from Table A1 in Appendix A and the correlation curve of \(\lambda_{es}^{dry}\) with porosity was plotted. Figure 4 shows that the relationship between \(\lambda_{es}^{dry}\) and porosity was linear based on Equation (8) (\(0.2<n\leq 0.5\)). As the porosity increased, \(\lambda_{es}^{dry}\) decreased because the thermal conductivity of the air phase was lower than that of the mineral composition. This was in accordance with the findings of previous research [41; 42]. However, the main conductive mechanism of dry sand is contact conductance, and the effect of quartz content \(f_{q}\) was insignificant. Therefore, \(\lambda_{es}^{dry}\) correlated with porosity as follows:  
\[\lambda_{es}^{dry}\ =\ -kn\ +\ \theta \tag{8}\]  
where \(k\) and \(\theta\) are indeterminate coefficients that can be determined through experiments. From Equation (7), it can be concluded that the modified parallel model of dry sand is:  
\[\lambda=(1-n)\ (-kn+\theta)+n\lambda_{a}\ S_{r}=0 \tag{9}\]  
The coefficients \(k\) and \(\theta\) can be determined by fitting Equation (8) to the heat-pulse measurements. Figure 4 plots the \(\lambda_{es}^{dry}\)-\(n\) values and the fitted lines, which are represented by dashed and solid lines. For completely dry sand, \(\lambda_{es}^{dry}\) was affected only by the porosity of the sand.  
Figure 3: The relationship between \(\lambda_{es}\) and \(S_{r}\) ([PERSON] 2008 [6]).  
First, measurements of dry sand thermal conductivity should be made for no fewer than three groups of sand with different porosities. Next, \(\lambda_{es}^{dry}\) corresponding to the test groups is calculated based on Equation (3). In this way, the coefficients \(k\) and \(\theta\) can be obtained by fitting \(\lambda_{es}^{dry}\)-\(n\) values according to Equation (8) and used to prepare for the subsequent stages of determination of parameters \(A\) and \(B\) in Equation (6).
## 5 Hardware Implementation and Experimental Results
### Digital Mixer  
A digital mixer was proposed based on an LUT and periodic reset. It consists of the local oscillator [24] and the complex multiplier. The local oscillator had a structure shown in Figure 25. The real_in and imag_in signals were received from the LUT since different angles should be supported for different cases. For cases 10, 11, 12, and 13, the angles were (mixer 1, mixer 2) = (58.5938, 58.5938), (43.9453, 58.5938), (29.2969, 58.5938), and (29.2969, 29.2969), respectively, in units of (degrees, degrees).  
Figure 24: FIR3 (Farrow interpolator) synthesis results.  
Figure 25: Local oscillator structure.  
The proposed digital mixer can get rid of the phase error accumulation by adopting a counter, cnt, and multiplexers, as shown in Figure 25. More specifically, the local oscillator has a feedback structure to produce cumulated \(I\) and \(Q\) signals for a given angle each clock cycle. Owing to this, the oscillator was susceptible to phase error accumulation from quantization. In this design, the angle that the oscillator supports was found and the digital mixer was periodically reset by a counter (cnt in Figure 25) in order to prevent phase error accumulation. Figure 26 exhibited the phase errors without a counter (black) and with a counter for periodic reset (pink), from which it is shown that the proposed digital mixer could effectively prevent phase error accumulation.  
Next, the complex multiplier for the digital mixer was designed and implemented such that the output from FIR3 (Farrow interpolator) was multiplied by the local oscillator output. Its structure is displayed in Figure 27. The complex multiplier received FIR3_realout and FIR3_imagout from FIR3 and also received real_ff2 and imag_ff2 from the local oscillator to execute the operation.  
After the ASIC synthesis, the digital mixer composed of the local oscillator and the complex multiplier had a critical path delay of 3.72 ns consisting of a 1.1 ns delay of the (22-bit \(\times\) 21-bit) multiplier plus a 1 ns delay of the 42-bit adder plus a remaining path delay. After the FPGA P&R, the critical path delay, consisting of a 3.519 ns delay of the (22-bit \(\times\) 21-bit) multiplier plus a 0.619 ns delay of the 42-bit subtractor plus a remaining path delay, was 5.602 ns in total. The critical paths for ASIC and FPGA are highlighted in red and green, respectively, in Figure 27. As is evident, it is confirmed that the critical paths for ASIC and FPGA indicate the same path in effect since both paths had the same-sized multiplier and adder/subtractor.  
The ASIC synthesis results of the digital mixer in a 180 nm CMOS technology were summed up in Figure 28, where the required delay of 12.82 ns or 1/78 MHz was denoted as a red line. The digital mixer was synthesized to reveal a delay value that lies to the left of the red line at the expense of a small area overhead.  
Figure 26: Phase error in log scale (**left**) and linear scale (**right**) at the output of the proposed digital mixer.
## 4 Use Case Examples  
In this Section, we show some examples of application of the GenoMetric Query Language (GMQL [28]) on the OpenGDC standardized data in order to highlight the advantages of our data representation in terms of information retrieval and integrative processing. GMQL is a high-level domain-specific query language. It can be executed in the system architecture described in [29], which is specific for genomic data processing. The current available version of the GMQL system uses Apache Spark [43] as its backbone; along with other design choices, this provides high scalability in cloud computing. The GMQL system contains a multiplicity of public genomic datasets from a variety of sources [44], ready to be used within tertiary analysis pipelines (as shown in [29]); among other sources, it features all the datasets available in the OpenGDC FTP service, providing an interface for browsing and processing data curated in OpenGDC. The produced datasets are also made available within another system, GenoSurf (GenoSurf is available at [45]) [46], a semantic search engine based on a Conceptual Model [47] that integrates TCGA data, imported by OpenGDC, with several sources such as ENCODE [48], Roadmap Epigenomics [49], and 1000 Genomes [50], among others, using the META-BASE integration framework [51].  
In the following, we propose three use cases along with their GMQL queries (the corresponding GMQL queries are available in the Supplementary File 6, ready to be executed on [52]) (alternatively expressible using the Python package [53]); we focus on query aspects, acting on both region data and metadata, which highlight the strengths of the datasets produced by OpenGDC, i.e.: (1) enabling the combined use of metadata derived from the GDC Data Model, the Clinical/Biospecimen Supplements, and our manually curated additions; (2) providing positional information (i.e., genomic coordinates) in a standardized structure, which encourages data inter- and intra-source interoperability; (3) allowing joined use of different data types even from different sources (e.g., gene expression and methylation, or mutations and gene annotations) based on common gene identifiers (e.g., the HUGO gene symbol), or genomic positions.
## 2 Materials and Methods
### Application and Testing of Virtual Constellation in Apalachicola Bay
#### 2.4.3 Selection of Training Data  
Machine learning models, including the virtual constellation proposed here, require reliable and clean data for training. The accuracy of the final estimator is dependent on the quantity and quality of the training data. All predictor variables except calendar month are floating point values. Across 42 months with approximately 1.17 million records (pixels) per month, the overall data corpus contained just over 49 million records.  
The RF used in the virtual constellation to produce L8 compatible data from S2A and ASTER was implemented in Python using scikit-learn [77]. The Geospatial Data Abstraction Library (GDAL) [78] was used to determine the spatial locations associated with the data. All records containing missing predictors (labeled as \"zero\" or \"NaN\") were removed. 70% (\(\sim\)34.4 million) of the records in the data corpus were randomly selected without replacement to form the training data set with the remaining 30% (\(\sim\)14.7 million) set aside as the testing data set. Examples of labeled records used in the virtual constellation model are shown in Table 2.
# Maximizing Efficiency in Energy Trading Operations through IoT-Integrated Digital Twins
## 4 Performance Analysis
### Prediction Module Outcome  
The employment of prediction models is of utmost importance in uncovering tacit knowledge and identifying concealed patterns within datasets. To facilitate the training of the model, the BD-LSTM approach integrates a 10-fold cross-validation methodology. This technique is employed to make predictions on various energy-related variables, namely energy load, energy consumption, PV generation, and energy cost. The process is visually depicted in Figure 5, specifically in sub-figures (a-c). The provided visual representations illustrate the observed and projected data pertaining to energy demand, photo-voltaic (PV) generation, and energy consumption, effectively emphasizing the discrepancies between the two datasets. In Figure 5d, it is evident that PV generation prediction exhibits the lowest root mean square error (RMSE) value of 1.03 among the considered parameters. Following this, the energy load reveals an RMSE of 1.23, while energy consumption exhibits the highest RMSE value of 1.44. In general, the obtained root mean square error (RMSE) value for the gated recurrent unit (GRU) model indicates a satisfactory degree of predictive accuracy. This outcome has important implications for energy-focused prediction models, as it enables energy provider organizations to make educated decisions based on reliable forecasts.  
Figure 5: Cont.  
\begin{table}
\begin{tabular}{l l} \hline \hline
**Technology Name** & **Detail** \\ \hline OS & Windows 10 for PC Server, Raspbian for edge Raspberry Pi \\ Programming language & Python Flask, JavaScript, HTML, CSS \\ Libraries & Bootstrap 3, Jinja 3, JSplumb for mapping \\ Server & Flask server \\ Persistence & MySQL \\ Browser & Chrome and Firefox \\ Core programming language & Python 3 \\ \hline \hline \end{tabular}
\end{table}
Table 3: Tools and Techniques used in the proposed system.  
The outcomes obtained from the recommendation model based on GRU are contrasted with a comparable investigation that employed BD-LSTM for predicting the same variables, as depicted in Figure 6. In general, a reduction in the root mean square error (RMSE) signifies the enhanced performance of the model, suggesting that the model's predictions are in closer agreement with the observed values. Figure 6d illustrates that the root mean square error (RMSE) value achieved by the GRU prediction model is superior to the outcome of the BD-LSTM model. This suggests that the GRU model can be regarded as a more effective metric.  
Figure 5: This figure shows actual and predicted values of key energy parameters, including actual and predicted energy load and photovoltaic (PV) generation values. (**a**) Actual and predicted energy values using gated recurrent unit (GRU) prediction module. (**b**) Predicted and actual PV generation values using GRU prediction module. (**c**) Predicted and actual energy consumption values using GRU prediction module. (**d**) Root mean square error value-based comparison analysis between Bidirectional-LSTM and GRU prediction module.  
Figure 6: \(Cont.\)
# A Blockchain and IoT-Enabled Framework for Ethical and Secure Coffee Supply Chains
## 1 Introduction
### The Need for Blockchain and IoT in the Coffee Supply Chain  
The synergy between blockchain [11] and Internet of Things (IoT) [12] technologies offers a compelling framework for addressing persistent inefficiencies and trust deficits within the coffee supply chain. When combined, these technologies can transform the current fragmented and opaque system into a transparent, data-driven, secure, and automated infrastructure, as presented in Figure 1. IoT devices serve as the interface between physicalevents and digital records, while blockchain ensures that these records are tamper-proof, verifiable, and shared among all stakeholders. This convergence bridges the gap between real-world processes and reliable digital documentation, enabling end-to-end traceability, operational accountability, and consumer trust.  
Below, we discuss the essential reasons why the synergy of blockchain and IoT is suitable for addressing the above-mentioned issues with the existing coffee supply chain.
# A Low-Cost Remotely Configurable Electronic Trap for Insect Pest Dataset Generation
## 1 Introduction
On the one hand, from a technical point of view, the camera calibration depends greatly on the intrinsic parameters of the camera system [28], the location and position of the trap, as well as the different surrounding elements that can create shadows on the object to be captured; moreover, from an agronomic point of view, the most convenient period of the year and times of day to schedule the most significant image captures is likely to depend on the type of pest under study, which has a direct impact on the configuration, as its parameters need to be adjusted to the expected exposure to light. The challenge of correct configuration can be addressed by enabling a remote reconfiguration protocol, a cloud-to-edge return path, which allows the trap to be remotely operated in order to set the appropriate parameters in real time, without the need to move suitably trained staff for that purpose. This innovation has not been addressed in the scientific literature and represents the main motivation for this study. Furthermore, there are other issues to be addressed in the current state of the fully automated insect pest monitoring devices. For instance, some works are able to make the detection and classification with highly powerful processors. These processing units consume a lot of energy, so that direct power, large batteries, or renewable energy capturing elements must be included. This constraint causes the devices to become very expensive, making them unsuitable for large deployments in rural non-attended areas. Thus, some type of balance between pest detection quality, power consumption, and economic costs needs to be reached. In this article, we propose a network-connected, low-cost device with a camera. One of the main advantages of the proposed device is that it can be accessed and configured remotely, which is a feature that has not been found in any other trap. The configuration can be set using intuitive and easy-to-follow webpages with standard API commands. This will allow users to check parameters on-the-fly, which is a novel feature not found in other works. Moreover, the configuration of the parameters of the camera can be set almost automatically by making use of objective quality metrics. We have not found this issue in any other trap. Thanks to the use of this feature, little expertise in image processing is required to obtain high-quality images.
## 3 Proposed Method
### Learning Process
The decoding network receives at its input a pre-processed image in the form of a tensor from the preliminary network, which it further processes and returns as an embedded watermark at its output. The preliminary networks for the encoder and decoder are identical in structure. The encoding and decoding networks have similar network structures, the difference being the number of filters used. Memory and performance requirements for processing a single 128 \(\times\) 128 pixel image are shown in Table 6. \begin{table}
\begin{tabular}{c c c c c c} \hline \hline
**Type** & **Input Tensor Size** & **Number of Weights** & **Size on Disk** & \begin{tabular}{c} **Processing Time for a** \\ **Single Tensor [ms]** \\ \end{tabular} & **GPU Processor** \\ \hline Encoder & \
\begin{tabular}{c} (2, 128, 128, 3) \\ (128, 128, 3) \\ \end{tabular} & 6,523,953 & 75.3 MB & 106.681 & GeForce 1080 Ti \\ Decoder &
\begin{tabular}{c} (128, 128, 3) \\ \end{tabular} & 7,647,390 & 88.2 MB & 31.25 & GTX 11 GB \\ \hline \hline \end{tabular}
\end{table} 
Table 6: Parameters of the designed networks. \begin{table}
\begin{tabular}{c c c} \hline \hline
**Layer Number** & **Layer Type** & **Parameters** \\ \hline
1 & BL &
\begin{tabular}{c} activation function: LeakyReLU \\ kernel size: 3 \(\times\) 3 \\ encoder filter number: 61 \\ decoder filter number: 71 \\ activation function: LeakyReLU \\ kernel size: 5 \(\times\) 5 \\ encoder filter number: 61 \\ decoder filter number: 61 \\ decoder filter number: 71 \\ encoder filter number: 61 \\ decoder filter number: 71 \\ \end{tabular} \\
2 & BL &
\begin{tabular}{c} activation function: LeakyReLU \\ kernel size: 3 \(\times\) 3 \\ encoder filter number: 61 \\ decoder filter number: 61 \\ decoder filter number: 71 \\ \end{tabular} \\
3 & BL &
\begin{tabular}{c} activation function: LeakyReLU \\ kernel size: 7 \(\times\) 7 \\ decoder filter number: 71 \\ encoder filter number: 71 \\ encoder filter number: 71 \\ decoder filter number: 71 \\ \end{tabular} \\
4 &
\begin{tabular}{c} Concatenate ((1, 2, 3), \\ axis = 3) \\ \end{tabular} & - \\
5 & BL &
\begin{tabular}{c} activation function: LeakyReLU \\ kernel size: 7 \(\times\) 7 \\ encoder filter number: 61 \\ decoder filter number: 71 \\ activation function: LeakyReLU \\ kernel size: 5 \(\times\) 5 \\ encoder filter number: 61 \\ decoder filter number: 61 \\ decoder filter number: 71 \\ \end{tabular} \\
6 & BL &
\begin{tabular}{c} encoder filter number: 61 \\ decoder filter number: 71 \\ encoder filter number: 61 \\ decoder filter number: 71 \\ encoder filter number: 61 \\ decoder filter number: 71 \\ \end{tabular} \\
7 & BL &
\begin{tabular}{c} activation function: LeakyReLU \\ kernel size: 3 \(\times\) 3 \\ encoder filter number: 61 \\ decoder filter number: 71 \\ \end{tabular} \\
8 &
\begin{tabular}{c} Concatenate ((5, 6, 7), \\ axis = 3) \\ \end{tabular} & - \\
9 & Convolution 2D layer & activation function: LeakyReLU \\ kernel size: 1 \\ \hline \hline \end{tabular}
\end{table} 
Table 5: A model of convolutional neural network encoding and decoding.