The description of the plugins (e.g. PMP, EPP etc..) in the GUI panel informs you about its scope of application and this should be accordingly considered when you define your scenario.

In order to prevent the plugins from reporting physically wrong results the validity of actual parameter values are checked during the calculations (Figure 317). In case parameter values exceed the valid range, appropriate exceptions, e.g. RuntimeException, stops the plugin from doing further calculations.

Figure 318: RuntimeException checker in the calculation codes

This can be avoided if you are informed about such conflicts before starting the simulation by checking the consistency of your plugins like it is done for the rest of the SEAMCAT workspace. Therefore the method consistencyCheck() is available to all the plugins.

The basic principle on that is quite simple: the more extensive the checks the less the risk of running into problems during the simulation.

For this, each type of plugins provides the same method consistencyCheck() to perform the recommended checks: 

Figure 319: Common method to perform checks

The referenced parameters are detailed as follow:

• ConsistencyCheckContext: provides information about parameters relevant for the type of plugin.
• List<Object>:
  depending on the type of plugin it contains one or two objects which are either a Radio System or links which can be the system link, the interference link or the sensing link of generic systems. Corresponding details are described in the following sub-sections.
• Input
  the input parameters of the plugin
• Validator:
  provides the interface to the scenario check in returning the consistency check messages generated by the plugin

Figure 320: ConsistencyCheckContext interface

Concerning the ConsistencyCheckContext it is important to be aware of the applicability of plugins to the scenario components:

• an antenna plugin (AP) can be applied only to a radio system, i.e. a generic system or a cellular system, hence the Origin is set to SYSTEM;
• a coverage radius plugin (CRP) can be applied only to a generic system, , hence the Origin is either SYSTEM or in case the system is the interferer INTERFERENCE_LINK;
• a propagation model plugin (PMP) can be applied to the system link, the interference link and the sensing link, , hence the origin can be SYSTEM or INTERFERENCE_LINK, depending on to which link the PMP is applied;
• an event processing plugin (EPP) and its post processing user interface (PPUI) cannot be applied to any of the scenario components, hence its ConsistencyCheckContext is set to NULL, except the Scenario which is not available for other plugins.

This default information can be replaced or extended if the plugin is nested, i.e. if the plugin is used as an input parameter of another plugin (annotation, see the previous section 14.3.1).

In case you apply nested plugins it is highly recommended to check the validity of these nested plugins inside the consistency check of your 'parent' plugin. The below example of an EPP which uses a nested PMP wants only to show the principle of checking input parameters:

In case you apply nested plugins it is highly recommended to check the validity of these nested plugins inside the consistency check of your 'parent' plugin. The below example of an EPP which uses a nested PMP wants only to show the principle of checking input parameters:

Figure 321: Example of checking the validity of a nested plugin