| SUBMITTED:
Stardate 95563.6
| | FILED BY:
LCDR T. Fozka
| | SECURITY:
Level 3 - Restricted
| |
MISSION: Analyse schematics of Azedi subspace weapon, as located by Starfleet Intelligence
OUTCOME: Weapon currently has a small area of affect. No defence currently exists.
NARRATIVE: The analysis of the schematics of the Azedi weapon are as follows:
It is confirmed that the weapon is a subspace-disruption weapon, the development of which is banned by Federation Law due to the unpredictability of the weapon, as well as the damage to all warp propulsion engines. The weapon takes the form of a slow-moving device, which is most likely delivered by firing from a torpedo, although there is no information to state that it cannot be delivered via mines or other such explosive methods.
Detonation creates a subspace tear which prevents the formation of a warp field in the area of effect, rendering warp travel inoperable in this area. Escape from the area would require the use of impulse engines, which could take hours or days depending on the size of the disruption. Currently, the weapon in question only affects an area the size of a single ship, and dissipates after 8 minutes and 24 seconds, on average.
There is no defence against this weapon currently. Warp core damage can be limited should the warp drive be taken offline before the denotation occurs, and then moving out of the field of effect through impulse engines, and restarting the warp core. This is theoretical, and current simulations have provided no conclusive results. However, there is evidence that a detonation near an active warp core will prevent the warp core from restarting immediately, and in some cases, can cause a complete shutdown of the warp core, requiring drydocking to repair. Once again, simulations have been inconclusive as to a correlation between detonation distance and power, against the time required to start the warp core.
A hypothesis was postulated to shoot down the device before the payload is delivered. The results are shown here:
(Note that there is no value for 0, and the first point measures from the power at 1%)
The graph shows the detonation chance of the device, releasing its payload, at increasing power levels of a phaser array. The reverse percentage shows the chance of shooting the device and destroying it without the payload being released.
As you can see, there is a slight decrease in detonation chance as the power increases, as this is due to the device most likely being completely vapourised by the high energy emitted from the beam. Subsequent tests, however, have not proved reliable in which power yields the most optimal result, as high power levels also seem to release the payload.
In addition to this, simulations were done using different type of weapons, that could be divided into two broad categories: Kinetic and High Energy. The results are below:
The graph here shows the average chance of detonation of weapons in these categories. Note that there is a large discrepancy when using kinetic weapons such as torpedoes, compared to a phaser array, as there is a greater chance of the high energy weapons vapourising the contents of the device than that of a kinetic weapon.
RECOMMENDATION: Further simulations are running in order to stress test warp drives in terms of survivability with device detonation. Further simulations are also running in terms of weapons feasibility to stop these devices before they explode.
More data is needed in order to create a more accurate simulation. There is a possibility of potential recreating the weapon for ourselves; this will yield more accurate results in terms of testing, but progress will be slow due to Federation bans limiting our knowledge of these types of weapons. There is also a moral issue of recreating this weapon, even for testing and defence. We leave this up to command to decide if we should progress further.
It should also be noted that this evidence is very limited due to the limited knowledge we currently have and the time we had allocated to produce a preliminary report. Whilst this is a benchmark, it should be noted that these values may change with further testing.
OOC: Sorry this is a bit late! As I've mentioned, some of this data could change if I've made any errors and such OOCly; the IC reason is given above. I'll let people know if there are any changes.
