The RP Photonics Software News > 2024-06-05

Combining Flexibility of Simulation Software With Usability

For simulation software to be really useful, it needs to have a number of important qualities. Two of those are particularly important:

• Flexibility: Such software needs to be usable in a wide range of cases, not just in a few simple situations. For example, a fiber amplifier simulation software should allow the following:
  • multiple amplifier stages, and between those additional components such as optical filters or switches
  • single-or double-pass configurations
  • continuous-wave operation and pulsed operation, even with ultrashort pulses
  • multiple input signals
  • dynamic simulations with arbitrarily time-dependent input powers, not just the usual on-off switching of pump sources and single pulse shapes
• In any case, one needs a lot of flexibility to generate all sorts of diagrams which may be useful for practical work.
• Usability: At the same time, software needs to be reasonably easy to use – without investing too much time into learning how to handle it.

Great usability is surely no substitute for flexibility, no vice versa.

It is a special challenge to create a user interface which well combines flexibility and usability. It took me many years to invent and implement really well-working solutions to that. Here, I will explain what has been found to work best. This gives you quite some insight into challenges of software engineering. But first let's discuss the limitations of different traditional approaches.

Limitations of Traditional Approaches

Form-based User Interfaces

The easiest way of configuring a simulation of a laser, amplifier or similar is usually to fill out a form on the screen. The form gives a certain structure, and users can generally find out quickly what kind of inputs are required. In the same way, the required outputs can be configured, in particular some diagrams.

The structure defined by a form is obviously very helpful, as it does not need to be created by the user. At the same time, however, it tends to seriously limit the range of applications: the form gives a number of options, but what if you need something which for which those are not sufficient? Some examples:

• A form may offer ten different types of diagrams, but often the user would like to add some features to a diagram which is not offered, or even require a complete additional diagram.
• The input pulses for simulations involving the propagation of ultrashort pulses must be defined somehow. It is easy to offer a choice between multiple temporal pulse shapes like Gaussian, sech², etc., and perhaps also an option to load pulse data from a file. But what if a user requires a simple pulse shape which is still not offered – force her to create a whole data file just to define that pulse? And how about the temporal phase profile? Trying to or for any features which cannot be relevant in practice is not easy at all.

The traditional way of dealing with this is to add more and more features to a form, trying to anticipate anything the users may need. But there are limits to that:

• The form should not be overloaded with rarely used features, which only make it more difficult to maintain an overview.
• There are always things which nobody could anticipate but still turn out to be important when applying a software in a certain situation.

Therefore, if the form is hard-wired in the software (i.e., cannot be extended by the users), we have a more or less serious limitation of flexibility. Basically, a form defines a certain structure with a limited number of options, and that will not always fit.

Scripting-based User Interfaces

An approach offering far better flexibility is scripting, i.e., defining all inputs and wanted outputs in text form – with script commands for certain actions, definitions of variables, etc. That way, the user is completely free, for example, to define arbitrary diagrams with any conceivable features. Essentially, one can do full-blown programming! Such a software is extremely flexible, not much dependent on what exactly the software developer has anticipated.

As a simple example, consider a little bit of code which creates a diagram for displaying the output power of a device as a function of the pump power in RP Fiber Power:

; Plot output power vs. pump power:

x: 0, 30
"pump power (W)", @x
y: 0, 10
"output power (W)", @y
frame

f: (set_P_in(pump, x); P_out(signal)),
  color = blue, width = 3

I think that most people would find it relatively easy to understand such kind of code and to develop it a little further, adapting it to their own needs. However, scripting is often perceived as tricky and cumbersome, and for many people just not a practical approach. Admittedly, it takes some efforts, for example, to find out the names of other functions for plotting additional output quantities, or how to add further text labels, make color plots, etc.

To some extent, one can mitigate that with various approaches – some examples of what we did:

• The software can come with a nice set of demo scripts, showing how to set up simulations for typical use cases. The user can then select one of those as the starting point for a simulation – in similar cases, only adjusting various parameters in that script, and possibly adding only minor details, e.g. of generated diagrams.
• Technical support can be very helpful, for example by delivering additional tailored scripts for specific new use cases indicated by a user.
• Of course, there should be comprehensive documentation, clearly explaining how the whole script language works, and giving plenty of examples.

This is how we started, for example, with our RP Fiber Power software many years ago. Essentially, users had to use scripting, which provided enormous flexibility, even in the earliest software versions around 2012. Further software features became important for scripting complex things – for example, a powerful script editor and an integrated debugger.

This worked well for many users. However, I assume that many still found it too demanding and could therefore not decide to get into that – although customers normally found that you can indeed become quite productive within a reasonable amount of time.

Combining Scripting and Forms

Over the years, I have developed various approaches for combining the flexibility of scripting with the good usability of forms – essentially by finding cute combinations of them.

Simply offering both forms and scripting features wouldn't be a great solution. For users, it would be two profoundly different ways of dealing with the software. They would probably start with the forms but then need to go for scripting anyway. But we found better approaches, as I will explain in the following.

Simple Forms, Creating Scripts

An early approach, already realized in RP Fiber Power V2, was to offer an additional mode of operation based on a set of simple forms. These allowed one, for example, to set up a simple continuous-wave fiber amplifier, and create various diagrams within a few minutes.

A cute feature of that: when you execute such a form, the software first creates a script based on your form inputs, and then executes that. You can then also inspect that generated script code and save it under a different name to develop it further.

So the idea was not to now go for forms instead of scripting, or trying to cover all uses cases with such forms. Instead, it was essentially another way of quickly creating a good starting point for further development of a script. That can be helpful, but obviously it does not remove the challenges of scripting.

Our software RP Fiber Power still offers these forms, although meanwhile we have found much better approaches.

Custom Forms, to be Tailored by Users

Another big milestone was the introduction of custom forms with RP Fiber Power V6, or with V4 of RP Coating, RP Resonator and RP ProPulse. Here, the idea is to define forms in scripts:

• Any text which is simply displayed on the form is simply provided in a special section of the script.
• With some number of # characters, one can indicate the positions and widths of input and output fields. After each line containing one or more such fields, one needs one additional line for defining the details of that field – for an output field, for example, one or more expressions, the values of which are displayed, together with the number of relevant digits and the used units. Further useful extras can be minimum and maximum allowed values and a hint text.
• There are special types of input fields for things like drop-down boxes, trackbars and the like.

That is definitely a nice way of gaining enormous flexibility: as forms can now be developed further (or from scratch) by our users, they can be tailored to a wide range of use cases without changing anything in the software itself.

We are delivering the software with many demo scripts, some of which are also equipped with a custom form. These are still kept relatively simple, making it easy for users to understand how it works. In simple cases, these forms already do everything required, but in practice one may often want to add at least a few features. Of course, we can always help within the technical support.

It is also possible that one member of an R & D team who delves deeper into the software develops some scripts with custom forms, and other team member can then simply use those forms, not being exposed to the underlying scripts.

Power Forms

In summer 2023, we reached another important milestone with the introduction of Power Forms (so far only in RP Fiber Power). These are essentially custom forms supplied by us, but with two essential new qualities:

• The Power Forms are quite sophisticated – suitable for direct application in many projects out of the box, not just meant to be simple demonstrations. For example, you can configure even complex multi-stage fiber amplifier systems for ultrashort pulses. A lot of flexibility is built into these forms by offering plenty of options. Still, the forms are organized to handle. For example, they hide parts which are not relevant based on certain inputs, which makes it easier to keep an overview.

• These forms are also specially integrated into the user interface such that our users need to deal less with file locations. One can easily call the forms without knowing where the underlying script code is stored. For the user's input data, there is a simple choice: either, these data can be stored in a special app data folder (which the users usually don't care about), one for each form, or they go to a user's folder for a specific project. In the latter case, the user just has to select that folder when starting the software.

In addition, we extended the features of custom forms in various ways to realize even nicer forms, or to realize them more conveniently.

Although the Power Forms offer far more features than the previously offered demo custom forms, it is of course still possible that in practical applications one needs certain features going beyond what is offered already. However, we have implemented ways to get extensions of different complexity levels very easily:

• For minor details such as adding a curve to a diagram, you can simply enter a single line of script code (or several lines, when needed) directly into the form. (The forms offer such an input for each diagram, and at other locations for other purposes.)

• It is even possible to add entire new diagrams that way. Such diagram definitions then become part of the input data, not part of the form itself.
• In some cases, you may require larger portions of script code, for example for implementing sophisticated additional data processing, with storing of calculated values and output files with special formats. In that case, in the form I will simply use an include command which references a separate script file.
• In some cases, one needs to extend the Power Form itself. Our user interface makes that quite easy: it offers to copy the script code for the form into the user's work folder, so that one can directly continue to edit it there as a custom form. Note that the original Power Form might be modified with the next software update, but the user's copy in the work folder will not be affected by that.

So scripting is only used for special extensions, i.e., usually for a very small part of the overall functionality of a Power Form. That implies that the user won't need to deal much with scripting – often just copy a bit script code (obtained e.g. through our support) into the form. Still, that feature is essential as a great extension of flexibility.

Only for special applications, where none of the Power Forms fit, one still needs to define custom scripts, which can also be equipped with custom forms as needed.

Required Software Technology

You will not be surprised to learn that it took us many years to develop these things. A lot was required:

• To begin with, developing a highly convenient script language for setting up simulations and creating diagrams was a complex undertaking. Over the years, I added more and more nice features to make things more convenient. For example, while arrays are limited to integer index values in most other languages, our script language offers real-valued arrays, allowing one to directly map physical quantities to locations or times, for example. When retrieving arrays values, you can also conveniently apply linear or even spline interpolation. (When starting with some Python programming, for example, you would not have such handy features available.)
• Offering hard-wired forms in a user interface is not that difficult when using the right software platform – which is Delphi in our case. However, allowing for custom forms which are defined by script code is far more demanding. But only that way, we could provide that enormous flexibility.
• As you can imagine, working out these Power Forms (seven so far) made two of us busy for many months.

Therefore, we are at least not concerned that some competitor reading this or studying the comprehensive descriptions of our software on our website could easily implement those things himself! Or that someone interested in simulation would consider that.

Conclusions

It is important to realize

• that only software which combines high flexibility with great usability can be highly useful for practical applications, and
• that this combination of qualities is not easy at all to achieve.

During many years of hard work, we have found and implemented well working solutions – in particular, user-tailored custom forms and sophisticated Power Forms. This now allows many users worldwide to realize sophisticated simulations, for example for the development of lasers and fiber amplifiers, without investing that much working time into setting up such things.

This also makes clear that only a clear separation of two tasks is a sensible:

• Developers of such software need to invest a lot of time into making really powerful tools with good usability.
• Others should fully concentrate on their own tasks, for example developing laser devices efficiently with computer simulations.

Investing a lot of time into developing such powerful tools is worthwhile only when these tools can then be used by a large community of laser developers and scientists. If everyone doing simulations would have to develop the tools himself, that would be far less efficient.

If you are engaged with developing fiber lasers or amplifiers, or with new fiber designs, start using this amazing simulation tool! You don't need to be a hero to handle that, and it will save so much work elsewhere.

This article is a posting of the RP Photonics Software News, authored by Dr. Rüdiger Paschotta. You may link to this page, because its location is permanent.

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