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 317: 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 318: Common method to perform checks
The referenced parameters are detailed as follow:
- Scenario:
settings of the systems used for the workspace. It holds the settings of the scenario as specified in the UI. - 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
Concerning the List<Object> 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
- a coverage radius plugin (CRP) can be applied only to a generic system
- a propagation model plugin (PMP) can be applied to the system link, the interference link and the sensing link
- an event processing plugin (EPP) and its custom user interface (custom UI) cannot be applied to any of the scenario components
Consequently, the default informations passed to the consistency check as List<Object> of the plugins are as follows:
- for the antenna plugin (AP)
0: the radio system
1: the component applying the antenna, i.e. either the TX or the RX
2. for the coverage radius plugin (CRP)
0: the generic system
3. for the propagation model plugin (PMP)
0: the system link or the interference link in case not used for the sensing link
or in case where the PMP is used for the sensing link
0: the interference link
1: the sensing link
4. for the event processing plugin (EPP) the List<Object> is always empty.
note: the above numbers 0 and 1 are the list indices
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 order to avoid conflicts on the consistency check it is therefore very important that all default instances of the plugin types are checked, for instance like this for a PMP:
Figure 319: Example of a PMP checking for the default instances
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 320: Example of checking the validity of a nested plugin