2

first of all I am new here and I hope that this is the right place for my question. I have a question about the recommended architecture of a project.

IDEA: Automate some calculations concerning to aerodynamics. I have some input data and I need to process this data in several sub-calculations. You can see such a calculation somehow like a black box:

INPUT => CALCULATION => RESULTS

Some of these calculations are already available as open source programs and some of them I need to program on my own. This shouldn't be a problem at all. But I want to connect these calculations in a flexible way. For example:

INPUT => CALCULATION 1 => CALCULATION 2 => CALCULATION 3 => RESULTS

Number and order of calculations should be changeable. Should I see each calculation as standalone program and connect them in a kind of framework where I can specify order and arguments of program calls? Or are there other techniques to solve problems like this?

Thanks a lot for each advice and every recommendation.

Sebastian

Improve this question
3
  • Does the input format of each calcualtion match the output format? If not, you may want to create (one or more) connectors, that are pieces of software which know how to transform the output of calculationI into the input of calculationJ
    – Thomas
    Mar 31, 2013 at 11:49
  • Sounds like MatLab to me.
    – Ross Patterson
    Mar 31, 2013 at 14:29
  • Yes, sometimes I need to write a little program which transforms the output. I see this easily as another black box which does some "calculation" with data.
    – s.greshake
    Mar 31, 2013 at 14:41

1 Answer 1

Reset to default
3

What you're considering is one of the tenets of the Unix philosophy: you build lots of small tools and string them together into pipelines to make bigger ones.

One real-world example of this that parallels your problem is a set of programs called NetPBM. NetPBM consists of more than 200 filters that can be pipelined to read an image in any of a long list of formats, manipulate it an any of a long list of ways -- often more than once -- and write the results in any supported format. The key to making these tools work is the use of a fixed set of standard formats for the data that each filter can read and/or write or can be derived using a conversion filter.

In your case, as long as the output format of any calculation can be read by any other, you could mix and match them in any order you like. For example, if everything was a 10x10 matrix, any of the following would work just fine (the "|" symbol means "pipe," or "direct the output of the program on the left side to the input of the program on the right side"):

Get Input | Calculation 1 | Calculation 2 | Calculation 3 | Write Output
Get Input | Calculation 3 | Calculation 2 | Calculation 1 | Write Output
Get Input | Calculation 1 | Write Output
Get Input | Calculation 1 | Calculation 3 | Write Output

As mentioned in your comment, you might have to write filters to do conversions, and that's fine, because they fit in with the idea of having a toolbox full of small, useful tools:

Get Input | Calculation 1 | Convert 1 out to 2 in | Calculation 2 | Write Output

That said, I would urge you to explore a numerical analysis tool like MATLAB or Octave. Both are designed specifically for this sort of thing. Once you're over the learning curve, you'll spend a lot more time doing math and a lot less time programming.

Improve this answer
3
  • Thanks for explanation. I know MATLAB. Unfortunately it is not the right tool for this project. I need some (small) CAD-like geometry manipulation in the beginning of the chain. This leads to a GUI in the end. I think - although possible - in this case MATLAB isn't the right platform.
    – s.greshake
    Apr 1, 2013 at 16:18
  • Another comment: Yesterday I read some basic stuff about the UNIX philosophy mentioned by you. I think I see the point of pipelining small tools. But while developing an application where do you make a cut and say this is now an own program. Lets remember the small CAD module in the beginning. It would definitely be possible to divide this module into a number of smaller tools. But would this make sense? This module serves only one sense: to define interactively one type of geometry. My instinct tells me to accept that this module would be an bigger program based on OOP. Is that right?
    – s.greshake
    Apr 1, 2013 at 16:32
  • @s.greshake: Probably. You have to evaluate your situation and do what makes sense and avoid overkill. (Overkill in this case meaning insanely long pipelines.) What you'll probably find is that your toolchain will end up a mix of programs that do some of the bigger tasks and libraries that get used by the programs to do some of the simpler things that don't make sense to pipeline.
    – Blrfl
    Apr 1, 2013 at 17:32

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.