extfieldsofstudy:
Biology
Computer Science

text:
WeSeqMiner: A Weka package for building machine-learning models for sequence data

In most cases, the application of machine learning techniques to biological sequence data requires a vector representation of the sequences. Extracting the numerical features from sequence data can be time consuming, especially if the user lacks programming skills. To this end, we propose a Weka package called WeSeqMiner, which provides several useful filters for extracting numerical features from sequence data for use in the Weka machine learning workbench. Motivated with an example, we show that the WeSeqMiner package integrates well with the Weka API, allowing transformations to be incorporated into Weka workflows for predictive model generation. WeSeqMiner can be installed by pointing the Weka package manager to the URL github.com/djhogan/WeSeqMiner/raw/master/WeSeqMiner.zip. The Javadoc for WeSeqMiner classes can be accessed at djhogan.github.io/seqminer.

Introduction
A number of high-throughput technologies generate large datasets relating peptide sequences to a biological property of interest. For example, in antibody phage display these peptides are variants of a complementarity determining region (CDR), often CDRH3, which is the primary determinant of antibody specificity [2]. The property of interest is the target-specificity of the antibodies incorporating these CDRs. Another technology is peptide microarrays, which contain several thousand spots of unique peptides in a grid-like arrangement on a glass surface. These peptides may be potential epitopes as in the case of epitope discovery, or predicted kinase targets as in the case of kinome analysis.
The large volume of data produced by high-throughput technologies like antibody phage display and peptide microarrays makes machine learning a viable option for discovering functions relating sequence to biological state, function, or condition. Bioinformatics is replete with such examples [4]. Unfortunately, the majority of machine learning techniques cannot be directly applied to sequence data due to its string representation, and the way to vectorize these strings is not obvious. Researchers must resort to extracting features from the string data that retain the salient information or signal for their prediction task. One feature extraction strategy is to represent each amino acid in a sequence as a vector of numerical properties. Two such strategies are to use columns of a substitution matrix (e.g. BLOSUM62) or the Kidera Factors. The Kidera Factors [3] are the 10 principal components uncovered from a principal component analysis of 188 physico-chemical properties of amino acids; therefore, each of the 20 amino acids would be represented by a unique vector of length 10 in this principal component space.
To simplify sequence feature extraction for users of the Weka machine learning workbench [8] we propose a Weka package called WeSeqMiner, which conforms to the Weka API, and thus benefits from the Weka ecosystem, providing a convenient interface for feature extraction and integration with upstream tasks, like reading data, and downstream tasks like feature selection or classifier/regressor training.

Software Features
WeSeqMiner provides Weka with 6 new filters that extract numerical attributes (features) from a basic string attribute representing a protein sequence. Three filters (AminoAcidCounts, DipeptideCounts, and KideraFactors) summarize the content of a sequence but retain no positional information. Each of these three filters accepts an option flag (-R) that, when turned on, normalizes the extracted features by the length of the sequence, n (or n − 1 in the case of DipeptideCounts). OneHotEncoding and BlosumEncoding encode each amino acid (position) in the sequence as a vector. OneHotEncoding achieves this by setting one of twenty elements in each vector to unity to denote the amino acid in the sequence. BlosumEncoding encodes the amino acid by its row in the BLOSUM62 matrix. Because the dimensionality of the output for these two filters is a function of the sequence length, the input sequences must be of equal length. Variable length sequences can be made equal in length either by trimming or by applying the SlidingWindow filter, the sixth filter provided by WeSeqMiner. It creates overlapping sequences of equal length from a larger sequence. Because WeSeqMiner conforms to the Weka API, it benefits from many of the features offered by the Weka ecosystem, including knowledgeflow pipelines.

Case Study
Phage display selections were carried out using a well-characterized single-framework synthetic antibody library named Library-F [1,5]. Five rounds of solid-phase panning were conducted against seven recombinant protein targets (full-length extracellular domains of Notch1, Notch2, Notch3, Jagged1, Jagged2, Axl and Mer) as described previously [6]. After each selection round, the CDRH3 region was amplified from the phage selection output and subjected to Ion Torrent next-generation sequencing [7] on an Ion Personal Genome Machine according to manufacturer's instructions. Following Ion Torrent sequencing, base-called reads were parsed by barcodes, quality trimmed, and filtered. Filtered sequences were translated, identified, and counted. A Weka knowledgeflow was constructed to assess the relative effectiveness of features extracted by WeSeqMiner classes for predicting the enrichment of CDRH3 sequences during the antibody selection process [2] against any of the seven targets.
The knowledgeflow incorporated five analyses. Analyses 1-3 used each of the feature sets produced by the filters AminoAcidCounts, DipeptideCounts, and KideraFactors with a random forest (RF) classifier. A RF classifier was selected because it (1) is capable of discovering complex relationships between predictor and outcome variables, (2) naturally resists overfitting, and (3) requires minimal configuration. The 4th analysis tested the union of features produced by the filters with an RF classifier. The 5th analysis required no feature extraction, accepting the raw sequence as input and using a string kernel SVM. The dataset used in the analysis was a balanced collection of both sequences that were not observed after 5 rounds of panning ("negatives"), and sequences that were still present after 5 rounds of panning ("positives"). Ten-fold cross-validation was used to evaluate the accuracy of each classifier resulting from the training.
The accuracies of the five trained classifiers were 84.4% (all features + RF), 82.0% (amino acid counts + RF), 83.9% (dipeptide counts + RF), 77.8% (Kidera factors + RF), and 82.0% (raw sequence + SVC). For the four RF classifiers, the threshold of votes was varied to determine the receiver operating characteristics (ROCs). The ROC curves are shown in Figure 1. With the exception of performance visualizations, which were generated using Python, the pipeline was built and executed entirely within the Weka workbench, obviating any need to write program code.

Conclusion
Our case study showed that WeSeqMiner adds to the Weka ecosystem a convenient method for extracting features from sequence data, such that models can be built, trained, and tested on this feature data using Weka. With the help of WeSeqMiner it was shown that four feature sets are comparable in their ability to predict clone enrichment, with the combination of the three feature sets performing the best. It was also shown that there are patterns in Library-F CDRH3 sequences that can predict the enrichment against any of the seven different targets. WeSeqMiner could be used to carry out similar analyses in other settings. For example, WeSeqMiner could be used with data from epitope arrays, where one is interested in relating amino  acid sequence properties to the flourescence of the peptides on the array. Such a relationship would be of interest to researchers because this flourescence indicates the presence of bound serum antibodies; therefore, the relationship could be used to screen peptides during array design to maximize the number of epitopes placed on the array.

Funding
This work was supported by the National Science and Engineering Research Council.


LIMoSim: A Lightweight and Integrated Approach for Simulating Vehicular Mobility with OMNeT++

Reliable and efficient communication is one of the key requirements for the deployment of self-driving cars. Consequently, researchers and developers require efficient and precise tools for the parallel development of vehicular mobility and communication. Although current state-of-the-art approaches allow the coupled simulation of those two components, they are making use of multiple specialized simulators that are synchronized using interprocess communication, resulting in highly complex simulation setups. Furthermore, the compatibility of those simulators requires constant attention as they are developed independently. In this paper, we present a lightweight and integrated approach for simulating vehicular mobility directly in Objective Modular Network Testbed in C++ (OMNeT++) and INET without the need for external tools or Interprocess Communication (IPC). The proposed framework Lightweight ICT-centric Mobility Simulation (LIMoSim) is available as Open Source software and can easily be combined with other third-party extension frameworks for providing vehicular mobility based on well-known microscopical models. In contrast to existing approaches, the amount of necessary preprocessing steps for simulation setups is significantly reduced. The capabilities of LIMoSim are demonstrated by a proof of concept evaluation in combination with the Long Term Evolution (LTE) simulation framework SimuLTE.

I. INTRODUCTION
OMNeT++ [1] is a well-established network simulation framework available as Open Source software for academic usage. Because of its modular approach, it has been extended by many third-party frameworks focusing on specialized communication technologies like LTE and IEEE 802.11p. As we have shown in previous work [2] the performance and robustness of communication systems can be highly improved by integrating knowledge of the users' mobility behavior into the routing decisions. With the deployment of autonomous cars in the near future, information about planned trajectories becomes available in all those vehicles and should be exploited for decision processes in the next generation of intelligent communication systems. With the increasing amount of interactions between mobility and communication, engineers and developers require efficient tools for simulating both aspects at once. Although current state-of-the-art frameworks already allow the coupling of specialized simulators for the two individual aspects, this approach has a number of system-immanent disadvantages (cf. Sec. II) because each of those simulators was developed for a very isolated field of application and not intended to be combined with others. In this paper, we present a lightweight framework for simulating microscopic vehicular traffic based on well-known models. In contrast to existing approaches, the proposed LIMoSim is intended to be used by communication simulators by design. It is seamlessly integrated into OMNeT++ (cf. Fig. 1) and requires no external tools or synchronization through IPC. Furthermore, it is completely compatible to third-party extension frameworks like SimuLTE [3] and INETMANET, which can integrate the novel mobility modules into their simulation scenarios in a transparent way using the widely-used INET framework. The rest of the paper is structured as follows. After discussing the related work, we present the basic architecture of our simulation model and provide a detailed description about the integration of LIMoSim into OMNeT++. In the next section, we describe the simulation setup for a proof of concept evaluation scenario in an LTE-context. Finally, detailed simulation results are presented and discussed.
II. RELATED WORK Vehicles in Network Simulation (Veins) [4] is a wellestablished simulation framework for simulating Vehicular Ad-hoc Networks (VANETs) in OMNeT++. It provides an implementation of IEEE 802.11p and acts as an interface to the microscopic traffic simulator Simulation of Urban Mobility (SUMO) [5]. Both simulators are synchronized through IPC using Transmission Control Protocol (TCP) and the dedicated Traffic Control Interface (TraCI) protocol of SUMO. While this approach ensures highly precise simulation results for both communication and vehicular mobility through usage of specialized simulators, it has a number of disadvantages:  release. When we started to work on LIMoSim, Veins was not compatible to the newest SUMO version. • For mobility-aware communication applications, TraCI is the bottleneck for the development process. The protocol needs to be extended for every new information type that should be shared between the simulators. • Simulation setups have a high complexity because different tools have to be executed simultaneously. This aspect is even more dramatic for massive simulation scenarios that are executed on multiple servers in parallel. Additionally, even the generation of SUMO-only scenarios from OpenStreetMap (OSM)-data is quite complex, as several preprocessing steps are required. • SUMO itself is rather designed for being used in a static way using precomputed data (for example routing paths). This does not match well with highly-dynamic vehicular applications, where the mobility behavior influences communication processes and vice versa. Since the IPC-approach using SUMO is the current state-ofthe-art way for simulating vehicular mobility in OMNeT++, those disadvantages are propagated to third-party extension frameworks like INETMANET and SimuLTE as well, if they want to make use of vehicular motion.
Consequently, we think the OMNeT++ community could benefit from a more diverse way for simulating vehicular mobility depending on the application scenario. While the current approach using Veins with SUMO is fitting for many IEEE 802.11p applications, there are scenarios where Veins could be coupled with our proposed framework to avoid the SUMO overhead and the need for IPC. Additionally, the complexity of many LTE and Mobile Ad-hoc Network (MANET) scenarios can be significantly reduced by using LIMoSim only.

III. INTEGRATION OF LIMOSIM INTO OMNET++
LIMoSim focuses on highly dynamic traffic scenarios where all decision processes and routes are determined at runtime. Its main field of application is the simulation of medium-sized city scenarios, where intelligent vehicles interact with other traffic participants through means of communication. In this context, the simulation of vehicular mobility is considered as a service for the simulation of communication systems.
The simulator consists of two main components: the simulation kernel with the different elements of the microscopic mobility models and the User Interface (UI) part for standalone vehicle simulation and the road editor for easy generation of new mobility scenarios. It furthermore features live visualization of statistical data in dynamically updated plots and contains export functions for vector graphics. In this paper, we focus on the simulation kernel of LIMoSim, as it is the only component that is linked to OMNeT++ and provide descriptions of the hierarchical mobility model and the event handling mechanism in the following subchapters.

A. Simulation of Vehicular Mobility
The LIMoSimCar.ned module extends the MovingMobili-tyBase.ned module of the INET framework and acts as a logical structure for the different mobility-related submodules. Its hierarchical structure is illustrated in Fig. 2 are interfaced through a Simple Module, the respective parameters can be set for the .ned-file without requiring external configuration files. An example configuration is shown in Fig. 3, where a User Equipment (UE) is assigned with the LIMoSimCar mobility type and positioned on a specified way segment. Furthermore, the Trip strategic mobility model is configured to sequentially approach multiple destination points (cf. Fig. 5). The ids originate from the OSM data model and can be obtained using UI of LIMoSim.

B. Embedding LIMoSim-Events into OMNeT++
The Discrete Event Simulation (DES)-coupling mechanism is illustrated in Fig. 4. Since LIMoSim can also be used in a standalone mode, its objects are not aware of their OMNeT++environment. The integration into the event handling mechanism is performed by a virtual event queue that does not take OMNeT++ events into consideration. In contrast to the IPCbased approach, there is no need for real DES-synchronization, as only a single queue is used. If an event e is scheduled, the event mapping singleton creates a new OMNeT++ cMessage m and stores a map entry for original event. m is then inserted into the OMNeT++ event queue. Once the handleMessage() method for m is called, e is retrieved from the map entry and handled by the respective object. With this approach, the actual event handling in OMNeT++ is transparent for all LIMoSim objects. Moreover, LIMoSim objects can use the event handling mechanism of OMNeT++ without even requiring an actual OMNeT++ module. As a consequence, objects that only influence the vehicular traffic but do not contain communication modules (like interference traffic or traffic signals) do not need to be modelled in OMNeT++.

A. LTE-scenario with Real-world Map Data
As a realistic scenario, real-world map data from OSM is used. An LTE-enabled car is monitored while it is driving around the campus area of the TU Dortmund University using a Trip strategic mobility module. 100 other cars act as interference traffic with Random Direction mobility and influence the mobility behavior of the considered car. The area is covered by three different Evolved Node Bs (eNBs), which have been positioned according to network provider information. Fig. 5 provides an illustration of the described simulation setup. Due to the mobility of the car, multiple HOs are required at runtime. For the considered car, the current velocity, acceleration and the Received Signal Strength Indicator (RSSI) of the LTE link are measured over the trip duration and shown in Fig. 6. The graphs for velocity and acceleration show typical innercity characteristics and mirror the traffic dynamics of the scenario. Due to the map topology, the traffic signals and the other traffic participants, the current street condition is under constant change. Therefore, a lot of braking and accelerating is required, causing a highly dynamic velocity behavior. The RSSI of the LTE signal shows plausible characteristics depending on the distance to the current serving eNB. Four handovers occur during the considered time (for the actual handover locations cf. Fig. 5). With HO2, the device attaches from eNB2 to eNB3 and shortly afterward back to eNB2 with HO3. This ping pong behavior can be considered as a motivation for further research in the interdependency of communication and mobility, as the handovers could have probably been avoided using a mobility-aware decision approach. In earlier work [8], we have performed a similar case-study using a different toolchain with SUMO and an analytical LTE model, which achieved similar results for the handover behavior.

B. Example Behavior of the IDM model
In order to analyze the effects of the IDM model on the traffic dynamics, we consider a typical street scenario. Fig. 7 visualizes the acceleration behavior of multiple cars in a spacetime diagram. The cars start in a jam situation, which is then  resolved into free traffic. After about 700m the cars encounter a car with engine failure that causes another traffic jam as only a single lane is used. Different driver behavior types can be identified depending on the slope of the curve. The results are confirmed by the analytical evaluation in [9].
V. CONCLUSION In this paper, we presented the novel framework LIMoSim 1 for simulating microscopic vehicular mobility directly in OMNeT++. In contrast to existing approaches that treat vehicular mobility and communication separately and require IPC for the synchronization of different simulation tools, our 1 Available at https://github.com/BenSliwa/LIMoSim proposal brings these aspects together in an integrated way. The actual mobility simulation relies on well-known models in order to guarantee the required accuracy. The easy integration is especially attractive for LTE and MANET simulations, which can make use of vehicular mobility without requiring a complex simulation setup. The capabilities of LIMoSim were demonstrated with a proof-of-concept evaluation in an LTEcontext using real-world map data from OSM. In future work, we want to couple LIMoSim with Veins for the simulation of IEEE 802.11p networks. LIMoSim could serve as an alternative to SUMO providing a lightweight solution for simulating vehicular motion without the IPCoverhead. Furthermore, we want to integrate strategic mobility models that are closer to human decision making like Small Worlds In Motion (SWIM) [10], which has already been applied to OMNeT++ in [11] and utilize the framework for the simulation of indoor robotic networks in a logistical context. Moreover, we want to exploit the visualization capabilities of the UI-part of LIMoSim to enable live visualization of OMNeT++ key performance indicators.


extfieldsofstudy:
Computer Science
Medicine

text:
Don’t make cache too complex: A simple probability-based cache management scheme for SSDs

Solid-state drives (SSDs) have recently become a common storage component in computer systems, and they are fueled by continued bit cost reductions achieved with smaller feature sizes and multiple-level cell technologies. However, as the flash memory stores more bits per cell, the performance and reliability of the flash memory degrade substantially. To solve this problem, a fast non-volatile memory (NVM-)based cache has been employed within SSDs to reduce the long latency required to write data. Absorbing small writes in a fast NVM cache can also reduce the number of flash memory erase operations. To maximize the benefits of an NVM cache, it is important to increase the NVM cache utilization. In this paper, we propose and study ProCache, a simple NVM cache management scheme, that makes cache-entrance decisions based on random probability testing. Our scheme is motivated by the observation that frequently written hot data will eventually enter the cache with a high probability, and that infrequently accessed cold data will not enter the cache easily. Owing to its simplicity, ProCache is easy to implement at a substantially smaller cost than similar previously studied techniques. We evaluate ProCache and conclude that it achieves comparable performance compared to a more complex reference counter-based cache-management scheme.

Introduction
As circuit, manufacturing, and architectural innovations have led to attractive flash memorybased solid-state disks (SSDs) from a performance-cost perspective, SSDs have become a common storage component in recent computer systems. In terms of cost, the main driver has been smaller feature sizes and multiple-level cell technologies such as multi-level cells (MLCs) and triple-level cells (TLCs).
However, as the flash memory stores more bits per cell, the performance and reliability of the flash memory will be substantially lower than when storing fewer bits per cell. To address this problem, a fast non-volatile memory (NVM-)based cache is widely used in modern SSDs.
Any kind of NVM devices can be used as a cache for SSDs. For example, phase-change memory (PCM) or spin transfer torque magnetoresistive RAM (STT-MRAM) can be used as PLOS  an NVM cache memory. Besides, some portions of a flash memory can be exploited as an NVM cache by applying a special mode that reduces the number of bits stored per cell (e.g., TLC ! MLC or MLC ! SLC) [1]. An NVM cache can enhance the performance of SSDs by reducing the long latency to write data. Furthermore, absorbing small writes with a fast NVM cache can also reduce the number of flash memory erase operations by ensuring that garbage collection targets behaving more uniformly, thereby prolonging the lifetime of the flash memory.
Regardless of what NVM device is used, developing an efficient cache-management scheme is first essential for maximizing the NVM cache utilization. More frequently written data (i.e., hot data) should be classified and maintained in the cache with minimum space and computational overhead. Increasing the amount of hot data maintained within the cache leads to higher performance and longer lifetime.
In order to maintain a higher hit ratio, and therefore maximize the cache utilization, various mechanisms have been proposed for SSDs [2][3][4][5][6][7][8][9]. However, these schemes require either high computational overhead or significant memory space, both of which significantly affect the cost of the storage system and mitigate the effectiveness of the cache.
This paper investigates a data caching management scheme that exploits the characteristics of a multiple-level cell flash memory. Based on the concept that frequently written hot data will eventually enter the NVM cache with a high probability, and that infrequently used cold data will not enter NVM cache easily without any extra work, we introduce probability based decision making, which is called ProCache. ProCache is fairly simple and can be implemented practically in a real system because it does not require any complex data structures or extensive computations-just throw the dice! We first show sensitivity analysis studies by performing simulations using the block traces that are collected from real machines. Then, for comparison purpose, we implement an SSD emulator including our proposed scheme along with relevant caching techniques. The results obtained from various perspectives show that the proposed scheme efficiently maintains a high hit ratio, and therefore enhances the overall performance over time and the storage ages. Specifically, ProCache exhibits a performance of up to 16.2%, which is on average a 7.6% better performance, and efficiently decreases the number of write operations by 19.3% and erase operations by 14.0%.
The remainder of this paper is organized as follows. In Section 2, we discuss some related work on this research. In Section 3, we explain the algorithm of the proposed scheme, while in Section 4, we discuss the trace-driven analysis results. Then, in Section 5, we describe the experimental setup and performance comparison results using an SSD emulator. Finally, we conclude this paper in Section 6.

Background
In their early work of 1997, Chiang et al. proposed a flash memory server (FMS) in order to reduce the number of erase operations in flash memory [2]. While FMSs exhibit good hot and cold data classification performance, they require a large amount of memory space because they must retain the last access time information of all LBAs. Unlike FMS, our probabilitybased scheme does not require recording for each set of LBA information for hot/cold data classification.
In a later work, Chiang et al. propose a new data reorganization method called dynamic data clustering (DAC) [3]. DAC dynamically clusters data not only during segment cleaning, but also during data updates. Our approach is fundamentally different from DAC, and does not require any substantial data management operations.  [4]. This two-level LRU scheme consumes less memory than FMS; however, it incurs other problems. The performance of hot data identification is totally dependent on the sizes of the lists. In other words, a small hot list can save memory space, but its prediction accuracy degrades because hot data may be demoted to the candidate list or may even be evicted from the candidate list. Moreover, this scheme incurs relatively high computing overheads to maintain LRU information. Our scheme does not maintain any LRU information or separate lists to classify LBAs.
Chang considers the size of write requests in his hot/cold prediction scheme [5]. We find that our approach and this size-based prediction approach are orthogonal. The write request size may provide us with useful hints. For example, depending on the size, we may apply different probability values when determining whether to insert the data into the cache.
There are schemes that track hot/cold data using compact tables. Hsieh et al. adopt K independent hash functions to hash a given LBA into multiple entries of an M-entry hash table to track the write count of the LBA [6]. Whenever a write is issued to the FTL, the corresponding LBA is hashed simultaneously by the hash functions. Each corresponding table entry (counter) to which the hash values point is incremented by one to reflect the fact that the LBA is written. In order to track the temporal access pattern changes, the counters are decayed (by dividing each entry by two) periodically. This approach can be fairly accurate, but is too expensive for application in a practical system with a large capacity.
In another study, Park and Du adopt a set of V independent Bloom filters (BFs) and K independent hash functions [7]. The weaknesses of the multiple hash function approach are: (1) the memory requirements of tables increase as the capacity of the storage device increases, and (2) computing K hash values and manipulating multiple tables may incur additional computational overhead.
Jung et al. propose a new hot/cold identification scheme that uses process identification (PID) as a hot/cold indicator [8]. The weakness (or strength) of this scheme is that it utilizes the information in the OS, which is generally not available inside a storage device. Our scheme does not require the OS level information in the core algorithm.
Finally, Kim et al. argue that the hot data (e.g., file system metadata) may be effectively compressed, while the cold data (e.g., multimedia data) may not be because they are already encoded [9]. In itself, the merit of this scheme is limited owing to the required computation overhead (unless compression is always performed for the purpose of saving storage capacity). It is also unclear whether the proposed method is more accurate than other previous ideas. In addition, our scheme uses the frequency of data accesses, which we believe is more general and accurate. Fig 1 depicts the key components of the typical flash memory-based storage system, a host interface, an SSD controller, an NVM cache, and a NAND flash memory array. To handle read and write requests that are issued from an operating system via a host interface, an SSD controller reads or writes data according to the request type.

Probability-based cache management
We propose a probability-based cache-management algorithm, which we call ProCache. ProCache is built on the simple probabilistic principle that repeated trials with a small probability of success will eventually result in success.
At the heart of our algorithm is the probability-based data classifier. In its baseline form, the input to the classifier includes p(0 < p 1), which is the probability of declaring that the current input is hot, and c, which is the cut-off size that determines whether a write is "too" large. One may expand the notion of p to a vector, p Ã = (p 0 , p 1 , p 2 ,. . ., p N−1 ). In this case, given the request size of C, p dlog 2 ce is selected for the test. In this way, one may eliminate the second parameter c, or, depending on the choice of N, 2 N−1 may become the new c.
The goal of designing a ProCache is to prove that the proposed probability-based NVM cache management concept can be implemented practically in a real system. Upon receiving a new write request, ProCache works like the Algorithm 1. As shown in the Algorithm 1, the proposed ProCache is fairly simple and easy to implement.

Algorithm 1 ProCache algorithm if the requested block is already in the cache then
It is hot data. Update corresponding NVM cache data. else if the request size ! c then It is cold data. Send it to the NAND array and invalidate any data in the NVM cache that overlaps with the request. else Generate a random number r, 0 r 1. if r < p then The write request passed the probability test and is considered hot. Insert it to the cache and invalidate any data in the cache that overlaps with the new data. else The data is cold, and send it to the NAND array and invalidate any data in the NVM cache that overlaps with the request. end if end if end if On the other hand, its effectiveness is expected to depend largely on the choice of p and c. Our preliminary study using a trace-driven simulation methodology shows that the proper choice of p and c is important for the above algorithm to perform well. First, we examine the algorithm theoretically before analyzing the initial experimental results.
The average number of trials needed to make an LBA "hot" is, given p, follows the geometric distribution: The above series boils down to 1/p. That is, if p = 0.1, the expected number of trials is 10 before an LBA is considered hot. If p = 1, the first trial will declare the LBA to be hot. In turn, in order to verity that hot data will usually have repeated access count of R on average, we can set p to be simply 1/R. Likewise, we can compute the probability that a "cold" LBA, which has K-th accesses, is not identified as "hot." This probability is equivalent to one less the probability of this address being declared hot within K trials. That is, When p = 0.1 and K = 3, the above probability is 0.729, adn when p = 0.05 and K = 3, the above probability is 0.857. The above result implies that with a sufficiently small p, the probability of having cold data enter, and thus pollute, the cache is not high. In other words, cold data are kept off the cache with a high probability of over 72% or 85% when p = 0.1 and p = 0.05, respectively (when K = 3).
In summary, the proposed probability-based hot data classification algorithm is simple and easy to implement. As long as there is a wide gap in the access frequencies between hot data and cold data, the probability-based classifier with a small p will effectively distinguish them. If it is important to quickly classify hot data, we need to have a reasonably large p. If preventing cache pollution is important, we need to keep p small.
For comparison purposes, we introduced an off-line optimal cache-management algorithm. Basically, replacement policies identify the block that will be used in the furthest future for a better cache memory utilization. Belady's off-line algorithm discards the information that will not be needed for the longest time [10]. Even though off-line algorithms are the most efficient cache-replacement algorithms, it is not able to adapt them in real systems because it is impossible to predict the future. We note that off-line algorithms are not for real implementation, and are developed to expose insights about what the on-line ProCache algorithm can or cannot achieve.
Our off-line algorithm is derived from the well-known Belady's algorithm. We add the notion of "bypass" to Belady's algorithm: If the newly requested data will not be needed again for a time longer than all the information already in the cache, we bypass the caching of this data; otherwise, we follow Belady's algorithm.
In the example shown in Table 1, we consider four successive requests for a given current cache status. Each pair of numbers (such as (1,4)) represents (LBA,next), where LBA is the logical block address of a request, and next is the logical time when the same address is next requested in the future. In the first case, read (1,5). The request hits in the cache (LBA 1 is in the cache) and the next access time of the cache entry is updated (from 4 to 5) based on the next access time of the new request. In the second case, read (5,8). Then, the request misses in the cache. Moreover, because this request is a read, we do not cache the logical block in the cache. Next, for the new request, write (1,6). There is a hit in the cache and the corresponding cache entry is updated with the next new access time. Finally, the request write (5,8) misses in the cache. Because this request is a write, we need to determine whether it should be inserted into the cache. Using the original Belady's algorithm, this request is inserted and the logical address 4 is evicted because its next access time (7) is the largest of all that are in the cache. On the other hand, if cache bypassing is enabled, the logical address 5 is not inserted into the cache because its next access time (8) is larger than that of any address in the cache.
Note that in our off-line algorithm, we label each access in the trace with the next access time information before we process the requests in sequence from the beginning according to the method described above. As such, the off-line algorithm utilizes the knowledge about future references to a given address.

Trace-driven analysis results
We used two traces for experiments, as summarized in Table 2. Traces were collected from a working desktop PC using the Windows PerfMon facility. As shown in the table, traceS is relatively short (a few days' amount) and traceL is relatively long (at least a week's amount). The cumulative write count of traceL is shown in Fig 2. Please note that the cumulative write count of traceS is very similar to that of traceL. Note that traceS is from a typical office computer and traceL is from one that is for development. The main metric that we used in this section is the write hit ratio, which is the ratio of the number of write transactions that hit in the cache to the total number of write transactions. Warm-up refers to running the given trace through the algorithm to "warm up" the write cache. We consider warm-up because the traces that we study correspond to only several days of storage traffic. Then, we repeated warm-ups to artificially amplify the traffic. We did not measure the   performance of the ProCache algorithm during the warm-up iterations. We studied the effect of warm-up separately in Section 4.4, and we make several observations. ProCache is a write cache as described in Section 3. To quantitatively evaluate the performance of the scheme, we measure the cache hit ratio. The hit ratio is calculated by dividing the write hit count by the number of requests, and is between 0*100%.

Comparison of off-line and ProCache algorithms
• The hit ratio of the off-line algorithm is high, from the smallest to the largest cache size that we examined, and the difference between the smallest and the largest cache sizes was small. This implies that the working set size is fairly small. The write hit ratio was as high as 80% or higher. •

Effect of p
As was previously discussed, p is the main parameter employed in the probability-based hot data classification algorithm. Fig 4 depicts the effect of p on the write hit ratio for both traces.
• In general, with respect to the examined metric (write hit ratio), a large p performed better than a small p.
• The highest write hit ratio that was observed was about 38% (traceS) and nearly 70% (traceL).
• The difference between the smallest and the largest p examined (0.1 and 1) increases with the cache size for both traces. Interestingly, the gap is narrower with traceL than traceS. We find that if we study for a much longer time span, a small p will perform fairly close to a large p, especially when the cache size is small.
• Based on the result, if the available cache size is large, an interesting approach may be to use a large p to capture the majority of the initial write data. Then, we adjust p as the cache occupancy approaches 100%. • A large c does not perform as well as a small c if the cache is small. Conversely, a large c performs better than a small c when the cache is large.

Effect of c
• With a large c, there appears to be more cache pollution (using large data). It has been reported that large data are reused less than small data.
• The result reveals that c is an important parameter for traceS. However, the impact of c becomes less significant with traceL, which is much longer than traceS. For traceL, p appears to be more important than c (Figs 4 vs. 5).
• The result also suggests that the write hit ratio is determined primarily by small writes (32 KB or smaller) if one observes write traffic for a sufficiently long time (traceL).

Effect of warm-up
While our traces are non-trivial, they only correspond to disk usage for a few days. As such, our trace-driven simulation method may not fully expose the characteristics of a cache-management scheme (as indirectly implied by the results in previous sections). In order to quantify the potential limitation of the trace-driven simulation methodology, we studied the effect of "warm-up" of the write cache by running the same trace multiple times before measuring the result. The proposed experiments will artificially increase the number of writes. Fig 6 reports four results: warmup-N has N warm-up runs before we perform the final measurement run. We observe that: • With warm-up, the write hit ratio increases and the warm-up effect is more visible with a large cache and when the trace is small. This result follows from the fact that repeated warmups increase the number of writes seen by the cache, implying that the probability that write data will be kept in the cache is higher.
• With many warm-ups (16 or 64), the write hit ratio becomes fairly high for traceS, and this is partly because the write requests that occur for the first time in the trace may hit in the cache (because the cache has been warmed up artificially).
• Warm-up has little effect for traceL because this long trace has many requests. Moreover, with the high probability considered in the experiment (p = 0.5), there is a high feasibility that most repeated writes are all cached.
• Our result suggests that we should be extremely careful when using a relatively short trace to study the behavior of a storage device. Still, the benefit of using traces is that we can perform deterministic experiments.

Setup and workload
The above-mentioned results motivate us to develop a new on-line emulation infrastructure. This infrastructure is expected to help us overcome a few shortcomings of the existing tracedriven simulation approach. With trace-driven simulation, it is hard to predict the actual execution time because the interaction of the SSD performance and the system behavior is not captured (i.e., the system condition is different between the time when the trace is collected and when the trace drives the simulation). In addition, trace lengths are typically small in order to conserve the storage space to keep the traces. Lastly, the storage content (e.g., the amount of data that we have at the time of simulation, and the location of the file system metadata) is typically not modeled. The proposed infrastructure is different from the trace-driven simulation method, and is potentially more powerful because: • It emulates the internal components of the target SSD device while the system runs real workloads; • Using powerful processors and high-bandwidth main memory in modern commodity PCs, we can model not only the FTL activities but also incorporate realistic timings of key events (e.g., erase operation and channel contention); and • It becomes possible to create a snapshot of the storage content so that we can repeat emulations predictably under real workloads.
• For a fair and fast comparison, we may emulate many different SSD configurations (e.g.,different cache sizes) simultaneously without having to consider the repeatability of the study.
The new on-line emulation infrastructure allows us to run significantly longer and larger workloads (compared to the trace-driven simulator we developed), and it increases the productivity and reliability of the experiments. Furthermore, it will help us determine the effect of the run-time performance of the on-line algorithm. The trace-driven simulation methodology is limited, and cannot accurately predict the performance impact of the internal working of the SSD on the overall system performance.
We have built our emulation infrastructure on a real hardware system with a dual-socket server having two quad-core Xeon (E5620) and 192 GB of DDR3 DRAM capacity. This large memory capacity allows us to model a realistic SSD device larger than 160 GB, and to employ large realistic workloads that combine the OS and multiple co-scheduled applications.
To the system, our proposed emulation environment is a completely functional SSD storage device, as shown in Fig 7a. It is a driver running in the kernel space that provides a pseudo block device to the host. The environment is a pure software driver, therefore no other hardware is required. Accordingly, the system cannot distinguish our emulated device from a physical device. This implies that with proper virtualization software, we can run workloads on a Linux or Windows (or any other OS supported by the virtualization technology of choice) guest with no modification to the OS itself.
It internally emulates the SSD controller, bus, bus controller, and flash chips, and allows the user to configure the parameters of each component. Specifically, it enables the user to configure the size of the command queue, type of FTL (page, block, and hybrid), number of buses, bus speed, bus controller delay, and various parameters for each flash memory chip including the page size, spare area size, number of pages per block, number of blocks per chip, number of chips, and read/write/erase operation overhead [11][12][13].
At the same time, the timing behavior of the target SSD device is controlled by user-defined parameters, thus giving us emulation capabilities. The emulated SSD controller, bus controller, and each flash memory chip are emulated separately by using the concept of the state machine. Fig 7b shows an example of the operation timing diagram for the write operation. In this example, assume that the emulator has eight command queue buffers, two local buses, and two chips per bus.
When the emulator receives a write command from a host, the request is queued in the command buffer, and is serviced in a first-in first-out (FIFO) manner when the status of the SSD controller module becomes Ready. Then, it changes the controller's status to Waiting, and copies actual data to the SSD controller module, where the controller executes the FTL function during the Waiting state. After that, the controller's status becomes Operating, and it copies the data to the appropriate local bus when the local bus's status is Ready. Before changing each component's status, we artificially emulate the timing overhead as designated by the user.
For the experiments, we set the SSD emulator geometry related parameters, as shown in Table 3, and we used flash memory timing parameters based on a typical TLC flash memory chip specification. Then, we implemented our ProCache into an SSD emulator. The current implementation of ProCache uses a simple LRU-replacement policy. It means that ProCache uses the probability based cache-entrance policy and LRU based cache replacement policy. The LRU policy and its variants base their replacement decision on the age of the references, while the LFU policy and its variants base their decision on the frequency of occurrence of the references [14]. However, note that the use of different replacement policies does not significantly affect the result because of the characteristics of ProCache. We used the Ext4 file system with a 1-KB block size, which is the default block size.
To compare the performance using a realistic workload, we defined a set of common works, as shown in Algorithm 2, which reflects (a little bit heavy) daily common computer  usage pattern. The workload that we used for the experiment consists of four steps. First, we copied the Linux kernel sources from the original directory to a new directory, and we compiled those kernel sources using multiple threads; specifically, we ran 16 threads simultaneously. The storage occupancy of this work is around 6.3 GB. Then, we cleaned the source tree. Secondly, we copied two DVDs and one CD file to a new directory four times. To do this task, we required about 25.2 GB of storage space. Third, we downloaded 2,000 web pages to a local directory. This step required a storage space of about 130 MB. Finally, we removed the newly created DVDs, CDs, and web pages. This workload shows various potential write patterns, that is, a mixed-size random pattern for the first step, a long sequential pattern for the second step, and a short sequential pattern for the third step.

Deciding c, p and cache size
We first have to determine three parameters, namely c, p, and the cache size. To determine the appropriate values, we measured the hit ratio of each configuration when the workload shown in Algorithm 2 is executed. Both Figs 8 and 9 show the variation in the hit ratios as we varied c, p, and the cache size. In Fig 8, we considered only the requests that were the same or less than the cut-off size for calculating the hit rate, while we considered all requests for Fig 9. The results obtained from a real workload on a real machine confirmed our findings of trace-driven studies.
• For the small c (1 KB and 4 KB), a small p exhibits a better performance for a small cache size, but a large p is appropriate for the larger cache size.
• For the large c (8 KB and 16 KB), a large p is suitable.
• In the case of a 'hit', the data from the cache are used for requests whose size is larger than c. Therefore, the hit ratio values of Fig 8 are very high.
• The use of 16 KB for c is somewhat large for a real workload.
• The highest hit rate value was obtained when c = 8 KB, p = 0.1, and the cache size is 1 GB.
Although the hit rate is less than 4% when we consider all of the requests, our cut-off idea significantly affects the performance of the storage system because • The storage system performance is significantly affected by small random writes [15,16].
• The metadata update of file systems incurs frequent synchronous small write operations, which exhibits extremely hot behavior. For our workload, 24.6% of the total requests were issued by only 1.5% of the small write volume, which was also observed in [17,18].
• It is extremely important to reduce the number of small write operations, especially in flash memory-based storage systems because of their merge operation overhead [19].
As expected, if there is more cache memory, there may be a greater performance gain. Furthermore, there is a direct correlation between the effectiveness of the proposed idea and the parameters, and the performance of the idea is highly dependent on workloads. However, we need to choose a reasonable cache size. As a result, for the performance comparison experiments, we set c as 8 KB, p as 0.1, and the cache memory size as 1 GB, which will be described in the next section.

Performance comparisons
In this subsection, we compare our proposed ProCache with the reference counting scheme proposed by Hsieh et al. [6]. The reference counting scheme maintains a saturating counter for each logical block number to be tracked. For comparison purposes, we implemented the pure LRU scheme (denoted as BASE), and the reference counting scheme (denoted as REFCNT) The detailed algorithm used to implement the reference counting scheme is shown in Algorithm 3.

Algorithm 3 Reference counting scheme.
Initially all C n have a value 0 Every once in a while (after physical or logical time t), decay all C n (e.g., shift right) For each write if C i < threshold then For the comparison, we set the SSD emulator parameters for cache memory to be the same as that of the SLC flash memory, while we used the TLC flash memory parameters for the remainder of the main storage area. For both the ProCache and reference counting scheme, we set the cache size as 1 GB and the main flash memory storage size as 32 GB, and for the baseline, we used 33 GB of flash memory.
We first measured the elapsed time for executing the workload described in Algorithm 2. Fig 10 shows the performance results of the baseline, reference counting scheme, and our proposed ProCache.
ProCache provides up to 16.15% (7.57% on average), better performance than the baseline owing to its efficient cache-management mechanism. In particular, it provides notable performance for workloads that have small random write behaviors, including kernel source compile, clean, and web page downloads. As expected, it is clear that there is no or worse performance gain for the file copy workload because it has a very long sequential cold write pattern. This means that we can further enhance the performance if we can carefully bypass such a long sequential write pattern. ProCache exhibits a slightly better performance than the reference counting scheme (1.97% on average). Note that the reference counting scheme requires significant RAM space, while ProCache does not. Specifically, the naive reference counting scheme requires 1B for each 512-B block. Therefore, a 512-GB drive requires a RAM overhead of *1-GB. The bloom filter can reduce this overhead at the cost of an increased number of memory accesses and false positives. It is very important to reduce the RAM space requirements when applying the proposed techniques to real-world consumer electronics. Fig 11 shows the results of write and erase count comparison between ProCache and the reference count scheme. Both schemes efficiently decrease the number of write and erase operations, which directly affects the lifetime and performance of the flash memory-based storage system. Specifically, ProCache decreases the number of write and erase operations by 19.3% and 14.0%, respectively. These results explain the reason for which ProCache shows a slightly better performance than reference counting.

Conclusions
We proposed a simple probability-based hot write data caching scheme. It is simple to realize the proposed scheme owing to its low overhead in terms of RAM usage and computation. The proposed scheme was shown to achieve fairly robust effectiveness at a fraction of the implementation cost needed for other techniques. We first evaluated the scheme using trace-driven simulations. Then, we quantitatively characterized the effect of c, p, and the cache size. Based on the realistic SSD emulation environment on a live system, we showed the results of the performance comparison. ProCache exhibits a performance that is up to 16.15%, which is on Based on actual experiments, this paper makes the following contributions: • Determination of c: The main factor is the cache size; if the cache is small, keep c small; otherwise, a reasonably large c will suffice.
• Determination of p: An important factor is the total writable volume to the cache (c also affects this). A small p of 0.1 appears to be suitable when c is 8 KB; a larger p of 0.2*0.4 appears to be suitable when c is smaller.
• We found that an SSD emulator with virtualization software support is very useful for the analysis of the internal and external structure of future SSDs. It is very easy to emulate multiple platforms with many configurations simultaneously, and this enables us to closely examine the traffic of systems in a simple manner.
We envision two potential directions for future research. First, we will explore the combination of p and c. For example, p = P[logs], where P has a decreasing density. Therefore, we can use a different p for a different write size (s). Second, we will consider dynamically adjusting p and c. When the replacement rate is high, it may be that p is too high and c should be decreased.


s2fieldsofstudy:
Computer Science
Engineering

text:
Structural Performance’s Optimally Analysing and Implementing Based on ANSYS Technology

Computer-aided Engineering (CAE) is a hotspot both in academic field and in modern engineering practice. Analysis System(ANSYS) simulation software for its excellent performance become outstanding one in CAE family, it is committed to the innovation of engineering simulation to help users to shorten the design process, improve product innovation and performance. Aimed to explore a structural performance’s optimally analyzing model for engineering enterprises, this paper introduced CAE and its development, analyzed the necessity for structural optimal analysis as well as the framework of structural optimal analysis on ANSYS Technology, used ANSYS to implement a reinforced concrete slab structural performance’s optimal analysis, which was display the chart of displacement vector and the chart of stress intensity. Finally, this paper compared ANSYS software simulation results with the measured results,expounded that ANSYS is indispensable engineering calculation tools.

Introduction to CAE
Computer-aided Engineering (CAE) is a new discipline which began to be developed in the 1960s. This process is a product which is combined with a numerical analysis methods and modern computer technology. With numerical analysis theory methods maturing and rapid development and wide application of computer technology, there is a broad prospects which commonly used CAE for engineering analysis improving design quality and shortening design circle. At that time, there were two fact that brought a great power in development of CAE [1]. One is basic idea of the finite element method which solves the problem of complex structures. In 1943, Courant, on his first attempt, applied the definition in the triangle area of piecewise continuous function and the principle of minimum potential energy to be solved St.Venant torsion problem. The second is wide application and rapid development of electronic computers. In the 1950's, J.Turner for the Boeing company by the United States, and J.H.Argyris in the university of London , puts forward the structural matrix analysis method, applied electronic computers as a major means of operation. The finite element method was developed on basis of this new method. A typical procedure to implement CAE generally consists of five steps, which is showed in Figure 1: establishing mathematical model, selecting optimal algorithm, designing program, developing objectives and requirements, and computer automatic screening optimal analysis scheme. Traditional analysis process is generally completed by the structural engineer with continuously testing according to past experience. Although structure can be improved to a certain extent after modification, but this kind of analysis has certain blindness and uncertainty. The final result is different from person to person. Because of the complexity of the structure, how to adjust analysis and design in order to get better, which is often a difficult problem to solve. Structural optimal analysis is effective method which makes a computer to replace human laborious work. Its research content is the combination of numerical theory and mechanics analysis method. It automatically improves and optimizes the bearing structure analysis in various conditions by establishing a set of scientific, systematic, reliable and efficient methods and software [2].

Lack of dynamic response to a change of parameters relating to design in the process of construction
In the process of structural analysis, there is a change of parameters relating to design in each step of the site construction, such as excavation depth, soil conditions, surrounding environment, the additional load, bending moment and shear force acting on the structure, these factors in affecting pouring quality of concrete, and so on. Computer aided structural optimal analysis can provide internal force analysis under various operating conditions.

Lack of scientificity and systematicness in traditional analysis method
The traditional analysis was finished generally by the structural engineer according to past experience. The result is different from person to person. In structural optimal analysis, the amount participating in calculation, one is constant, and other is variable, that forms a whole structure analysis solution domain. The analysis organically unites mechanics concept and optimization technology. Practice proves that the structural optimal analysis can shorten design cycle, save manpower, improve the quality and level of structure design. Economic benefit and social benefit is completely remarkable.

Lack of coordination between the informationization construction and design
We try to establish the concept of work with a computer data process and site data monitor at the core in the process of informatization construction. Traditional analysis cannot provide the data of a whole site construction, unable to form the management value. This make the structural analysis can't realize informatization with the result that its security should be greatly reduced. Structural optimal analysis can provide management data to achieve the design and construction informatization.

The Framework of Structural Optimal Analysis Based on ANSYS Technology
There are three typical analysis process including Preprocessor, Solution Processor and Post Processor.

Preprocessor
The module has two main parts: the entity modelling and meshing. There are two kinds of entity modelling method: top-down and bottom-up. The users define a model primitives, thereby, to directly structure geometry model, such as circular ，rectangular, 3D block, ball, taper and column. When Bottom-up modelling entity, users structure model upwards from the lowest figure yuan ,namely, users first define key point, and then in turn the line, surface, body related to it. No matter using which kinds of method, the user can use Boolean operation to combine data sets, and "sculpture" a solid model. ANSYS program provides convenient and high quality of grid partition function for CAD model. Four meshing are included: extended meshing, image meshing, free classified meshing and adaptive meshing.

Solution Processor
The user can define analysis type, analysis options, load data and load options, then began to finite element solution. Loading is that the boundary condition data descript the situation of actual structure , and analyze the interaction between structure and outside world. There is the meaning of load such as the constrained displacement of freedom degree, nodal force load (force, torque), surface pressure, and inertial load (gravity acceleration, angular acceleration).

Post Processor
A graphic form of the front analysis results can be displayed and output in post-processing. Different lines colors represent different values, different values, and clearly reflect the regional distribution. Different line colors represent different values, numerical areas, and clearly reflect resultant regional distribution. In addition, post-processing can also check results in a time period or a substep process .These results can be viewed by drawing curves or list, in order to help to visualize analysis results [3]. The data flow of analysis is shown in Figure 2.

The experiment survey
There is a reinforced concrete slab of 1000*1000*180mm.Four levels exert concentrated load is applied respectively in the centre of the plate, which is 4kN, 6kN, 8kN, 10kN. Two long sides support slab, and two short sides node are constrained. The node doffs of UY constraints are applied to the slab bottom of Z = 1900 ~ 2000, at the same time, The node doffs of three directions constraints are applied to the slab bottom of Z = 0 ~ 100 [4]. The change state of slab 's displacement and stress in the loading stage is observed and recorded. The accuracy of the numerical simulation analysis is verified by compared with the ANSYS software's calculation cases.

The cloud charts of displacement vector sum.
A concentrated load is imposed on the center of slab. With concentrated load is gradually given an increase of 2kN, slab deflection value begins to expand gradually, however, the deflection value expands greatly slowly. The cloud charts of displacement vector sum are shown in Figure 3. From the figure, the deflection limit distributes the center on the bottom of the slab, whose value is the biggest, while the deflection value decreases in annular state trend on either side of slab [5]. There are four deflection cloud maximum values in the process of per level load, which are shown in Table 1

The cloud charts of stress intensity.
A concentrated load is imposed on the center of slab. As the concentrated load is given an increase of 2 kN, stress intensity concentrates in the center of the slab bottom. The red part is dangerous stress area, which is also the largest stress intensity area of 1.09304 Pa. And then, you can draw a conclusion that stress intensity satisfies the requirement of the strength of material, if it is in the allowed range which is compared with the allowable stress of material. The minimum value is 0.051724 Pa, which is located on the support constraint of slab. There are shown in Figure 4. There are four stress intensity cloud maximum values in the process of per level load, which are shown in Table 2.  In the laboratory, the reinforced concrete slab is loaded with hydraulic jack. There are measured values of maximum deflection for leach level load which are shown in Table 3. As using ANSYS software to simulate results, which comparing with the experimental measured results, we can see that the deflection values of computer simulation are consistent with the experimental result, which is shown in Figure 5. The chart is generally linear in the load -deformation curve chart [6]. The error in process is mainly manifested these great stress concentration in support of slab , which is with the corresponding concrete node displacement coordination; There are inaccurate dockings on working condition, which affect analysis model incorrect constraint and load.  Figure  5.
Comparison ANSYS simulation results with the measured results in deflection

Conclusions
The deflection and stress intensity of slab is simulated and analyzed by ANSYS soft. Although there is error in the calculating result of finite element model, it is basically in accordance with the measured results of experiment on the same change trend. The study shows that ANSYS is indispensable engineering calculation tools which simulate the stress process of slab better. There are some problems in the finite element analysis of this study.(1)Some factors affecting convergence, such as mesh count, convergence criteria, bearing problem, appeared in the process of reinforced concrete slab's nonlinear calculation .
(2)the reason of some error in process of finite element software calculation is that material parameters reflecting the calculation model and the working condition of docking is difficult to determine.

Acknowledgments
The authors would like to thank Shiqi Cui and Bo Cheng from Structure Department at Shandong Academy of Building Research, as well as the anonymous referees for valuable comments and critique during the review process of this paper. None besides the authors, however, can be held responsible for the result.