Project #1: Neural Networks for Concrete Compressive Strength Predictions - An Exercise in Deep Learning Modeling

https://github.com/artemkk/flask-api/tree/master

Table of Contents

Project Summary

I made a Flask API that pulls data from a local PostgreSQL database and pushes it into a *feed-forward* neural network in the aim of predicting concrete compressive strength based on eight constituent features. After doing so, I read the academic paper [1] that sourced me with this data set for the first time. This was done to compare my observations and results to their methods and conclusions as they described their approach to making the same strength prediction. This allowed me to learn, research and deduce important pieces of knowledge on topics such as data exploration, APIs and deep learning at first independently. It then provided me with guidance for further learning and growth by facilitating a comparison of my successes and outcomes to theirs.
 
Table of Contents➜

Learning Outcomes

  • Implemented a Flask API for communication between PostgreSQL database and neural network model 
  • Built functional neural network models and optimized them for increased performance
  • Assessed and visualized neural network performance
  • Learned of the practical application of neural networks for solving regression problems
Table of Contents➜

Project Premise

I was searching for datasets that I'd be interested in turning into a rudimentary data science project kind of centered around a Flask API. This API would be the communication between the database and the predictive model I was wanting to build. I felt that I was interested in exploring something that was a bit familiar to me while I was learning about my first data science model, which gave me the idea to look into data sets on Kaggle that dealt with construction topics. 

I found an OSHA data set detailing construction industry injuries in the United States that I considered, in particular to see how the cost and duration of a job can have an impact on injury frequency (if any). In the same search session, I also found a data set associated with an academic paper regarding concrete compressive strengths as a function of eight constituent materials as a weight per volume basis and the exception of concrete age given in days. Back in like December 2019 I took a class on concrete at the U.S. Army Corps of Engineers ERDC in Vicksburg, MS. I thought this might be a cool crossover I could do with my old career while learning about some portions of the new career. And to add to that, I read the Abstract of the paper that this data set was associated with. The paper was:

"Modeling of strength of high-performance concrete using artificial neural networks" by I.-C. Yeh

It detailed that artificial neural networks (ANNs) are suitable for solving multivariate regression-type problems which deal with the model being able to adequately generalize relationships between independent features and dependent labels. And it was illustrating this by predicting the concrete compressive strengths of various concrete mixtures as a function of eight independent variables.

I thought that it’d be interesting to see how I’d manage making a neural network to make the same prediction as the paper’s author, both in terms of my model’s effectiveness as compared to theirs and just overall what metrics I used and how I chose to present the data as compared to the author. That’s why I didn’t read past the abstract and instead decided I’d go along on my own and compare the results of the paper to my exploration after the fact. Seemed like it’d be more interesting that way.
 
Table of Contents➜

Starting Goals

The idea to create a Flask API came from Seattle Data Guy's YouTube video discussing a Data Engineering Roadmap for 2022 that I first watched December of 2022. In it, he mentioned that a good starting project would be a Flask API and outlined what that would look like in general terms. The API would be implemented by the user to communicate between two or more pieces of code in order to accomplish some goal. 

I decided that my iteration of this project would look like the following:

  1. Establish a database to house data
  2. Pull this data via the API and preprocess it using Python
  3. Push this processed data into a Deep Learning or Machine Learning model of some kind 
  4. Have the model execute and provide the predictive output
  5. Visualize the performance of the model
  6. Deploy the code package into production through a Cloud-hosting service

These were my general project goals. Some of them were met more than others but I’m alright with where I’ve got to so far for the time being. That’s why I’ve chosen to include a Potential Future Improvements section. I contend that the approach of doing first and learning from the eventual issues that arise has its place in my self-learning toolkit.

I came upon the dataset that the model and database portions of my project used by searching for  time available Kaggle datasets that dealt with construction, as I mentioned. I did know I wanted something that would make a prediction of a dependent variable based on some independent variables, which I had read could be accomplished with a regressive solution provided by a feed-forward neural network. I thought that it’d be an interesting idea to do  a kind of amateur “peer” review of the paper by trying to accomplish it’s stated goals on my own without reading past the abstract, which let it be known that neural networks can be used to make such predictions effectively.

For the API itself, I knew from the start that I'd end up making it very simple. It's purpose was to act strictly as a communication interface between the database and the model. It ended up that the only actual outputs on the relevant port and server were the JSON objects of the raw data and nothing else. I would expect there to be some API already out there in existence that would feed the PostgreSQL data into the neural network model directly, without having my API transform it into a JSON object locally and do the same (but I have yet to verify). The inclusion of my own API was nonetheless beneficial for my understanding of what roles APIs can play when it comes to creating software.

Table of Contents➜ 

Constraints & Unknowns

The authors mention that during the evaluation of the 1,030 sample total data set, some of the concrete samples were deleted from the data due to larger size aggregates (larger than 20 mm), special curing conditions, etc. 727 concrete samples made with ordinary Portland cement and cured under normal conditions were evaluated in turn. These are deletions of bad data points that that I didn't do because I didn't have access to the same concrete meta-information that described these secondary characteristics. This realization led to one of the more important lessons out of this project. The importance of knowing the data to an extent that allows for doing the necessary preprocessing to ensure model accuracy. Since this gives the data a uniformity that otherwise can't be accounted for unless it's a known feature. Yeh had to protect the quality of the data by deleting down to a more standardized data set driven by the actual observable kg/m^3 features of the concrete and plus it's age rather than factors external  to the data set and it's data. Unfortunately, since I do not have this information, I decided to run my models on the full 1,030 row data set.

A note on the S1-S4 trials, the A, B, C, D groupings for these trials are described as being procured by a split up of the data set in such a way that the vectors from the different references divided the data set into fourths. The direct quote is "A data base of 727 records, each containing the eight components for the input vector and the one output value (compressive strength), was split in such a way that the vectors from the different references were divided into four data sets: set A, set B, set C, and set D." I don't understand what vectors are being discussed (I assume it's the constituent materials) and more importantly how they were used to dictate the split. This unfortunately means I'm a bit lost when it comes to understanding how the split was done for the S1-S4 trial data set creation. Adding some discussion on this part would have been to the benefit of the paper I think. The alternative to this method was a random sampling of 75% for testing and 25% for training which performed better. This is what I then attempted to replicate but with the full 1,030 sample data set.  

A note on the ratios in Table 2, the paper doesn't seem to mention what binder they're referring to when constructing these ratios and eventually implementing them in Regression Analysis. From my knowledge, cement acts as concrete's most common binder but there are others out there, some even in resin form. But the paper makes the distinction between water to cement ratio and water to binder ratio so it's somewhat unclear. I did not perform a regression analysis nor did I have access to the data set with the full details of the ratios per unique mix. 
 

Project Topics

API

Process 

The API portion of the project was quite rudimentary. As mentioned already, the intent of the API was to facilitate the use of HTTP methods to feed the relevant data from the PostgreSQL database to the model. The information that is returned on the client pages when the API is ran is simply the data set that was fed to the model but in JSON object form. This project started out with more of a focus on the API portion but that was side-lined somewhat by the later focus on the deep learning model. 
 
I spent a good bit of time reading up on APIs to see what kind of things can be built with them and what kind of services they can provide. I was surprised to learn that APIs are often deployed to increase reach and use-cases for a given software and can be done so to great financial benefit as well. Some companies rely on subscription services to their APIs (SaaS) as their main source of revenue. After about 10 or so articles, I was able to get a starter version coded up that could display data pulled from a local csv file. This then was modified to accommodate a MySQL connection, and later a PostgreSQL since that is the database management system I eventually decided on.
 
The connection between the API and the database was simple enough but it was somewhat tricky trying to get the API to then communicate with the model. I had to double-check the HTTP request definitions but eventually managed a functioning solution that involved an HTTP GET request accessing the page on the local server where the data from the database was being stored. With the way I had setup my API to run, this process of data extraction and loading happened automatically. This meant that as soon as the user accessed the correct URL, the API gave the command for the data to be transferred in and the model to be executed. Plots and relevant values were outputted upon completion.
 

Results

The API worked as intended, providing a bridge between two components of my overall project. The PostgreSQL database was able to communicate with the API which in turn was able to communicate with the neural network model, successfully transferring the information it needed out of the database to provide model input for an eventual prediction. This seems to be a valid approach for providing my model access to data, from what I can tell. 

Table of Contents➜

Similarities & Differences

The API idea is what led me to Yeh's paper although this work makes no mention of the use of any kind of API or databases for that matter. Yeh does not discuss his measures for ensuring his model's access to maintained and structured data sets afforded by database management systems such as PostgreSQL. While this may be best practice as it's a component of the overall data science pipeline, it wouldn't exactly fit the paper's narrative. So there's not really any similarities or differences to discuss as it relates to these topics and the content of the work in question, since they're technically out of scope.
 
Table of Contents➜

Learning Outcomes & Improvements

Felt that it was valuable to learn what role APIs play as potential income sources for companies, with some providing a subscription model or Software as a Service (SaaS). Bit of first-time practice setting one up with Flask, as opposed to usually doing it with NodeJs. 

One improvement could be creating a POST request for the user to input certain variables or constituent ratios that could be substituted in in lieu of others. This is done later on in the paper manually when Yeh describes the convenience of using neural network models to review the relationship of each constituent feature as it affects the overall mix strength and maybe even the mix proportions themselves. He provides an experimental verification of how the strength model can be used to study the strength effects of age or water-to-binder ratio. This let's Yeh substitute in the w/b ratio at selected step sizes for the age parameter and create curves that describe their interaction in context of the mix strength. If I were to implement something like this, I'd think the API would be the appropriate place to do it.

Table of Contents➜

Data Set & Data Exploration

Process

I knew from some prior reading that an important component of the machine learning model pipeline was the exploration of the given data set. That's why I decided to create scatter plots with each independent variable plotted as the X-Axis against the Y-Axis of concrete compressive strength. The intent was two-fold: to assess any visual relationship between the individual independent features and the dependent label and to familiarize myself with Python's matplotlib module. 

It was simple enough to get a scatter plot showing the data as intended, and then to repeat that seven more times to get a two by four spread of all the relevant scatter plots. What was a bit tough however, was to get them positioned adequately given the limited real estate and to have the values on the X-Axis not overcrowd. Both obstacles were surmounted with some trial and error though.
 
Table of Contents➜

Results 

It was interesting for me to note a slightly positive plateauing trend in the concrete compressive strength as cement kg/m^3 content increased. One can note that while the points are still spreading out, they're also increasing in slope nonetheless. Age seemingly did not have a significant role in dictating compression strength. Visually speaking, there doesn't seem to be the same degree of influence for the age feature on the target as there is for the cement feature. All the other features didn't have discernible trends, at least visually speaking. 
 
While doing this exploration, I was curious to know if there are ways to identify the most influential features on the target prediction value or if that's part of that hidden layer ambiguity that neural networks are currently and partially characterized by. Turns out that there are and it's briefly discussed in this paper in a somewhat indirect way with the experimental portion and using regression analysis to create water to binder ratio curves as a function of age to then describe the compressive strength. The ability to do so suggests a strong influence of these features on the target prediction value, as far as I understand. Click to expand: 

It also seems as though I was correct in my visual observation of cement content being strongly correlated to compressive strength. It is a binder after all and the constituent-to-binder ratios are what's used to develop the regression coefficients for the regression model portion. This is fleshed out even further during Yeh's discussion of the Abrams’ water-to-cement ratio (w/c) pronouncement of 1918. Abram's identified an inverse proportionality between the w/c ratio and the strength of concrete. His rule asserts increasing the water to cement ratio decreases the concrete compressive strength, and vice-versa. This means that the strengths of various but comparable concretes are equivalent if their water to cement ratios are equivalent as well, regardless of other compositional details. 

This observation implies that the quality of the cement paste controls the strength of comparable concretes and the cement quantity does not matter. 

Sigma 1 being the concrete compressive strength, w1 being the water quantity and c1 being the cement quantity of concrete mix 1 and same for subscript 2 for concrete mix 2.

Yeh goes onto discuss that analysis of a variety of experimental data which shows this to not always be true. He posits an example where the strength of the concrete with the higher cement content (a higher quantity) is lower if two comparable concrete mixtures have the same water to cement ratio.

These are some pretty interesting observations so it was cool to kind of pick up on some whispers associated with it just by doing some simple data exploration and graphing. 

Table of Contents➜

Similarities & Differences

Yeh didn't spend too much time on discussing the data exploration portion in his paper. He included Table 1 which shows the reader the ranges and means for all of the available features plus the label. He goes on to do the same with the various constituent ratios to which are similarly described in Table 2. He didn't display any graphs for the data exploration portion and I'd say that was our biggest difference, with no similarities identified for this part of the work. 

Table of Contents➜

Learning Outcomes & Improvements 

It was good to learn Matplotlib, in particular the techniques necessary to make multi-graph spreads for presenting multiple variable relationships at once. Removing some of the redundant Y-Axis labeling and instead having it on the left-most column of plots only could be a potential improvement.

It would be nice to know what these scatter plots would look like if I knew the 727 samples that Yeh selected knowing the special exclusionary properties (curing, aggregates over 20 mm in size, etc) of the 303 that were deleted. As mentioned before, these are deletions of data points that that I didn't do because I didn't have access to the same concrete meta-information that described a number of secondary characteristics of the available features. These characteristics caused the data points to be considered of a lower quality because they introduced potential relationships into the neural network that it would be able to adequately capture due to a lack of readily available quantitative description. This realization led to one of the more important lessons out of this project. The importance of knowing the data to the extent that allows for the necessary preprocessing to ensure model accuracy.

Noticing a relationship between the cement content and strength from a simple data exploration, and then reading the paper to have that observation be explored with a discussion of the Abram's formulation was really cool too. My observation was that there was a loose positive relationship between increasing the cement content and in result having the concrete mix take a higher compressive strength. Abram's formulation makes the same observation by saying that a lower water to cement ratio results in an increased compressive strength. To make the water to cement ratio lower, one would need to either lower the water content or increase the cement content. This isn't a hard and fast rule however, as Yeh provides an example sourced from a lab experiment of when this isn't the case. In the experiment, two concrete mixes with identical water to cement ratios experience differentiating compressive strengths with the weaker mix being the one with a higher cement content. So cement quality does play a role in strength aside from just it's quantity.

Table of Contents➜

Database

Process

In all, I thought about implementing a total of three viable database solutions, actually managed to connect two, and finally decided on one towards the end of the work. 

I first poked around in MySQL with a free Azure trial account and managed to get that up and running locally. MySQL was the database solution we implemented during my CS 340 Intro to Databases portfolio project, so I was already somewhat familiar with it. However, my trial duration expired before I was able to complete this project so I needed to pick out a different database management system to actually finish up the work. I was considering using the SQLite package in Python given the scope of my work and how agile it was to implement. I ultimately decided to go with PostgreSQL instead. This decision was based on a recommendation from a friend in industry who said that while PostgreSQL would likely be a  bit overkill for the data set in question, it'd be more of a direct comparison to MySQL and ubiquitous in industry. 

It was simpler than MySQL to setup with their GUI being slightly a bit more intuitive. The process of establishing a connection between the database and API was also fairly straightforward, allowing me to extract the relevant data as a JSON object. 

Table of Contents➜

Results

I had a storage solution for the data in the form of a database management system that potentially mimicked a setup one might find in a professional environment.

Table of Contents➜ 

Similarities & Differences

See the similarities and differences section for the API, the same applies here.

Table of Contents➜  

Learning Outcomes & Improvements

I explored some of the more popular database management systems out there, such as MySQL and PostgreSQL, getting a feel for their setup, execution and available features. An immediate improvement for this portion of my project is shared by the other modules as well. It would be better for the database and the rest of the app to be deployed to some Cloud-service provider as that would be the most true to the data science pipeline in industry. 

Table of Contents➜

Neural Network Model 

Process

I started creating my neural network model by first assessing which kind of neural network would be the right fit for my use-case. I knew that it had to be capable of solving problems that could be addressed conventionally by Regression Analysis, that it had to be capable of receiving multivariate feature inputs and providing an in-discrete predictive output, and that I had to be able to measure it's performance so I could attempt to tune it. 

These criteria led me to a number of various tutorials, the best of which was provided by Ahmet Özlü. This tutorial clearly explained a neural network model structure using Keras that would be applicable to my particular use-case. I set out to use this tutorial as the basis for two potential models that I would spend some time experimenting with. Both models were neural networks that made use of feed-forward propagation and back-propagation in order to learn on the afforded training set. The model that I eventually chose to focus my efforts on, Model 2, was slightly more complex than Model 1 and performed slightly better as well.

These are the model structures, with Model 1 on the left and Model 2 on the right. 

The metrics for success that I implemented include the R-Square (R2) measure and  Mean-Square-Error (MSE). R2 represents the proportion of the variance for a dependent variable that's accounted for by an independent variable or variables in a regression model. It essentially explains to what extent the variance of one variable explains the variance of the second variable. An R2 of 0.50 indicates that half of the observed variation is explained by the model's inputs, with the other half being attributed to noise and error. An R2 of 1.0 means that 100% of the variance of the dependent variable being studied is explained by the variance of the independent variables. MSE is the average squared distance between the observed and predicted values, thus measuring the amount of error in a model. A smaller MSE indicates a truer line of best fit through the actual vs predicted scatter plot. This is also why it can be conditional to the data to get a very small value for MSE. I wanted to use both of these metrics since they seemed not only appropriate, but complimentary. I only began to implement MSE when I began to focus on my second model, however.

Table of Contents➜ 

Results

My initial results were poor, with both models performing at R2s of below 0.2 for the testing sets.
 
 

I began to experiment with various regularization techniques and hyper-parameter tuning in turn. My initial success with Early Stopping proved to be the most effective regularization technique I implemented overall. It led to an equivalent performance on both the training and test data sets, at approximately 0.61 R2 for both. Later on, when I began tracking MSE as well, some tuning of the learning rate of the optimizer function Adam, the batch sizes and the decay rate led me to an MSE of ~50 in partnership with Early Stopping. At this point, I didn't think what I had was a amazing but it did seem to be working, and I was growing curious as to how it stacked up against what Yeh had done in his paper. This curiosity didn't stop me from trying out a few other regularization techniques to see their affect on my model's performance. 

Commit d8115b0


 

Commit b7ebbe3

In my subsequent tuning explorations, I decided to focus in solely on Model 2 as it seemed to me that the more complex structure was somehow handling overfitting better than Model 1. The R2 values for both training and testing data sets possessed less discrepancy for Model 2 than those for Model 1 after all.

I attempted to implement a Dropout strategy, trying to have neurons randomly drop out at various layers in order to prevent some gaining artificially-presented importance. This seemed to harm rather than help my model under the configurations that I tried. I did find out that it's best to drop out after the final hidden layer and to make the dropout rate smaller, closer to 0.1. Nonetheless, even the lower rates were still worse than no dropout at all so I binned it.

I then went on to try L2 Regularization, which penalizes the faster growing attributes by multiplying them with a weight less than 1.0. An L2 of 0.01 gives poor results but an L2 of 0.001 benefits the training R2 by 0.1 or so while harming the test R2 by 0.05, an instance of noticeable over-fitting. I tried to include the Dropout technique at a rate of 0.1 in conjunction with L2 at 0.001 and was rewarded with a result of 0.71 for training R2 and 0.61 for testing R2. I unfortunately didn't save the outputs of this run and don't have those to share. I believe it had a worse MSE and I couldn't quite reconcile why the training R2 value rose and the testing R2 did not. 

I also tried to standardize the data prior to feeding it to the model. Data standardization is a statistical method of scaling the values by subtracting the mean from them and dividing that difference by the standard deviation. I had read that standardized data can be preferred when used for multivariate analysis which requires variables of comparable units and when this data has Gaussian distribution. My intent was to reconcile the differing units of kg/m3 of the seven features with the Day unit for the Age feature. This did not give me better results and so I didn't progress it further. 

Table of Contents➜

Similarities & Differences

My model is similar to Yeh's in the sense that it is a neural network leveraged to solve a regression problem with non-standardize data. However past that, the differences begin to appear more frequently. Yeh's model does not use more than one hidden layer and does not implement any regularization techniques. His model also sources the scrubbed dataset with 727 entries standardized under the conditions described in the paper while mine makes use of the total 1,030 entry dataset.

Table of Contents➜

Comparison

Yeh describes his model as follows:

Number of Hidden Layers: 1

Number of Hidden Units (Neurons): 8

Learning Rate: 1.0

Momentum factor: 0.5

Learning  Cycles (Epochs): 3,000

This is similar to my Model 1 slightly, so I'll be editing that model to reflect Yeh's for the purpose of comparing his model to my Model 2 as ran on the 1,030 data set. There is no specification of activation function so I'll keep using ReLU. The loss function is not specified either so I'll continue to use mean squared error from Keras as it's applicable to regression problems. I'll be interpreting that Yeh's model has an input layer, one hidden layer with eight neurons and one output layer. The learning rate and momentum factor suggest to me that Yeh's model implements Stochastic Gradient Descent (SGD) as it's optimization function so that's what I'll implement now. My Model 2 ran Adam.

I first randomly-sorted my data set in Excel using the Rand() function. I then divided it into 3/4 training and 1/4 testing subsets. Making the necessary edits, I thought the following model would get some results.

Instead, it wasn't able to adequately minimize the loss function - my loss flat-lined immediately instead. This led me to spending some time researching neural network architectures to make sure I had replicated Yeh's description adequately. This seems to have been the case. I then made sure that my loss and optimizer functions were both applicable and also compatible, just in case. They seemed to be, but I was still getting nonsensical results. 

I decided to start from a functioning model in order to reverse-engineer Yeh's out of it. I took my Model 1 from a previously functioning commit and decided to build up Yeh's description step by step. This model had two hidden layers with the first having 12 neurons and the second having 8. I changed the epoch count to 3000 and ran it. R2 values of 0.25 for both training and testing in turn, using MSE as the loss function and Adam as the optimizer. 

I then reduced the number of hidden layers to only one with 8 neurons, as Yeh's model specifies. This resulted in negative R2 values for both training and testing data sets, but the loss function did minimize as the model trained. I then attempted to implement the stochastic gradient descent for my optimization function and that's when the model broke. My loss function, MSE, is for some reason unable to to be optimized with SGD for this particular model. My Actual vs Predicted graph is simply a straight line parallel with the X-Axis.

I decided to explore a bit more and went on to implement Early Stopping on this one-layer model to see the results. I ditched the use of SGD as my optimizer and instead decided to stick with Adam. After approximately 34k epochs, my model stopped and gave me R2 scores similar to my Model 2 at around 0.6. However, the testing score was slightly better than the training score.

This felt like a good spot to wrap up the comparison as it was clear that I could sink in a good bit of time into trying to make my interpretation of Yeh's neural network work. It would have been nice if it did, but given my inability to interpret the parts of questionable clarity and the fact that the data set I was using was the undoctored version, I decided not to. 

Table of Contents➜

Learning Outcomes & Improvements

This was a rewarding experience that allowed to me create and tweak a neural network model in application to a real-life use-case. It was a good way to learn about regression and the role that neural networks can have in not only solving regression problems but also facilitating other kinds of numerical experiments with data permitting.

Unfortunately, I was not able to replicate Yeh's model as I had interpreted it. I instead resorted to modifying my existing Model 1 in order to match Yeh's description as close as I could while still procuring viable results. The model architecture fared alright but I did not succeed in interpreting the correct hyper parameters, such as the optimization function which I initially thought was SGD. The learning rate Yeh lists is unusually high at 1.0, given that the default rate for SGD is 0.01, but SGD does use both learning rate and momentum. Attempting to use SGD gave me nonsensical results. To my relief, the modified single hidden layer model did work albeit only with the help of Early Stopping. And to my surprise, the results were similar to the multi-layered Model 2. So more complexity isn't always good, if seldom!

Another learning outcome that can also be described as a potential improvement would be to automate model output storage. I found it difficult to manually track what output corresponded to which run, and figure that this is something that's best to standardize and automate well ahead of the first run. That way, with the various tunings and regularization attempts, there's a clearer picture of what works and what doesn't. This can be implemented by deciding on a folder structure and having the model create a new folder at the end of it's execution in order to save it's figures and variable outputs within. That way, it'll be possible to take stock of model performance at a certain point in it's development without having to worry about doing so manually.

In the same vane, there's a number of improvements I could attempt to do on the model in order to increase it's similarity to a real-life work project. I could pay for Google Cloud and receive access to parallelized GPU computational power, permitting me to implement grid search and do some more in-depth hyper-parameter tuning. I could also attempt to deploy my app into a cloud environment to better mimic the full data science pipeline. I actually did attempt this on a number of free services but had issues building my project. Deployments are something that I've decided to focus on in future projects in turn, as the process is still fairly new to me at the given moment. 

Table of Contents➜

Yeh's Validation Experiment & Use Case

A particularly interesting portion of the paper covers an experiment Yeh performed to validate the strength model created by his neural network. Table 7, Figure 3 and Figure 4 detail the results. Yeh took great care to create five concrete mixes and tailored each with a w/b ratio at fixed step sizes. Then he performed slump tests, getting the average of five, for each mix at a given age. This allowed him to plot curves showing the relationship between strength and age and w/b ratio which was in turn validated by his model. I don't believe Yeh discusses this in detail, but from the sound of  it his model allowed him to feed in the same features and get a prediction that was quite close to the actual compressive strength measured with the slump tests.   

I thought this was noteworthy. It provided an empirical validation of the neural network's capabilities, while also reminding me of Yeh's discussion regarding the Abram's formulation. The formulation suggested that only the binder quality mattered and not the quantity. Yeh gave examples for when this wasn't true, but it was interesting to see these exceptions validated by the experimental. Higher w/b ratios imply higher water and lower binder content quantity and as such are associated with lower ranges of compressive strength results than lower w/b ratios. This is evident as well when mapped out in terms of age, which shows that older mixes with lower w/b ratios are stronger. The Abram's formulation mentions water to cement ratios in particular, but I feel comfortable making the connection and generalization here since cement is a type of binder.

Yeh goes onto assert that the ease with which these models can be applied for numerical experiments to review the effects of each variable on the mix proportions. He claims that this is possible due to the fact that "the neural network model is built based on the data over the experimental domain". This is able to afford the researcher an ability to study the response of other experimental points in the experimental domain in terms of both their modeling and their prediction. This is why Yeh is able to introduce w/b ratios into the data as a totally new feature in lieu of Age and still able to get accurate strength predictions. Now that's neat! 
 

Conclusion

Overall, this was a rewarding project that was my first legitimate self-learning excursion into data science. It exposed me to neural network modeling, a number of database management systems, and the utility of APIs. It let me exercise my creativity when it came to trouble-shooting issues I had, either when debugging or when thinking conceptually on what I could to improve. Just as importantly, it highlighted what I didn't know and areas where I could make gains in order to better round myself out as I continue my learning.

Table of Contents➜

Citation

I.-C. Yeh,
Modeling of strength of high-performance concrete using artificial neural networks,
Cement and Concrete Research,
Volume 28, Issue 12,
1998,
Pages 1797-1808,
ISSN 0008-8846,
https://doi.org/10.1016/S0008-8846(98)00165-3.
(https://www.sciencedirect.com/science/article/pii/S0008884698001653)
Abstract: Several studies independently have shown that concrete strength development is determined not only by the water-to-cement ratio, but that it also is influenced by the content of other concrete ingredients. High-performance concrete is a highly complex material, which makes modeling its behavior a very difficult task. This paper is aimed at demonstrating the possibilities of adapting artificial neural networks (ANN) to predict the compressive strength of high-performance concrete. A set of trial batches of HPC was produced in the laboratory and demonstrated satisfactory experimental results. This study led to the following conclusions: 1) A strength model based on ANN is more accurate than a model based on regression analysis; and 2) It is convenient and easy to use ANN models for numerical experiments to review the effects of the proportions of each variable on the concrete mix. 
 

Comments

Post a Comment