Drasil
Drasil copied to clipboard
JacquesCarette
Chapter 0 Introdcution - MEng Report
From the Industrial Revolution (1760-1840) to the mass production of automobiles that we have today, human beings never lack innovation to improve the process. In the Industrial Revolution, we start to use machines to replace human labour. Today, we have been building assembly lines and robots in the automobile industry to reach a scale of massive production. Hardware automation has been relatively successful in the past one hundred years, and they have been producing mass products for people at a relatively low cost. With the success story of automating hardware, could software be the next one? Nowadays, the software is used every day in our daily life. Most software still requires a human being to write them. Programmers usually write software in a specific language and produce other byproducts during development time. Whether in an enterprise or research intuition, manually creating software prone to errors, and it is not as efficient as a code generator. In the long term, a stable code generator usually beats programmers in performance. They will eventually bring the cost down because of the labour cost reduction. Perhaps this is why human beings consistently seek to automate work. History demonstrates that we successfully automate hardware. With fairly well-understood knowledge of software, creating a comprehensive system to produce software is not impossible. Can you imagine that programmers no longer programming in the future world? In this world, code generators will generate software. There will be a role called "code alchemist" who is responsible write the recipe for the code generator. The recipe will dictate what kind of software people want. In other words, the recipe is also a software requirement document that the code generator can understand. Once the code generator receives the recipe, it will automatically produce software artifacts. The described above is revolutionary if there is such a code generator, and the Drasil framework could be it.
The Drasil is a framework that generates software, including code, documentation, software requirement specification, user manual, axillary files, and so on. We call those artifacts software artifacts. By now, the Drasil framework targets generating software to overcome scientific problems. Recently, the Drasil team has been interested in expanding its knowledge to solve a high-order ordinary differential equation (ODE) through external libraries. There are two main reasons why we want to do that.
-
Scientists and researchers frequently use ODE as a model in scientific problems, and this model describes the nature phenomenons. Drasil is a framework able to generate software artifacts that solve scientific problems. Therefore, solving ODE in the Drasil framework would solve many scientific problems.
-
There are many reliable libraries, and the Drasil team is interested in how the Drasil framework interacts with external libraries. Libraries that solve ODEs are probably the most important ones. Once the team understands how to interact between the Drasil framework and external libraries, they will start to add more external libraries. In this way, it would unlock the potential to allow the Drasil framework to solve more scientific problems than before.
However, the Drasil framework neither captures ODE knowledge nor solves high-order ordinary differential equations. The previous researcher researched to solve a first-order ODE, but it only covers a small area of the knowledge of ordinary differential equations. Adding high-order linear ODEs into the Drasil framework will expand the area where it has never reached before. Therefore, this research will incorporate high-order linear ODEs in a complex knowledge-based, generative environment that can link to externally provided libraries.
In order to solve a high-order linear ODE, we have to represent equations in the Drasil database. Then, we need to know how external libraries solve ODEs, what their capabilities are, and what interfaces look like. Last, we need to bridge the gap between the Drasil ODE data representation and external libraries. We can achieve that by generating proper interfaces.
Before conducting this research, the Drasil framework can solve explicit equations and numerically solve a first-order ODE. After this research, the Drasil framework will have full capability to solve a high-order linear ODE numerically. In addition, we will explore the possibility of solving a system of ODE numerically. We will introduce a new case study, the double pendulum. It contains an example that solves a system of high-order non-linear ODE.
Chapter 1 will cover how to represent the data of linear ODE in Drasil. Then, in Chapter 2, we will analyze external libraries. In Chapter 3, we will explore how to connect the Drasil ODE data representation with external libraries. Last, we will discuss a user's choice to solve ODE differently in this framework.
I'm not a big fan of introductions that start at quite so high a level, removed from the actual topic (i.e. the first 1/2 of your first paragraph).
I would think of "recipes" as bearing the same relation to current code as current code bears to machine language. It's still a form of code, and the code generator is a form of compiler.
The way I would approach high-order ODEs is to say that they occur often in research models (and thus scientific software) - but that Drasil only dealt with first order ODEs. I would also phrase the use of external libraries differently: they are hard to write and embody a lot of knowledge, so we want to re-use that instead of forcing ourselves to reproduce them "the had way". Ah, I see that you do mention some of this after your enumeration! I would mention that before.
In many ways your core contribution is buried in the paragraph 'In order to...'. Thus I think that this paragraph should be expanded, to further explain things.
As a first draft of an introduction, this is quite good. I would move on to the other chapters, you'll need to come back to this later anyways.
Can the first half paragraph (introduce software automation) still preserve somewhere in the report? It's my shallow vision of software automation and why it exists.
@cd155, as we discussed during Friday's meeting:
- please move the above contents (with editing) to the tex document for your report. It will be easier to track your changes (although maybe harder to get feedback from @JacquesCarette) :smile:
- it is nice how you go from general to specific
- you'll want to cite the Drasil paper (Szymzack et al.) and the Drasil webpage.
- rather than "in order to" say "to" 😄
I'm fine with a Background section that has a (sub)section on "larger setting" that puts things in the larger domain of software automation. I prefer an Introduction that gets to the point as quickly as possible.
This review has been completed, as far as I can tell. I'll re-review Chapter 0 when the complete draft of the report is ready for review.