Starship Reactors and Dead Man Switches

[SailorSaturn13]

There is also a DEATH Star problem: any channel through which a core is ejected would be an ideal attack angle. At least Hull opening must be active. So a passive system cannot be implemented AT ALL.

GStone -- the antimatter-dump/core-ejection system failed every single time it was called up on in TNG.

It appears that GCS had design problems - the core is wrongly placed and instable. Voyager ejected core in "Day of Honor" and in "Renaissance man". In the former, it was subseqvently attacked by THORIUM - driven ships and couldn't defend itself because of energy shortage.

If you've got any evidence that such a system exists, do share.

Like I said, backstage info. Not canon. But then, Fuel pods NEVER create problems, do they?

[GStone]

You know, I can just image the entire lower rear of an ISD disconnects from the ship. A couple of the pieces disconnect from the larger part and we see several tiny spots glow from inside the 'hole' in the back of the ISD, pushing it forward. Then, the ISD jumps to hyperspace right before the ion engines and the reactor explodes. It'd be a cool visual.

How could it jump to hyperspace, if it has just lost it's main power? I have always thought, that would need huge amounts of energy.

Is there a canon evidence, that they have a battery backup, which is sufficient for a hyperspace jump?

Well, I'm assume that their got some reserve energy storage tanks that they could shunt the energy from in emergencies. To shields or weapons in a battle, to the hyperdrive for a brief jump if the reactor is gonna explode, but I've got no evidence that they've got it.

Given that we know fusion powers everything (ep 3 novel) and we have evidence that hyperspace is a static continuum distortion (visuals of movies of space and enegines working in hyperspace and the mention of a warp in the ep 6 novelization), it'd be a good idea if they weren't supplying all the energy to continuously keep space contracted.

My guess would be that the energy initially supplied by the vessel somehow alters the ambient energy fields of the space the vessel passes through, so that the distortion is retained without more energy from the vessel. After the initial expenditure, energy would be expended for just 2 other reasons. It'd be to alter course somehow (maybe some kind of force field control, I'd image, since we have seen both spherical and planar shields). After this, it'd be done to stop, wher energy would be expelled by the vessel to disrupt the continuum distortion and the engines return to normal power.

This would conserve their energy reserves and reminds me of what the Feds tried to do in TNG. Given the dissparities between energy generation levels of the 2 franchises, this might allow larger vessels, such as an ISD, to jump to hyperspace with a relatively small amount of power and keep going till they got somewhere to get a replacement. If the ISD designers were smart, they'd put in smaller fusion generators for emergencies. Fighters that can go to hyperspace on their own have small fusion generators, I assume, so having a few for the 'continuum contracted field controllers' and the 'continuum contracted field dispersers' would be a sensical back up plan.

[Who is like God arbour]

• 1.)
  That's all only speculation. As you have said yourself, you don't know, if there is a kind of battery backup, which can supply enough energy for an hyperspace jump. You don't even know, if it is possible at all, that the "entire lower rear of an ISD" can "disconnect from the ship".
  I have no problems with speculations, if they are there to explain something, which indisputable is there or has happened, as long as the speculations aren't contradicted by other evidences. But to prove, that something is possible, if said something itself is only a speculation, with another speculation is going too far.

• 2.)
  The question, how the hyperdrive is functioning, has nothing to do with this thread. I think, there are not enough informations, to try to explain its operating mode. But if you want to discuss this further, I would propose that you create a new thread. It doesn't belong in this thread and deserves its own thread.

[GStone]

That's true. It's the only thing I can think of at the moment to make it all fit.

[Who is like God arbour]

Does someone think, that Ted C will still answer?

How much time shall I give him?

I mean, I know that he has had enough time to post on SDN [at least 11 posts] since his last post here [01. March 2007]. He has had even enough time to write at SDN [...]

Ugh. The density is greater than a neutron star. It sucks the energy right out of you.

[...] a day after his last post here.

I'm reluctant to assess his silence as a sign, that he has conceded but is to gutless to state it publicly.

What are your opinions?

Maybe we can invite Keiran to participate in this debate or at least ask him, to convey our request to Ted C, to finish this debate like a gentleman and not like a lout.

Maybe he can even convey an invitation to Darth Wong, the writter of the article "Engineering and Star Trek". He should have the possibility to defend himself. It wouldn't be necessary, that he engages in this debatte. It would be enough, if he describes exactly and concrete, how he would design the fail-safe-systems for the warp core, considering all mentioned problems. After all, he was the one, who has claimed, that he, as a competent engineer, would employ "dead man's switch" principles wherever possible, so that a system is ideally activated by a failure condition. I think, he should have the chance to elaborate and prove this claim and prove therewith, that he is not only a braggart.

[GStone]

I don't know how long to give Ted C. I'm not sure when I last saw his name at the bottom of the main page. I know Wong has known of this board for some time, but he has chosen so far to not show up. I think the last time he showed up at a board that wasn't his was when Darkstar had his board up. You can ask Keiran, if you want. I'm sure it wouldn't hurt.

Edit:

Maybe he can even convey an invitation to Darth Wong, the writter of the article "Engineering and Star Trek". He should have the possibility to defend himself. It wouldn't be necessary, that he engages in this debatte. It would be enough, if he describes exactly and concrete, how he would design the fail-safe-systems for the warp core, considering all mentioned problems. After all, he was the one, who has claimed, that he, as a competent engineer, would employ "dead man's switch" principles wherever possible, so that a system is ideally activated by a failure condition. I think, he should have the chance to elaborate and prove this claim and prove therewith, that he is not only a braggart.

Now that I think of it, I'm not sure if I've ever heard him elaborate more than saying dead man switch and referencing real world situations.

[Jedi Master Spock]

I'm reluctant to assess his silence as a sign, that he has conceded but is to gutless to state it publicly.

What are your opinions?

Maybe we can invite Keiran to participate in this debate or at least ask him, to convey our request to Ted C, to finish this debate like a gentleman and not like a lout.

Calling Ted C "gutless" and "a lout" is not polite and constitutes a personal attack.

[Ted C]

For what it's worth, the debate seems to have grown pointless. You keep trying to spin out reasons why having a failsafe system is more dangerous than not having one, or excuses for why you'd rather die than have your core or pod eject before it explodes, or spin some reason why a different failsafe would be better.

The impression I finally got was that no one was listening to what I said, since I kept seeing the same arguments repeated over and over. Not wanting to end up doing the same thing myself, I found no reason to post.

[SailorSaturn13]

The International Thermonuclear Experimental Reactor in Cadarache, France will have one half gram of deuterium/tritium fuel [2], which will be heated to its operating temperature of greater than 10 keV (over 100 million degrees Celsius) [3]. Maybe someone can calculate, how many damage that can create, respectively how much matter could be vaporized therewith.

A gram has some 630 GJ (150 Ton TNT ) of fusion potential.

Actually, I believe small explosive release charges would do the trick, similar to the explosive charges that release the emergency pods in case of a ship wide failure.

Or destroy the core even quicker.

Point is, a "passive" failsafe system is hard to designate, sometimes impossible and sometimes indiscutable because of side effects. An active system IS used and (judging on Voyager) works fine. In E-D, they probably relied on separation option.

[Wyrm]

Alright, I'll attempt to pick up where Ted C left off.

First off, I'll define what a "failure mode" is, because you'll see a lot of that term from me. A failure mode is an engineering term that describes the process in which a device fails, and unlike a mere description of the symtoms, a failure mode is a rather complete description of the failure process. This includes the preconditions of the failure, the ultimate and proximate causes, the way a device was being used, and all subsidiary and resulting failures.

When you design a system, you also (by implication) design its failure modes. The "dead man's switch" is a design philosophy (not a special gizmo) such that as much as possible failure modes should result in the least amount of harm to surrounding structures and personnel, all without active intervention. The "dead man's switch" (DMS) principle, for instance, would dictate that, given two designs under a certain failure condition where one design explodes in your face and kills you, and the other stalls and shuts down, that you choose the design that stalls over the one that explodes. Please note that the solutions are not one-size-fits-all, as failure modes (and mechanisms employing "dead man's switch" principles) are particular to the system involved.

Sometimes, no matter how hard you try, you cannot eliminate all harmful failure modes. This is where cost/benefit analysis comes in. In C/B analysis, you choose failure modes that minimizes cost and maximizes benefits in all conceivable situations. This includes costs of repair and recovery, cost in human lives, and benefits of retaining equipment.

With that out of the way, let's look at a pod designed with the DMS principle, vs the standard pod. Sez Mike:

Competent engineers would have designed the antimatter tanks so that they must be retained against a constant ejection pressure (perhaps driven by springs, gas pressure, or magnetic repulsion), thus utilizing the "dead man's switch" principle. If the containment magnets are connected in series with the tank retainer magnets, the tanks will be blown free as soon as the fields begin to weaken.

Please note carefully what is being said: it is not possible to cut the tank retainer fields without also cutting the containment fields, and vice versa. So long as the contaiment fields are powered up above some threshold, the retainer magnets retain the pod. If the containment fields fall below that threshold, chosen by C/B analysis, then the retainer fields lose power first and the pod is ejected, in time such that the containment fields fail completely when the pod is at some safe distance. Each pod has it's own independent ejection system; that pod ejects only when it's particular containment field drops below the chosen threshold. It doesn't even know whether other pods have been ejected. Each pod has it's own independent circuit on the ship's main power grid; the power condition of any other system or pod is irrelevant to the power condition of this one. Furthermore, the failure of main power automatically switches in a battery to supply the containment (and retention) fields for a time.

Is there any situation where these DMS-principle pods would have a failure mode that is less desirable than the standard pods? Quite frankly, it's hard to think of one. Because the failure of one pod's contaiment field only affects that particular pod's retention field, only that particular pod will be ejected in that failure mode.

When will all the pods be ejected? When and only when each and every pod suffers containment failure. (And in that case, they shouldn't be retained anyway.)

Is it possible to make a DMS pod that you can save by correct crew action? Yes, by having the retaining magnet tuned such that it loses retaining pressure ONLY when the containment field decays to some threshold, and never before. (If it takes minutes for a containment field to decay to that point, then the pod is retained until that time.) Besides which, we have an emergency battery to extend the life of the fields and to handle any power dips (for a time).

Can a computer glitch cause the loss of the pods? Yes, but only by cutting containment power to the pods, which means they shouldn't be retained anyway (after the battery(ies) runs down).

Is there a failure mode that leads to a catastrophic outcome? Yes, combat damage, and loss of containment energy due to power failure within a starbase or such. But these failures will be catastrophic with a standard pod as well.

[GStone]

Alright, I'll attempt to pick up where Ted C left off.

Please note carefully what is being said: it is not possible to cut the tank retainer fields without also cutting the containment fields, and vice versa.

Why the hell would you design it that way? If there's a problem that needs you to remove the pod to prevent failure, you would want control of it being locked in place. If you come to the rescue of another ship that has used up/lost all its antimatter, you could give them one, so they could follow you back to a nearby starbase under their own power to get a replacement for themselves and you can get your pod back (assuming it'd fit in the rescued ship).

So long as the contaiment fields are powered up above some threshold, the retainer magnets retain the pod. If the containment fields fall below that threshold, chosen by C/B analysis, then the retainer fields lose power first and the pod is ejected, in time such that the containment fields fail completely when the pod is at some safe distance.

This uses a faulty premise. Aside from the examples I provided just above, the threshold you speak of would have to be very small because we are talking of containing antimatter, which causes automatic reactions with matter.

When dealing with antimatter, a partial containment field loss causes destruction of the pod. You don't need the field to be completely nonexistent to do that.

Each pod has it's own independent ejection system; that pod ejects only when it's particular containment field drops below the chosen threshold. It doesn't even know whether other pods have been ejected.

They should have some knowledge because there needs to be feed lines turned on and off when one pod empties and you start using another. They're probably set up, so they can use the generator of the other pods if it's necessary. There is no need to keep a containment field up for antimatter when there's no antimatter to contain in the pod.

Each pod has it's own independent circuit on the ship's main power grid;

This is a bad design. In situations, such as in The Last Outpost (TNG), they couldn't keep life support up, couldn't use impulse or warp. The main popwer grid was being effected. Were they worried about antimatter containment? No, their main concern was keeping everyone from freezing to death. This demonstrates that antimatter pods have their own independent power system for containment.

There is also all the times when main power is offline and they don't worry about antimatter containment, sometimes even the lights aren't effected. Even if they were using fusion generator back ups that autmatically kicked in, The Last Outpost suggests independent power generation for the pods. If they could have used back up fusion generators in TLO, they should have been able to divert energy to life support, but life support wasn't working enough to keep them heated. So, they ability to divert energy was probably being effected, too.

Many, including MW, have ridiculed Trek (including Fed ships) for not being decentralized enough, especially in terms of computer cores. This idea that you're proposing reduces the level of decentralization of the containment fields already in place.

Furthermore, the failure of main power automatically switches in a battery to supply the containment (and retention) fields for a time.

And Contagion tells us there are several back ups that keep things running properly.

Is there any situation where these DMS-principle pods would have a failure mode that is less desirable than the standard pods? Quite frankly, it's hard to think of one. Because the failure of one pod's contaiment field only affects that particular pod's retention field, only that particular pod will be ejected in that failure mode.

Only when you ignore the fact that the failure of one containment field destroys part of the pod, which effects containment of the whole pod, causing an explosion, which could effect the other pods.

Any containment loss that lets antimatter escape will cause an explosion, which will effect the pod's ability to keep the containment field up even partially.

Is it possible to make a DMS pod that you can save by correct crew action? Yes, by having the retaining magnet tuned such that it loses retaining pressure ONLY when the containment field decays to some threshold, and never before. (If it takes minutes for a containment field to decay to that point, then the pod is retained until that time.)

The reason why it takes some time before they loose containment is because of the many back ups already in place to keep it from happening, so the crew has time to fix the problem, presumably.

Besides which, we have an emergency battery to extend the life of the fields and to handle any power dips (for a time).

Since the pod are independent already, they most likely already have their own back ups.

Can a computer glitch cause the loss of the pods? Yes, but only by cutting containment power to the pods, which means they shouldn't be retained anyway (after the battery(ies) runs down).

So, with your system..., not only would a computer glitch cause you to waste time because of a faulty part makes the thing eject...you also loose the pod itself because you've designed the pod to explode because it isn't connected to its holding place because this 'retention field' is no longer active.

Assuming the back up battery in your design works, the pod shouldn't be ejected, but if the glitch is enough to mess with the battery, too, the pod will be ejected and you're lucky, if it doesn't explode before it leaves the ship.

And when you translate that into an example of when the ship is inside the hangar of a space station, you will cause damage to your ship and the station.

So, if you emit that a glitch can cause the pod to automatically eject, it'd also be a glitch that makes the thing explode and you are praying that it doesn't explode while it's still inside the ship.

That is a very bad idea and illogical.

Is there a failure mode that leads to a catastrophic outcome? Yes, combat damage, and loss of containment energy due to power failure within a starbase or such. But these failures will be catastrophic with a standard pod as well.

Not when they have their own independent power generation for containment and not when containment field operation isn't linked to its ability to stay connected to the ship in its proper place.

A glitch causes the pod to eject and, if you're lucky, it will not explode before it leaves the ship. This stuff isn't just sitting at the edge of the hull.


````````````
There was a proposition of using small explosions (which are using a passive sensor to know when to detonate) to push the pods and core out and have them move on some kind of rollers, which might work to make the system as passive as possible, but it won't work if you link the pods' ability to stay put with the containment field.

To even attempt to make your design of any use, they should be unlinked and used specific, passive sensors, but even that doesn't solve all the problems this design creates. If you want a cost/benefit analysis, this one is worse than the one in use.

[Wyrm]

Alright, I'll attempt to pick up where Ted C left off.

Please note carefully what is being said: it is not possible to cut the tank retainer fields without also cutting the containment fields, and vice versa.

Why the hell would you design it that way? If there's a problem that needs you to remove the pod to prevent failure, you would want control of it being locked in place. If you come to the rescue of another ship that has used up/lost all its antimatter, you could give them one, so they could follow you back to a nearby starbase under their own power to get a replacement for themselves and you can get your pod back (assuming it'd fit in the rescued ship).

Why the hell would you want to remove a loaded pod? With a substance as volitile as antimatter, I wouldn't even want to touch an antimatter pod unless it was empty. Besides, antimatter isn't refilled by exchanging pods; it's refilled through an antimatter fill port. If you're really on a rescue mission, the rescue ship would have the equipment to fill antimatter pods. I'm sure such equipment is at every antimatter depot in the Federation.

So long as the contaiment fields are powered up above some threshold, the retainer magnets retain the pod. If the containment fields fall below that threshold, chosen by C/B analysis, then the retainer fields lose power first and the pod is ejected, in time such that the containment fields fail completely when the pod is at some safe distance.

This uses a faulty premise. Aside from the examples I provided just above, the threshold you speak of would have to be very small because we are talking of containing antimatter, which causes automatic reactions with matter.

When dealing with antimatter, a partial containment field loss causes destruction of the pod. You don't need the field to be completely nonexistent to do that.

Rediculous. That only happens if the operating field strength is only barely above a minimum level for containment. I don't know why you would design such a critical system that is always that close to catastrophic failure.

Besides, even if you were correct, what would you think that an actively-ejected pod would behave any differently? Whether the ejection was active or passive, when the pod is ejected, it is disconnected from its source of sustaining power. That means the containment field decays. By your logic, the standard pod explodes instantly, when the pod has barely gotten anywhere, much less to a safe distance. If containment failure is instantaneous as you say, then standard pods are obviously equipped with small storage cells to sustain the field for as long as it takes for the pod to be thrown a safe distance. A passive DMS pod would have the same feature.

Try again.

Each pod has it's own independent ejection system; that pod ejects only when it's particular containment field drops below the chosen threshold. It doesn't even know whether other pods have been ejected.

They should have some knowledge because there needs to be feed lines turned on and off when one pod empties and you start using another. They're probably set up, so they can use the generator of the other pods if it's necessary. There is no need to keep a containment field up for antimatter when there's no antimatter to contain in the pod.

"Cost/benefit." You speak it?

The power it takes to sustain a containment field is obviously infinitesimal compared to running the rest of the ship. In WOK, they couldn't even run the regular lights, and had to go to awful red emergency lights, yet they still obviously had antimatter containment. If the containment field really is that much of a burden on the power system, why couldn't they increase the emergency battery size by a little bit and run the regular lights so that people could see what they were doing?

So if the cost of contaiment really is that low, would you waste a little power sustaining containment fields that contain no antimatter in exchange for a near-foolproof failsafe for containment pods? YES! Run the containment fields all the time! They're cheap, and you don't have to compromise a desirable failure mode.

Each pod has it's own independent circuit on the ship's main power grid;

This is a bad design. In situations, such as in The Last Outpost (TNG), they couldn't keep life support up, couldn't use impulse or warp. The main popwer grid was being effected. Were they worried about antimatter containment? No, their main concern was keeping everyone from freezing to death. This demonstrates that antimatter pods have their own independent power system for containment.

And what, pray tell, would be different in the DMS containment pods? The design change I propose for the pods would not reqiure you to give up any redundancy already present in the Galaxy class or other Federation ships. You seem to think "independent" means "exclusive." It does not. It means that it is shielded from failures of other, unrelated systems.

There is also all the times when main power is offline and they don't worry about antimatter containment, sometimes even the lights aren't effected. Even if they were using fusion generator back ups that autmatically kicked in, The Last Outpost suggests independent power generation for the pods. If they could have used back up fusion generators in TLO, they should have been able to divert energy to life support, but life support wasn't working enough to keep them heated. So, they ability to divert energy was probably being effected, too.

Again, I am not asking you to give up any redundancy already present.

Many, including MW, have ridiculed Trek (including Fed ships) for not being decentralized enough, especially in terms of computer cores. This idea that you're proposing reduces the level of decentralization of the containment fields already in place.

And how is decentralization a bad thing? Especially in an antimatter pod, where the failure of contaiment is a very decentralized event itself.

Furthermore, the failure of main power automatically switches in a battery to supply the containment (and retention) fields for a time.

And Contagion tells us there are several back ups that keep things running properly.

And I'm not asking you to give any of these backups up.

Is there any situation where these DMS-principle pods would have a failure mode that is less desirable than the standard pods? Quite frankly, it's hard to think of one. Because the failure of one pod's contaiment field only affects that particular pod's retention field, only that particular pod will be ejected in that failure mode.

Only when you ignore the fact that the failure of one containment field destroys part of the pod, which effects containment of the whole pod, causing an explosion, which could effect the other pods.

Any containment loss that lets antimatter escape will cause an explosion, which will effect the pod's ability to keep the containment field up even partially.

... What? Are you deliberately misinterpreting what I wrote? By "one pod's containment field", I'm obviously talking about the entire containment field assembly of a single pod. A failure of one of the pod's component containment fields is considered a failure of the pod's entire containment field.

Is it possible to make a DMS pod that you can save by correct crew action? Yes, by having the retaining magnet tuned such that it loses retaining pressure ONLY when the containment field decays to some threshold, and never before. (If it takes minutes for a containment field to decay to that point, then the pod is retained until that time.)

The reason why it takes some time before they loose containment is because of the many back ups already in place to keep it from happening, so the crew has time to fix the problem, presumably.

And during which time the containment field of the pod is still full-strength. The DMS pod does not eject, just like a standard pod. Try again.

Besides which, we have an emergency battery to extend the life of the fields and to handle any power dips (for a time).

Since the pod are independent already, they most likely already have their own back ups.

So I've added nothing new, and the DMS pod still will not explode in any scenario where the standard pod does not.

Can a computer glitch cause the loss of the pods? Yes, but only by cutting containment power to the pods, which means they shouldn't be retained anyway (after the battery(ies) runs down).

So, with your system..., not only would a computer glitch cause you to waste time because of a faulty part makes the thing eject...you also loose the pod itself because you've designed the pod to explode because it isn't connected to its holding place because this 'retention field' is no longer active.

... Whaaat? If the pod loses all power, then it's containment field is collapsing. IT'S ABOUT TO BLOW! Why would I want to retain a pod that is in imminent danger of expoding in my face and killing me and destroying the entire ship.

As long as a DMS pod has power, from any source that can sustain the containment field, it will be retained. If it loses power such that the field cannot be sustained, then it is ejected as a failure mode.

Repeat the above paragraph to me in your own words. I want to make sure you actually understand this!

Assuming the back up battery in your design works, the pod shouldn't be ejected, but if the glitch is enough to mess with the battery, too, the pod will be ejected and you're lucky, if it doesn't explode before it leaves the ship.

"Multiply redundant isolated systems," yes? If there's main power, then it doesn't matter if the battery goes bad, the pod will accept a power feed from any system that will sustain its containment field. We have systems today that will do this for you. They're called uninterruptable power supplies (UPS). They're on every major server farm on the internet. They switch instantly from line power to battery power in case the line power goes down. They'll even self-diagnose and tell you if the battery has gone bad.

And when you translate that into an example of when the ship is inside the hangar of a space station, you will cause damage to your ship and the station.

No, it won't.

So, if you emit that a glitch can cause the pod to automatically eject, it'd also be a glitch that makes the thing explode and you are praying that it doesn't explode while it's still inside the ship.

There is NO GLITCH that will cause a DMS pod to eject, except the total loss of all sources of containment field power. In that case, containment failure is imminent anyway.

That is a very bad idea and illogical.

No it isn't, because the failure mode you describe does not exist.

On an active eject, a computer glitch can cause the pod to eject even when there is sufficient sustaining power. That is, when the pod would not explode! Furthermore, on an active eject, a catatonic computer will miss a containment power drop and the pod will explode inside your ship, killing you. For a DMS pod, these failure modes do not exist.

Is there a failure mode that leads to a catastrophic outcome? Yes, combat damage, and loss of containment energy due to power failure within a starbase or such. But these failures will be catastrophic with a standard pod as well.

Not when they have their own independent power generation for containment and not when containment field operation isn't linked to its ability to stay connected to the ship in its proper place.

So you want a pod with a fault in its safety system to remain anywhere near you, when it contains a volitile substance with the explosive potential to destroy your ship?

I'm very glad you don't design safety systems in the real world.

A glitch causes the pod to eject and, if you're lucky, it will not explode before it leaves the ship. This stuff isn't just sitting at the edge of the hull.

It's not "luck"; you design the pod that way. You design the containment fields with enough slack so that it takes several seconds for the fields to decay from the ejection threshold to the minimum physical level of containment. If you can't do it, put in multiple integral capacitors to supply power to sustain its containment field for the trip out (which you would have to have anyway with the standard pods), and keep them charged while the power is connected.

````````````
There was a proposition of using small explosions (which are using a passive sensor to know when to detonate) to push the pods and core out and have them move on some kind of rollers, which might work to make the system as passive as possible, but it won't work if you link the pods' ability to stay put with the containment field.

If you use a spring, gas pressure, or magnetic repulsion for the pods, you wouldn't need explosives for the pods. But what does this have to with a core ejection system (if it's necessary — remember, you would rather have the warp core stall out rather than have to eject it)? And if you REALLY wanted an active pod ejection system, then you can always put the pod proper and it's passive ejection system into a single assembly, and put THAT on an active eject system.

To even attempt to make your design of any use, they should be unlinked and used specific, passive sensors, but even that doesn't solve all the problems this design creates. If you want a cost/benefit analysis, this one is worse than the one in use.

I ask again, why would you want an antimatter pod with a fault in its safety system to remain anywhere near you? You want the safety system for a single pod to fail in a way that will not destroy your ship. That means you would rather have the pod eject than retain it if it's safety system is faulty.

[GStone]

Alright, I'll attempt to pick up where Ted C left off.

Please note carefully what is being said: it is not possible to cut the tank retainer fields without also cutting the containment fields, and vice versa.

Why the hell would you design it that way? If there's a problem that needs you to remove the pod to prevent failure, you would want control of it being locked in place. If you come to the rescue of another ship that has used up/lost all its antimatter, you could give them one, so they could follow you back to a nearby starbase under their own power to get a replacement for themselves and you can get your pod back (assuming it'd fit in the rescued ship).

Why the hell would you want to remove a loaded pod? With a substance as volitile as antimatter, I wouldn't even want to touch an antimatter pod unless it was empty. Besides, antimatter isn't refilled by exchanging pods; it's refilled through an antimatter fill port. If you're really on a rescue mission, the rescue ship would have the equipment to fill antimatter pods. I'm sure such equipment is at every antimatter depot in the Federation.

So long as the contaiment fields are powered up above some threshold, the retainer magnets retain the pod. If the containment fields fall below that threshold, chosen by C/B analysis, then the retainer fields lose power first and the pod is ejected, in time such that the containment fields fail completely when the pod is at some safe distance.

This uses a faulty premise. Aside from the examples I provided just above, the threshold you speak of would have to be very small because we are talking of containing antimatter, which causes automatic reactions with matter.

When dealing with antimatter, a partial containment field loss causes destruction of the pod. You don't need the field to be completely nonexistent to do that.

Rediculous. That only happens if the operating field strength is only barely above a minimum level for containment. I don't know why you would design such a critical system that is always that close to catastrophic failure.

Besides, even if you were correct, what would you think that an actively-ejected pod would behave any differently? Whether the ejection was active or passive, when the pod is ejected, it is disconnected from its source of sustaining power. That means the containment field decays. By your logic, the standard pod explodes instantly, when the pod has barely gotten anywhere, much less to a safe distance. If containment failure is instantaneous as you say, then standard pods are obviously equipped with small storage cells to sustain the field for as long as it takes for the pod to be thrown a safe distance. A passive DMS pod would have the same feature.

Try again.

Each pod has it's own independent ejection system; that pod ejects only when it's particular containment field drops below the chosen threshold. It doesn't even know whether other pods have been ejected.

They should have some knowledge because there needs to be feed lines turned on and off when one pod empties and you start using another. They're probably set up, so they can use the generator of the other pods if it's necessary. There is no need to keep a containment field up for antimatter when there's no antimatter to contain in the pod.

"Cost/benefit." You speak it?

The power it takes to sustain a containment field is obviously infinitesimal compared to running the rest of the ship. In WOK, they couldn't even run the regular lights, and had to go to awful red emergency lights, yet they still obviously had antimatter containment. If the containment field really is that much of a burden on the power system, why couldn't they increase the emergency battery size by a little bit and run the regular lights so that people could see what they were doing?

So if the cost of contaiment really is that low, would you waste a little power sustaining containment fields that contain no antimatter in exchange for a near-foolproof failsafe for containment pods? YES! Run the containment fields all the time! They're cheap, and you don't have to compromise a desirable failure mode.

Each pod has it's own independent circuit on the ship's main power grid;

This is a bad design. In situations, such as in The Last Outpost (TNG), they couldn't keep life support up, couldn't use impulse or warp. The main popwer grid was being effected. Were they worried about antimatter containment? No, their main concern was keeping everyone from freezing to death. This demonstrates that antimatter pods have their own independent power system for containment.

And what, pray tell, would be different in the DMS containment pods? The design change I propose for the pods would not reqiure you to give up any redundancy already present in the Galaxy class or other Federation ships. You seem to think "independent" means "exclusive." It does not. It means that it is shielded from failures of other, unrelated systems.

There is also all the times when main power is offline and they don't worry about antimatter containment, sometimes even the lights aren't effected. Even if they were using fusion generator back ups that autmatically kicked in, The Last Outpost suggests independent power generation for the pods. If they could have used back up fusion generators in TLO, they should have been able to divert energy to life support, but life support wasn't working enough to keep them heated. So, they ability to divert energy was probably being effected, too.

Again, I am not asking you to give up any redundancy already present.

Many, including MW, have ridiculed Trek (including Fed ships) for not being decentralized enough, especially in terms of computer cores. This idea that you're proposing reduces the level of decentralization of the containment fields already in place.

And how is decentralization a bad thing? Especially in an antimatter pod, where the failure of contaiment is a very decentralized event itself.

Furthermore, the failure of main power automatically switches in a battery to supply the containment (and retention) fields for a time.

And Contagion tells us there are several back ups that keep things running properly.

And I'm not asking you to give any of these backups up.

Is there any situation where these DMS-principle pods would have a failure mode that is less desirable than the standard pods? Quite frankly, it's hard to think of one. Because the failure of one pod's contaiment field only affects that particular pod's retention field, only that particular pod will be ejected in that failure mode.

Only when you ignore the fact that the failure of one containment field destroys part of the pod, which effects containment of the whole pod, causing an explosion, which could effect the other pods.

Any containment loss that lets antimatter escape will cause an explosion, which will effect the pod's ability to keep the containment field up even partially.

... What? Are you deliberately misinterpreting what I wrote? By "one pod's containment field", I'm obviously talking about the entire containment field assembly of a single pod. A failure of one of the pod's component containment fields is considered a failure of the pod's entire containment field.

Is it possible to make a DMS pod that you can save by correct crew action? Yes, by having the retaining magnet tuned such that it loses retaining pressure ONLY when the containment field decays to some threshold, and never before. (If it takes minutes for a containment field to decay to that point, then the pod is retained until that time.)

The reason why it takes some time before they loose containment is because of the many back ups already in place to keep it from happening, so the crew has time to fix the problem, presumably.

And during which time the containment field of the pod is still full-strength. The DMS pod does not eject, just like a standard pod. Try again.

Besides which, we have an emergency battery to extend the life of the fields and to handle any power dips (for a time).

Since the pod are independent already, they most likely already have their own back ups.

So I've added nothing new, and the DMS pod still will not explode in any scenario where the standard pod does not.

Can a computer glitch cause the loss of the pods? Yes, but only by cutting containment power to the pods, which means they shouldn't be retained anyway (after the battery(ies) runs down).

So, with your system..., not only would a computer glitch cause you to waste time because of a faulty part makes the thing eject...you also loose the pod itself because you've designed the pod to explode because it isn't connected to its holding place because this 'retention field' is no longer active.

... Whaaat? If the pod loses all power, then it's containment field is collapsing. IT'S ABOUT TO BLOW! Why would I want to retain a pod that is in imminent danger of expoding in my face and killing me and destroying the entire ship.

As long as a DMS pod has power, from any source that can sustain the containment field, it will be retained. If it loses power such that the field cannot be sustained, then it is ejected as a failure mode.

Repeat the above paragraph to me in your own words. I want to make sure you actually understand this!

Assuming the back up battery in your design works, the pod shouldn't be ejected, but if the glitch is enough to mess with the battery, too, the pod will be ejected and you're lucky, if it doesn't explode before it leaves the ship.

"Multiply redundant isolated systems," yes? If there's main power, then it doesn't matter if the battery goes bad, the pod will accept a power feed from any system that will sustain its containment field. We have systems today that will do this for you. They're called uninterruptable power supplies (UPS). They're on every major server farm on the internet. They switch instantly from line power to battery power in case the line power goes down. They'll even self-diagnose and tell you if the battery has gone bad.

And when you translate that into an example of when the ship is inside the hangar of a space station, you will cause damage to your ship and the station.

No, it won't.

So, if you emit that a glitch can cause the pod to automatically eject, it'd also be a glitch that makes the thing explode and you are praying that it doesn't explode while it's still inside the ship.

There is NO GLITCH that will cause a DMS pod to eject, except the total loss of all sources of containment field power. In that case, containment failure is imminent anyway.

That is a very bad idea and illogical.

No it isn't, because the failure mode you describe does not exist.

On an active eject, a computer glitch can cause the pod to eject even when there is sufficient sustaining power. That is, when the pod would not explode! Furthermore, on an active eject, a catatonic computer will miss a containment power drop and the pod will explode inside your ship, killing you. For a DMS pod, these failure modes do not exist.

Is there a failure mode that leads to a catastrophic outcome? Yes, combat damage, and loss of containment energy due to power failure within a starbase or such. But these failures will be catastrophic with a standard pod as well.

Not when they have their own independent power generation for containment and not when containment field operation isn't linked to its ability to stay connected to the ship in its proper place.

So you want a pod with a fault in its safety system to remain anywhere near you, when it contains a volitile substance with the explosive potential to destroy your ship?

I'm very glad you don't design safety systems in the real world.

A glitch causes the pod to eject and, if you're lucky, it will not explode before it leaves the ship. This stuff isn't just sitting at the edge of the hull.

It's not "luck"; you design the pod that way. You design the containment fields with enough slack so that it takes several seconds for the fields to decay from the ejection threshold to the minimum physical level of containment. If you can't do it, put in multiple integral capacitors to supply power to sustain its containment field for the trip out (which you would have to have anyway with the standard pods), and keep them charged while the power is connected.

````````````
There was a proposition of using small explosions (which are using a passive sensor to know when to detonate) to push the pods and core out and have them move on some kind of rollers, which might work to make the system as passive as possible, but it won't work if you link the pods' ability to stay put with the containment field.

If you use a spring, gas pressure, or magnetic repulsion for the pods, you wouldn't need explosives for the pods. But what does this have to with a core ejection system (if it's necessary — remember, you would rather have the warp core stall out rather than have to eject it)? And if you REALLY wanted an active pod ejection system, then you can always put the pod proper and it's passive ejection system into a single assembly, and put THAT on an active eject system.

To even attempt to make your design of any use, they should be unlinked and used specific, passive sensors, but even that doesn't solve all the problems this design creates. If you want a cost/benefit analysis, this one is worse than the one in use.

I ask again, why would you want an antimatter pod with a fault in its safety system to remain anywhere near you? You want the safety system for a single pod to fail in a way that will not destroy your ship. That means you would rather have the pod eject than retain it if it's safety system is faulty.

I'll sum up everything because I lost it all and I don't feel like going back over point by point again.

Your systems sucks. It's suicidal. The antimatter containment field will only maintain itself for a few seconds before the first bit of antimatter escapes when the generator shuts off, destroying the pod. Linking the containment field with the release is suicide because the pod won't just jump out of the ship without contacting anything.

You claim you can get the pod away and get a safe distance, but you don't have the time when you link when the containment field fails with the release, even when you want to give yourself a few seconds. You'll be lucky if a few seconds is all it takes to get the pod outside the ship, even with a passive system. Antimatter pods aren't sitting on the hull.

You have made statements in your last post, but have quoted your answers from my last post.

I am the one that has had to remind you and Ted C that there are independent systems for the antimatter pods. Don't act like you said it first.

You propose that a glitch would cause every single safety as well as their corresponding back ups to fail, but the odds of that happening are astronomically impossible. Don't give me any 'it might happen'. Yeah and Q will actually will himself into our reality, if someone made video of him doing it. 'It might happen'.

You're so freaked out about moving a stable antimatter pod that survives even when Voyager crashed onto an ice planet when the amount it takes to kill someone is an infinitesimally smaller amount of energy than the total warhead yield equivilent any antimatter pod has. It's barely anything of an arc that could kill you and you're worried about moving a stble pod that survives when a ship crashes on an ice planet?

If it survives the crash of a starship, it can stand a controlled move. And what I have spoken of in my last post and the ones before it is the destruction of one antimatter pod inside the ship will probably destroy another. The raised and empty containment field in your design would only protect the air inside the field...maybe...and most likely not.

Your design increases cost and decreases benefits at the same time by linking the relsease with the containment failure and increases the centralization of the ship. You decrease the opportunity of the redundency systems to work because it will explode inside the ship because the release and the field collapse are linked.

What the fuck is the point of keeping a contaiment field up when there's no antimatter to contain? Protecting the air inside the field?

You say containment failure is inevitable, but if both are linked together and neither will go down without the other, you can't eject the pod you now will loose containment because it won't release until containment fails. Having the 2 linked is suicide. And you can't manually release the pod if you wanted because you've designed it, so that you don't have control of it.

What makes you think I haven't designed safety systems in the real world? The idea of a dead man/power switch for a starship proposed by Wong makes me think he doesn't really have an engineering degree.

[Wyrm]

I'll sum up everything because I lost it all and I don't feel like going back over point by point again.

In short, you weren't willing to slog through my arguments and at least try to understand them, even though I gave you that same courtesy?

Your systems sucks. It's suicidal. The antimatter containment field will only maintain itself for a few seconds before the first bit of antimatter escapes when the generator shuts off, destroying the pod.

With any antimatter pod, regardless of whether it uses active ejection or the DMS mechanism, the escape of antimatter causes the pod to explode. With any antimatter pod, regardless of type, the loss of sustaining power (regardless of where the this power comes from) will lead to escape of antimatter from the pod.

If my system sucks and is suicidal for this reason, then your system sucks and is suicidal for the very same reason.

Linking the containment field with the release is suicide because the pod won't just jump out of the ship without contacting anything.

Sure it can! If the antimatter pod door is held shut by the same electromagnet that retains the pod, it will pop open when the retaining magnet loses power, and when the pod ejects.

You claim you can get the pod away and get a safe distance, but you don't have the time when you link when the containment field fails with the release, even when you want to give yourself a few seconds. You'll be lucky if a few seconds is all it takes to get the pod outside the ship, even with a passive system.

Do you honestly believe the situation will be any different for the standard pods? Standard pods, when ejected with the active system, will also be disconnected from the containment field when ejected.

If my system sucks and is suicidal for this reason, then your system sucks and is suicidal for the very same reason.

Antimatter pods aren't sitting on the hull.

I know. I don't see why that would be important.

You have made statements in your last post, but have quoted your answers from my last post.

Yes. This is a problem because...?

I am the one that has had to remind you and Ted C that there are independent systems for the antimatter pods. Don't act like you said it first.

I know Ted C said it first. I did read the thread. I read the entire fucking thread before I said a word. It bore repeating, since you didn't seem to get it the last time around.

You propose that a glitch would cause every single safety as well as their corresponding back ups to fail, but the odds of that happening are astronomically impossible.

So what? The point was that a systemwide failure (and only a systemwide failure) would cause a systemwide ejection of the pods.

Don't give me any 'it might happen'. Yeah and Q will actually will himself into our reality, if someone made video of him doing it. 'It might happen'.

That wasn't the point. Local failure is more likely. That's why we have the ejection system in the first place, right? However, we get robust systemic failure handling for free. The antimatter pods response to failure automatically scales to that of the energency. I'm not about to throw it away.

You're so freaked out about moving a stable antimatter pod that survives even when Voyager crashed onto an ice planet when the amount it takes to kill someone is an infinitesimally smaller amount of energy than the total warhead yield equivilent any antimatter pod has. It's barely anything of an arc that could kill you and you're worried about moving a stble pod that survives when a ship crashes on an ice planet?

If it survives the crash of a starship, it can stand a controlled move. And what I have spoken of in my last post and the ones before it is the destruction of one antimatter pod inside the ship will probably destroy another. The raised and empty containment field in your design would only protect the air inside the field...maybe...and most likely not.

... Whaaat? In order to remove an antimatter pod, you have to disconnect it from all the multipily redundant power systems that sustain the containment fields, as well as removing it from it's safety system! That makes the pod far more dangerous, because now containment power is coming in through a flexible cord. (DON'T TRIP OVER IT!) Try ejecting a pod when the ejection system has nothing to push against.

If you empty the pod before you move it, you can skip all that nonsense and just get on with moving the pod. It's much less risk, and furthermore, it's a risk you are in full control of (unlike an uncontrolled landing).

If you're really hurting for pods, transfer the pods dry and install them dry, and after checking that everything's ship-shape, THEN fill them!

Your design increases cost and decreases benefits at the same time by linking the relsease with the containment failure and increases the centralization of the ship.

What cost have I added above the standard active eject system? What benefit have I eliminated from the standard active system in my design? How is having each pod responsible for it's own ejection increasing centralization?

WELL?

You decrease the opportunity of the redundency systems to work because it will explode inside the ship because the release and the field collapse are linked.

If you had read my original post you would have noticed that I have not taken away ANY redundancy that was part of the standard system. All I've eliminated are the failure modes of the standard system where control links to the antimatter ejection systems were severed (Disaster), and the system goes wonky (Contagion). Unlike your hypotheticals, these are known problems with the Galaxy class antimatter safety systems!

What the fuck is the point of keeping a contaiment field up when there's no antimatter to contain? Protecting the air inside the field?

It's the price of a robust system. I never said this system came without cost. But if the Federation starships can afford to run antimatter containment off batteries but not the regular lights, it's obviously not a very big cost. I have therefore added substatial benefits to the system with little cost.

You say containment failure is inevitable, but if both are linked together and neither will go down without the other, you can't eject the pod you now will loose containment because it won't release until containment fails.

Jesus H. Christ! Engage your brain! To eject a pod manually, all you have to do is cut the power to that pod. You don't even have to cut ALL the power to the pod, just enough of the power so that the retainer magnet cuts out but the containment field is still fine, but then the pod ejects and the pod loses containment power anyway.

If you're really squeemish, you can put a small squib on the retainer magnet's tributary of the pod's power feed, causing an ejection. But then the pod loses containment power anyway.

Having the 2 linked is suicide.

You have yet to explain why.

And you can't manually release the pod if you wanted because you've designed it, so that you don't have control of it.

I've already dealt with that bullshit.

What makes you think I haven't designed safety systems in the real world? The idea of a dead man/power switch for a starship proposed by Wong makes me think he doesn't really have an engineering degree.

Because dead man switches are used in real systems. The CANDU system, used in real fission power reactors, is a dead man's switch. The safety kickback break of a chainsaw is a dead man's switch. The power switches on power tools are dead man switches (if you release 'em, like you've just dropped dead, the power tool shuts off). DEAD MAN SWITCHES ARE EVERYWHERE!! Why should Mr. Wong wanting to use this ubiquitous engineering principle in a starship mean that he doesn't have an engineering degree?

As for Mike Wong's qualifications, it's actaully trivially easy to verify if he's an accredited engineer: call the University of Waterloo and ask. Easy as pie!

[GStone]

In short, you weren't willing to slog through my arguments and at least try to understand them, even though I gave you that same courtesy?

No. In short, I lost it all. In long, I went point by point, then, I hit preview. I got the log in screen. I tried to go back, but got another log in screen. I went forward to the first log in screen, signed back in and everything I had written was gone. It might have been a problem with my laptop, I don't know. I spent a while typing all my points up, as I went point by point and when I found I lost it all, I decided to summarize what I had originally typed because I didn't feel like slogging through the whole thing again.

With any antimatter pod, regardless of whether it uses active ejection or the DMS mechanism, the escape of antimatter causes the pod to explode. With any antimatter pod, regardless of type, the loss of sustaining power (regardless of where the this power comes from) will lead to escape of antimatter from the pod.

And your system doesn't give the crew enough time to get the pod out because of linking when it is released and having no manual control over when it's released. I said this.

If my system sucks and is suicidal for this reason, then your system sucks and is suicidal for the very same reason.

Horse shit. Yours sucks because you don't have any hope of manually controlling when the pod is ejected because your design cuts off that possibility. My design doesn't have that. Therefore, that statement is inherently wrong.

Sure it can! If the antimatter pod door is held shut by the same electromagnet that retains the pod, it will pop open when the retaining magnet loses power, and when the pod ejects.

Your design has the added feature of phasing the antimatter pod through solid matter. You never said and that is what I was talking about. You weren't.

Do you honestly believe the situation will be any different for the standard pods? Standard pods, when ejected with the active system, will also be disconnected from the containment field when ejected.

They have an independent containment system. You could eject every one of those little fuckers with hours left before the fuel runs out of the generators. Your design won't let you.

If my system sucks and is suicidal for this reason, then your system sucks and is suicidal for the very same reason.

Again, my design doesn't have the problems I have listed many times that yours has.

I know. I don't see why that would be important.

Oh, lord. You'd need them sitting on the external hull to have your system be of any use. They'd have to be like the pods on the outside of a mon calamari cruiser. That'd be the only way, but it'd still suck even then.

Yes. This is a problem because...?

Because you are wasting time. There's the answer to your question, you know it's there. Instead of asking for an answer you already see in front of you, ask one or make a statement based on what's already there. That is the adult thing to do.

I know Ted C said it first. I did read the thread. I read the entire fucking thread before I said a word. It bore repeating, since you didn't seem to get it the last time around.

I'm the one that said the presence of the independence was already there. I'm the one that brought up The Last Outpost. He's the one that suggested they diverted power from life support to keep the pods from exploding, which I then said would have cost them a lot less energy, if they ejected the pod, let it blow up and then, kept life support up, so they wouldn't freeze to death. Now...tell me I didn't say that.

So what? The point was that a systemwide failure (and only a systemwide failure) would cause a systemwide ejection of the pods.

The 'so what' is that it's impossible. With so many back up and back ups for the back ups, there's no way every single fucking one is gonna fail. There is only one instance off the top of my head with that kind of problem and it wasn't caused by a damn glitch. It was Cause and Effect and the distortion caused the ship to loose all it's power within a couple minutes (which would include antimatter containment power- main power was done and what they had left was being lost really fast), then a nacelle gets damaged and the ship blows.

Show me an instance where a glitch caused that to happen and don't use Contagion because that wasn't a glitch. That was an alien computer virus from a more advance civilization.

That wasn't the point. Local failure is more likely. That's why we have the ejection system in the first place, right? However, we get robust systemic failure handling for free. The antimatter pods response to failure automatically scales to that of the energency. I'm not about to throw it away.

And if you needed to move it to make repairs for whatever reason, you can't with your design. You've made it impossible to do so. There are already many back ups and warnings that let the crew know with enough time.

... Whaaat? In order to remove an antimatter pod, you have to disconnect it from all the multipily redundant power systems that sustain the containment fields, as well as removing it from it's safety system!

Not when each pod has its own containment system. Your design, as you've said, makes each one hooked up to the power grid the rest of the systems of the ship draw power from. Mine doesn't, which is another detail you keep deliberately overlooking. Pay attention. You couldn't even disconnect it with your system because the computer is keeping you from doing that with your design.

That makes the pod far more dangerous, because now containment power is coming in through a flexible cord. (DON'T TRIP OVER IT!) Try ejecting a pod when the ejection system has nothing to push against.

That's because you've done something not smart and didn't give each pod its own system, which you have admitted to. My design does have independent systems that can be hooked together, like multiple computers on a network. Each one doesn't run off the same power supply.

If you empty the pod before you move it, you can skip all that nonsense and just get on with moving the pod. It's much less risk, and furthermore, it's a risk you are in full control of (unlike an uncontrolled landing).

Youo don't have to drain everything, especially when you have antimatter pods that can survive when the ship takes a nose dive into an ice planet. The antimatter pods are not the Hindenberg.

If you're really hurting for pods, transfer the pods dry and install them dry, and after checking that everything's ship-shape, THEN fill them!

The thing has a self-containing system. And just where are you proposing they shunt all the extra antimatter till they get an empty pod out of the rescuing ship and into the rescued one, huh? The holodeck? In the transporter's pattern buffer?

In your system, you couldn't even do that because the lock is tied to the containment field. With nowhere to put the antimatter, you can't create the condition of the pod decreasing the field naturally, as it would when it runs out of fuel.

What cost have I added above the standard active eject system?

The cost of not being able to eject the pod when you want to.

What benefit have I eliminated from the standard active system in my design?

The benefit of being able to remove the pod manually when the situation demands it, the greater chance of surviving the containment failure of a pod, etc. All the shit I have talked about and then some.

How is having each pod responsible for it's own ejection increasing centralization?

You have made a computer link between the locking mechanism and the containment field. You and Ted C have designed the pods to draw its power supply from the main power grid and saying the independence comes in back ups.

If you had read my original post you would have noticed that I have not taken away ANY redundancy that was part of the standard system.

You've screwed with the redundency by doing things, such as linking the containment field with the locking mechanism.

Unlike your hypotheticals, these are known problems with the Galaxy class antimatter safety systems!

Like your attempts to spin, these statements are not true. They are not problems that are inherent to the safety system. That's a bold face lie. They are unique circumstances. As far as Disaster, there was a problem with power overall. What they needed was access to a terminal to prevent containment loss. In a normal circumstance, they would have been alerted to the problem and fixed it after one of the back ups kicked up, if it had to get that far at all.

But, go ahead. Tell how your design would have been able to have survived when the Enterprise was hit by the quantum filament. Tell how even the hatch door that opens to let the pod out would have continued to work with your design. I want to know how.

As for Contagion, that was an alien computer virus from an advanced civilization. Tell me how the hell your design would have protected that. Tell me of the design of a computer that gets so advanced that even more advanced civilzations with more advanced computer tech than this computer couldn't be able to defeat this computer of a less advanced civilization. I want to know what it is.

It's the price of a robust system. I never said this system came without cost.

Here's another cost to add to the list of bad things your design does.

I have therefore added substatial benefits to the system with little cost.

What you have done is pointless and overcomplicating things. What you have suggested is the equivilent of adding a second door knob on the side of the door the hinges are fastened into. It's utterly, completely pointless.

Your insistance on it being robust, as an excuse to have it is ridiculous. Not everything needs to operate under all conditions. In fact, that's what you're trying to do with arguing for this design, but it isn't working.

It does jack squat. You have overcomplicated things. Overcomplicating is a hallmark of inferior engineering designs.

You don't even have to cut ALL the power to the pod, just enough of the power so that the retainer magnet cuts out but the containment field is still fine, but then the pod ejects and the pod loses containment power anyway.

First, containment retention is based upon the locking mechanism, which you both have said. You can't have one without the other. Second, if you don't have to destroy your power source, why the fuck would you do something so stupid, as destroy the pod? That is what you have to do each and every time you release a pod. You'd be lucky if you could get the damn thing out because, if the batteries kick in to maintain field containment, the locking mechanism kicks back in and the pod stays put.

You have yet to explain why.

See all the times when I said you can't get the pod out fast enough to just the edge of the hull before it blows up, destroying your ship.

I've already dealt with that reasonable.

Nope. Batteries kick in in your design, locking mechanism reattaches. You can't have one without the other, remember?

Because dead man switches are used in real systems.

Show me a real life example of a matter/antimatter power generation system that's based in space, not in the atmo of a planet and on the fucking ground.

The CANDU system, used in real fission power reactors, is a dead man's switch. The safety kickback break of a chainsaw is a dead man's switch. The power switches on power tools are dead man switches (if you release 'em, like you've just dropped dead, the power tool shuts off). DEAD MAN SWITCHES ARE EVERYWHERE!!

Which has jack shit to do with a matter/antimatter system onboard an object in space. Different environmental factors, different equipment, etc. etc.

Why should Mr. Wong wanting to use this ubiquitous engineering principle in a starship mean that he doesn't have an engineering degree?

Show me a real life power generator that uses matter/antimatter collision for fuel that's in an object in fucking outer space and I'll show you where having a dead power/man switch in the generator is a space born Hindenberg.

As for Mike Wong's qualifications, it's actaully trivially easy to verify if he's an accredited engineer: call the University of Waterloo and ask. Easy as pie!

I don't have to to get an idea of how much he learned, if he really went. The stuff he posts on the web speaks for itself.