The Photonics Spotlight > 2012-02-03

Simulation Software

When you need to do some simulation and modeling, a basic question often arises: should you develop your own software to do this, or better take a commercial product?

I am admittedly not neutral on this issue, as I am obviously happy if people decide to buy my own modeling software, such as

• RP Fiber Power for fiber laser and amplifier design
• RP Resonator for resonator design (mainly for bulk lasers)
• RP ProPulse for pulse propagation simulations, e.g. in mode-locked lasers, regenerative amplifiers and fibers

Anyway, I can contribute some thoughts on that question which may help you to arrive a rational conclusion. It turns out that a number of aspects should be considered in this context.

Time to Get Started

In most cases, the time to get familiar with some commercial software is quite small compared with the time to develop some software oneself. So in this respect, commercial software often has a big plus. However, it can also turn into a big waste of time if you start with some software which works for the simple cases but later out turns out not to be sufficiently flexible (see below) so that you still have to turn to something else later on.

Is the Code Correct?

That can be a big issue. Anyone can easily make errors when developing simulation and design software, and obviously such errors can severely hurt you. For example, you may be mislead by them and subsequently try out things in the lab which cannot work.

Definitely, any such software should be carefully validated before it is used. This is a process which takes substantial time and experience. (I have actually devoted another article to the problem of software validation). If you develop such software yourself, you may be under pressure to get results quickly and do only some superficial testing. On the other hand, you may find it hard to trust some anonymous developer at some software company. So preferably you will use software developed by somebody who is known to be most competent, experienced and careful.

User Friendliness and Flexibility

Obviously, it will help you if a software is user friendly, as this makes your work easier, more efficient and also safer. (The risk of introducing errors in the software handling is much greater if you don't have a well engineered user interface!) On the other hand, you want something really flexible, working also in more sophisticated cases, as it is no point to do only some simple things with a software and have no solutions for the most interesting cases.

Unfortunately, it is not easy to achieve user friendliness and flexibility, let alone to combine them in one product. Some products come with a really beautiful graphical interface, where you simply put together some model with a few mouse clicks. However, this approach tends to severely limit your flexibility, as some general structures are hard-coded and cannot be changed. For example, there are optimizations where you can only adjust parameters but not the general type of the used figure of merit. In other cases, you may easily set up some chain of optical components, but cannot deviate from a linear chain.

As a more concrete example, imagine that you want to simulate the operation of a regenerative amplifier, where you inject a pulse, let it circulate say 50 times, then eject it and replenish the energy by pumping the crystal for some time. Now you may want to vary some parameter (e.g., the initial pulse energy) and check out what you get after multiple amplification/pumping cycles. If you have to arrange all that manually for each parameter value, it may drive you crazy before your results are complete.

Scripting vs. Forms and Graphical User Interfaces

Initially, my software always had to be controlled by writing scripts, containing certain commands and mathematical expressions. That gave the user the full flexibility, but required some initial investment to get acquainted to the script language. Well, starting out with some demo scripts one gets into it quite quickly, but some potential users were concerned to spend too much time. Other companies offered software with a purely graphical interface, which was easier to get started with, but totally lacked flexibility. I then considered to offer forms in addition, but I still didn't want to confront the user with a hard choice between two totally different approaches, each one still having its characteristic limitations. I finally managed to find the right combination, best implemented in my RP Fiber Power software:

• You can work with simple forms, but you can put mathematical expressions instead of plain numbers into most form fields. For example, this allows you to specify any time-dependent powers, and not only choose from some given selection of simple temporal shapes.
• When a simulation is executed, the software writes a script based on your form inputs and then executes that. If you do really complicated stuff, just go as far as possible with the forms and then refine further the automatically generated script - which is much easier than starting from scratch with script programming.
• The forms also offer various opportunities to inject additional script code for special purposes such as adding a special graph or certain calculated labels to some diagram, or to import some input data from files.

This approach nicely combines the simplicity of filling out forms with the great flexibility of scripting. It even avoids the hard break when moving from forms to scripting.

Obviously, such features are really difficult to implement. You surely cannot invest that much time when developing some own code for a project, and many software companies cannot offer it either.

Can the Next Colleague Take Over?

A typical situation at universities (but also in some companies) is that some clever guy puts together some ingenious programs which allow him to efficiently to do his job. Only, when he later leaves the place, nobody can take this over, as nobody will understand his source code within a reasonable time. So the next guy will start from scratch. Obviously, this is very inefficient in the long run, and leads to periods of time where the productivity of the team is severely reduced. When working with some well engineered software, this won't happen: the work is not done by tweaking the source code, but on a level which is much easier to access. Also, technical support is available to sort out any remaining problems. So the continuity is much more easily maintained.

Some Conclusions

There can be very good reasons to stick to home-made code, particularly when available commercial software is too limited in its flexibility. If it is not really usable to do the job also in more complicated cases, don't bother to start with it.

On the other hand, if you know a trustworthy commercial software combining a convenient user interface with high flexibility, it is hard to defend the do-it-yourself approach. That will take much more time, will presumably lead to something which is more prone to errors (both in the code and during the handling), and makes it difficult to transfer the job to somebody else. Well, if you want to force your boss to keep you employed forever, this may be the way to go! Your boss however, should want to avoid that, even if it costs some money upfront, as it would be silly to ignore the difference in productivity. One cannot spend that much time on developing software before making this effectively more expensive than buying a commercial software. After all, it is obviously more efficient if one guy (or team) makes an excellent software to be used by many, compared with everyone implementing a quick-and-dirty solution himself.

Sometimes, people say that it would great to have some good commercial software, but they cannot afford it. The question is then whether they can afford to work in less efficient ways, such as paying salaries over long times for the same amount of work and not fully utilizing some expensive infrastructure. Obviously, if you are under pressure to be economically efficient, you should choose the most efficient solution rather than the one which requires the smallest possible initial investment. If you can't, you may get out of business some time later.

This article is a posting of the Photonics Spotlight, authored by Dr. Rüdiger Paschotta. You may link to this page and cite it, because its location is permanent. See also the RP Photonics Encyclopedia.

Note that you can also receive the articles in the form of a newsletter or with an RSS feed.