|
Posted on:
27 Feb 2013
|
In our previous blog we discussed about the integration of modelling and simulation software in the curriculum of High Schools and Universities.
Another very interesting point covered in the paper of the professors from Rowan University is the fact that many (small) companies use self-made macros or programs to solve problems that are readily solved with commercial simulators, simply because they cannot afford the software. This does not mean, of course, that process simulation software is “a tool that graduating chemical engineers should not be familiar with.”
The problem with this self-made or programmed models is that they are normally very difficult to maintain, since they are programs which have been written by individuals. Therefore, it is not uncommon that companies do not allow their engineers to write software. Actually, computer programming (in languages such as FORTRAN, C, or PASCAL) is not a vital skill for chemical engineers in industry anymore.
The chemical engineering community thus may have a use for teaching tools and techniques that challenge students to think logically and develop algorithms without necessarily taking the time to learn a full programming language.
A closely related problem is that, even with commercial simulators there always seems to be an issue with maintainability of models (also in big companies). Especially when models become large and/or highly “custom made”.
Let me sketch a typical scenario (that I have seen several times). A company “hires” a graduate student to make a model for them, because they have no time, no money and/or not enough expertise to do it themselves. The student works on the model for months and does a lot of custom programming. After the student finishes his work, the model typically goes “in the closet” for a few months/years, because nobody has time to do something with it. After a long period, the model could actually be useful, but no one at the company knows how to work with it and no one seems to even get it running. So, they wisely decide to hire another student, who does not completely understand what the previous student has done and therefore decides to start from scratch and redo the entire job….
Not very efficient of course, but, unfortunately quite commonplace.
In my opinion the root of the problem is caused by the fact that there are basically two ways of making models nowadays:
I think a large part of the maintainability issues can be resolved by introducing a “new” approach: The “Equation and system based” approach, which typically is a combination of the best of the two previously mentioned approaches. Without going into details I would state that such a methodology offers a lot of flexibility, but also provides insight in the process that is being investigated. Although this methodology has a learning curve, I have noticed that students/engineers who have mastered it are able to solve problems quicker. Also the generated models tend to be a lot easier to transfer to others, without the need for extra documentation.
What tips do you have to improve maintainability of process models?
I invite to post your experiences, insights and/or suggestions in the comment box below, such that we can all learn something from it.
To your success! Mathieu. ———————————————–
Another very interesting point covered in the paper of the professors from Rowan University is the fact that many (small) companies use self-made macros or programs to solve problems that are readily solved with commercial simulators, simply because they cannot afford the software. This does not mean, of course, that process simulation software is “a tool that graduating chemical engineers should not be familiar with.”
The problem with this self-made or programmed models is that they are normally very difficult to maintain, since they are programs which have been written by individuals. Therefore, it is not uncommon that companies do not allow their engineers to write software. Actually, computer programming (in languages such as FORTRAN, C, or PASCAL) is not a vital skill for chemical engineers in industry anymore.
The chemical engineering community thus may have a use for teaching tools and techniques that challenge students to think logically and develop algorithms without necessarily taking the time to learn a full programming language.
A closely related problem is that, even with commercial simulators there always seems to be an issue with maintainability of models (also in big companies). Especially when models become large and/or highly “custom made”.
Let me sketch a typical scenario (that I have seen several times). A company “hires” a graduate student to make a model for them, because they have no time, no money and/or not enough expertise to do it themselves. The student works on the model for months and does a lot of custom programming. After the student finishes his work, the model typically goes “in the closet” for a few months/years, because nobody has time to do something with it. After a long period, the model could actually be useful, but no one at the company knows how to work with it and no one seems to even get it running. So, they wisely decide to hire another student, who does not completely understand what the previous student has done and therefore decides to start from scratch and redo the entire job….
Not very efficient of course, but, unfortunately quite commonplace.
In my opinion the root of the problem is caused by the fact that there are basically two ways of making models nowadays:
- The “Unit oriented” or “flow sheeting” approach. Hardly any programming is required. The user just drags some predefined units on a flow sheet, connects them and configures some parameters. Quite convenient for most users, but very inflexible (sometimes nearly impossible) when deviations from standard equipment are needed. And, as discussed in our previous blog, users sometimes simply don’t know what they are actually doing.
- The “Equation oriented” approach. Nearly everything needs to be programmed out. This is very flexible, but typically also a very tedious job. Much (programming) experience and a lot of patience is required to get a model up and running
I think a large part of the maintainability issues can be resolved by introducing a “new” approach: The “Equation and system based” approach, which typically is a combination of the best of the two previously mentioned approaches. Without going into details I would state that such a methodology offers a lot of flexibility, but also provides insight in the process that is being investigated. Although this methodology has a learning curve, I have noticed that students/engineers who have mastered it are able to solve problems quicker. Also the generated models tend to be a lot easier to transfer to others, without the need for extra documentation.
What tips do you have to improve maintainability of process models?
I invite to post your experiences, insights and/or suggestions in the comment box below, such that we can all learn something from it.
To your success! Mathieu. ———————————————–
Hi Mathieu,
Unfortunately, I am almost sure that the models I made as a student and, later on, as an employee of a certain small company are hidden in somebody’s hard disk. Modeling in certain companies is still abracadabra…
The problem that you mentioned when retrieving a model from somebody else occurs even using the simplest model simulator: Excel. It is such a nightmare to dig into the nitty-gritty details that you better start all over again.
I haven’t seen the latest versions of Mobatec but its modularity actually helps a lot solving this “transfer” problem. As a recommendation, I would implement a kind of graphical tree or directory that indicates clearly in which layer of the model we are. For example, if we are modeling a distillation column, showing if we are seeing the liquid phase, vapor phase or interphase equations.
By the way, I like your initiative of starting a blog about modeling!
Success!
Thanks for your nice comments, Raul. Indeed, in a lot of companies Excel is The Main Simulation Tool and it’s often not the best choice in terms of maintainability.
Also thanks for the recommendations to improve our modelling tool, Mobatec Modeller. Quite a lot has been changed and improved (including the tree you are suggesting) over the last years, so be sure to download our latest version and have a look at all the options ;).
I would be more than interested in the views of other readers on the maintainability issue, so, everybody, please share your ideas on this subject!
Kind regards,
Mathieu.
Hi Mathieu,
I was just looking at the approach that you took to handle this problem. I think that it is a very good direction, because the topology is the best way to easily show the connections made on each level of the model.
Using the gPROMS in the last 12 months, I can say that they have a similar approach to this problem. There is also one option in gPROMS. Once you have written the code for your unit, you can make it a library model. When you do this, you create a user interface where the (new)user of the model has a window to fill-in the values of certain parameters & variables (relevant to the model),run the model and get a certain results. You, as the model & model interface creator will decide which parameters values the user needs to fill in and what solutions the model will display. The interface itself is created by gPROMS (you just need to folow the steps) and it is quite easy to do this (once you have your code-model working). This approach helps new users to use the model and obtain results.
But, if you want to change something in the existing model(equations) that was made by somebody else.. the best approach is to be very descriptive when writing the code and to leave a lot of comments.
Cheers!
These are indeed handy features for end users, Vladimir. Thanks for sharing.
The blog post was mainly concerned with your last comment. In my opinion the amount of “very descriptive comments” can be reduced quite a bit, when a structural approach to modelling is adhered to (independent of which tool is used in the end). This is because this methodology tends to be “self-documenting”, meaning that the main assumptions are actually visible (without the need for extra documentation), because of the way the model is setup.
I am working with Six Sigma tools in practical industrial process lines. Whether a model is right or not is also very depending on factors like equipment pollution, quality differences in raw materials, etc. Typically such information is not in the models. Most important there is to have easy information at hand that describes the rough logics of the model. Those typically remain useful for future users.