## Discrepancy Between Circuit Simulation and Reality

29 09 2011

Previously we modeled the polywell coils and power supply in SPICE.

Today I returned to that model.

All resistance values in the simulation are based on real world measurements with the exception of coil inductance (code).

Starting with an estimate for coil inductance of 0.1 mH the discharge current looks like this:

The simulation’s peak of 1.5 kA is nowhere near the 2.3 kA we are getting in the real world:

OK. Maybe the value for coil inductance is off?

I played around with the value for coil inductance but the simulation would not match reality.

As a control I replaced the simulated inductor with a 1 mΩ resistor (code). Looks like this:

The simulation predicts ~1.8 kA but in reality we see 2.3kA!

Where does this discrepancy come from?

UPDATE: Reader Andrew solved the mystery:

You could try changing the ON resistance of your switch/SCR to something a bit lower than 100mOhms

.model MySwitch SW(Ron=.1 Roff=1Meg Vt=3 Vh=0)

I can’t see the part number of your SCR but 2mOhms would seem reasonable.

I didn’t notice that rather high resistance lurking in the SCR model.

Now the simulation matches reality very closely with 0.06mH coil inductance (code):

Good work Andrew and the rest of the internet brain!

## Wiring Diagram

22 02 2009

So I’m working on an algorithm to come up with a wiring diagram for the dodecahedral core. It’s more complicated than just wiring up the 12 coils in series. This is would only magnetically protect 12 of the 30 connecting joints. Ideally each join would get one pass of superconducting cable. A picture to meditate on:

Lets start by making some methods to traverse the net. Currently I have this functionality:

Geometry::Dodecahedron.faces.first

=> [Vector[1, 1, 1], Vector[1, 1, -1], Vector[0.618033988749895, 1.61803398874989, 0], Vector[1.61803398874989, 0, 0.618033988749895], Vector[1.61803398874989, 0, -0.618033988749895]]

So I can easily iterate through the the faces, and I get the vertices of that face unordered. The first challenge is to order these collections of vertices so that you traverse the face clockwise simply by iterating the collection.

## Bloom Filter

30 12 2008

File this under tools I bet I’ll need:

Bloom Filter in Ruby

Excerpt:

A Bloom Filter is a probabilistic data structure that is used to test whether an element is a member of a set, or more simply, it’s an incredibly space efficient hash table that is often used as a first line of defense in high performance caches.

## New Calculations

23 11 2008

Based on the new coil winding calculations, I am going to slim down the coils to hit a target of ~200 wraps. Now the coils appear to be proportioned like the coils on the WB6. Here is what the adjustment looks like:

• coil_length: 116,309.299858263 mm
• wraps: 225
• torus_tube_wall_thickness: 4.998 mm

Next we will calculate Forces_between_two_magnetic_dipoles, and Power_dissipation of the coils in the form of heat. This will give us some idea of the tensile strength and temperature envelope of the device.

## Coil Winder

16 11 2008

I’m working on a computer controlled coil winder. I’ve started by using the midpoint circle algorithm to rasterize a circle. Each digit represents a wrap of 22 gauge wire inside a torus with a cross section about the size of a US quarter:

Here is an updated version. The wire is a more realistic 12 gauge. I knocked out the corners, so it’s true only where the coil should be. Now it’s much easier to iterate over. This coil would have 421 turns. With some additional code, I can now calculate the actual length of wire necessary for the coil, and in this case it comes out to ~200 meters! With this new information, I will have to adjust the model. I want to shoot for the same wire gauge and number of wraps as WB6.

Here we have the design for the bobbins. They split down the middle so you can remove the finished coil: