Your goal as an author is to create an EASAP that is:

1. Easy-to-use,
2. Reliable, and
3. Robust.

Basically, you want your users to learn it, like it, and trust it.

The ease-of use of your EASAP is mostly a function of the User Interface design and layout, and this topic is discussed in detail in User Interface Design Principles.

The reliability of an EASAP is related to the results produced and how accurately they tend to represent reality. Reliability is mostly a function of the underlying software applications and how well they have been validated for the problem being solved by the EASAP.

Finally, the robustness of an EASAP is measured by its ability to always run properly and produce a valid result. If an EASAP too often fails to produce information for the user to use, then they will most likely stop using the EASAP. Here again, robustness is highly dependent on the underlying software applications, but controls are available when generating an EASAP that can improve robustness.

There are a couple of important factors worth noting that can affect the robustness of an EASAP. The first is related to the underlying software, while the second is related to the EASAP design.

One characteristic of underlying software applications of which to be aware is whether non-linear solution methods are employed by the software. If so, a valid solution, even for a well posed problem, will not be guaranteed. Non-linear solution methods often employ an iterative approach that must ‘converge’ on a solution, and ‘convergence’ to a solution is not a foregone conclusion. In addition, convergence in non-linear analysis is often highly dependent on the inputs to the software.

Note: A danger with non-linear analysis is that a solution file will be produced even though the solution is not converged to an acceptable level. You should check for this situation and notify users accordingly.

The number of inputs made available to users in an EASAP may affect its robustness. The idea being that you are increasing the chances for something to go wrong, or at least, increasing the amount of testing required to ensure a robust EASAP. Also, the size of the ranges set for these inputs using upper and lower bounds can also play a role in robustness. Again, the idea is the larger the ranges, the more room for problems to occur.

To test your EASAP for robustness, you will need to perform some level of parametric testing. In parametric testing, you will need to systematically vary the values of inputs that may affect the robustness of an EASAP and its underlying software applications. As examples, these inputs might be geometric dimensions, material properties, initial conditions, boundary conditions and operating conditions. However, a text input that will be passed straight through to the report on the Results page will not affect robustness.

When planning your parametric testing for an EASAP, you need to first decide on the level of testing that you think is appropriate for the particular EASAP. There are a few factors that determine the amount of parametric testing that may be required.

1. The number of input parameters that affect robustness, n
2. The number of values per input to test, N
3. Whether an input can be varied in isolation since its effect on robustness is independent of other input parameter values

To get an estimate of the number of parametric runs required for an EASAP, you can use the following two equations to some extent as lower and upper bounds.

1. All inputs isolated: N*n
2. Full parametric interactions: Nn

These two equations assume that N is the same for all inputs. An example of where this is not the case is where you have a mix of choice list values and real or integer box values to test. In this case, N may be equal to the number of choices for the choice list items while for the real and integer inputs, N will most likely be equal to 1, 2 or 3.

To get a sense of a typical number of runs an EASAP might require, let’s look at an example using the two equations above. For n = 5 (all real box inputs) and N = 3 (minimum, default and maximum values), the number of runs would need to fall somewhere between 15 runs for all inputs in isolation (3*5) and 243 runs with all interactions tested (35).

From the above example, you can see how the number of test runs can get quite large with a relatively small number of inputs, with over 200 possible runs with just 5 inputs. A large number of runs will not pose a problem for software applications that run in a few seconds, but you may need to be more selective in you testing for applications with longer run times.

A convenient way to set up parametric runs for testing purposes is to use parametric ranges on all real box inputs to be tested. This will minimize the number of EASAP submissions required. Details on the use of Linear Ranges can be found in the EASA Client mode documentation.

Note: When using Parametric Ranges, you will be investigating full interactions between the real boxes since the total number of runs is determined by multiplying all the Number of Values settings together.

Now that you have identified the particular inputs that may cause problems, there are a few corrective measures that you can employ to make your EASAP more robust.

If certain numerical inputs can tend to cause failures in the underlying software, one remedy is to reduce the range of allowable inputs by modifying the Lower Bound parameter, the Upper Bound parameter, or both for the Real box or Integer box object of concern.

A more drastic approach than just the tightening bounds on an input is to remove it altogether from the user interface and use a default value or relationship for it that you know will work.

Often with software applications there can be more than one method for computing a solution. The tendency will always be to choose the method that runs the fastest and finishes in the shortest time possible. Unfortunately, the fastest, most aggressive methods are usually the least robust since they may be ‘tuned’ to a certain small range of input settings. Therefore, the goal here will be to strike a balance between turn around time of an EASAP run and its robustness.

Some possible examples of methods that can be used in a more robust, conservative approach to getting a solution are as follows:

1. If a transient calculation, use smaller time steps.
2. Run an initial process with simpler, more robust settings to generate a better initial guess for the more aggressive solution approach.
3. Similar to the previous method, ramp up complexity of the problem by using several solution runs that restart from the previous run, and where the final run contains all the desired solution complexity.

Tip: Leave process objects that try aggressive approach first in your EASAP, and only resort to process objects containing the conservative approach when the aggressive approach fails by making use of Run if parameters.

It is almost certain that you will not be able to create all your EASAPs to be 100% robust and always produce a valid result. In fact, an EASAP that runs properly 90% of the time is not necessarily bad and may be perfectly acceptable to your users. However, you should do two things to provide users with useful feedback when things do go wrong:

1. Put checks into your EASAP to detect whether an underlying software application has produced a valid solution. To do this, use the Extract and Find objects to look for indicators of a valid solution in the diagnostic files or other output files.
   
   
2. Provide messages in the output to users that:
   • indicate when a valid solution has not been produced,
   • provide suggestions for actions on their part to increase the likelihood for getting a valid solution, and
   • suggest that they contact you with the details of the problem so you may be able to correct it.