Archive for March, 2006

Maybe a little work on Renewable Energy Design…

2006-03-28

Idea for organization of R.E.D. wikia (renewableenergy.wikicities.com now renamed renewableenergy.wikia.com)

  • Problem pages should focus on a particular problem stated at the top and worked out on the page.
  • Need list of problem pages for the project. Use categories for this. Each project has a category. Problem pages belong to project category for each project they are relevant to.

Recent thoughts about the machine itself:

  • Need to keep stresses localized. Huge objects just aren't rigid. The forces which make each part of rotor turn have to arise within that part.
  • The gas is localized at top of the cylinder. As cylinder turns, there shouldn't be much stress on cylinder walls which are surrounded by water. There has to be extra mass above the gas to counteract the extra buoyancy.
    • This ballast needs to stay at top. Friction? How to keep it there?
    • Or maybe ballast is on the axis. Stretching forces appear on connection from axis to outer walls when they are at top. Very little force present between ballast and outer walls when they are not at top.
  • The walls need to be cheap. Gas-tight, but cheap. Maybe some fabric or flexible plastic, with ribs to keep the cylindrical shape. Or the shape follows from the tension (stretching) forces due to gas at top and ballast at center connected by ropes (and fabric for the screw part).
  • Might need buoyancy spheres. (Thought of filling the space with them and letting gas move through the gaps between spheres. Outer walls hold them in place. Probably a dumb idea.) May not have a buoyancy problem if the walls are light and there is a big volume of gas.
  • May need hot water moving downward as hot gas moves upward, and cold water moving upward as cold gas moves downward. Screw would help move water but lack of gas phase makes it more like a turbine than a positive displacement screw. (i.e. blades push on the water, but it can go around them).
  • Alternative is the heat is carried by a refrigerant through heat pipes. (Refrigerant gas carries heat to low pressure area, up or down. Condensed liquid flows down. Heat rises in a gravity feed heat pipe.) Trouble is, the source of heat is at top of ocean and the cold is at bottom. So, need a pump (e.g., a screw since we already have rotation going on) to lift the condensed refrigerant up to place where it can absorb heat and evaporate. Evaporated refrigerant will go wherever the pressure is lower, caused by condensation on a cold surface). But this requires fairly large volume low pressure container deep undersea. The external pressure would tend to crush the heat pipes. So they have to be small bore, but then refrigerant can't move fast enough.

The above was all early last week. More recently, I've been thinking of a cylindrical machine made of flexible gas-tight fabric which rotates about a rigid heavy metal axis. The top end is held above water by an inflated collar, while the bottom end is held at a fixed depth by an anchor cable running from float on surface to lower end of machine to a sufficiently heavy anchor some distance below the machine. The whole machine is sealed except at top. Hot surface water is raised to the entrance by a screw as machine rotates. It flows through the hot helix, maintaining temperature of hot expanding gas, and heating cold compressed gas in counter-current heat exchanger at bottom. At end of heat exchanger, the water is nearly cold, and it feeds into a large storage compartment at very bottom where remaining heat is rejected to cold ocean bottom. This compartment is under pressure because of the continuous addition of hot water at top, with excess pressure over ambient equal to the height of entry port above sea level. Output of cooling compartment is cold water which proceeds upward through the cold helix, removing heat from cold gas as it is compressed. At top, the cold water is used to cool low pressure hot air. The resulting warm water is released into open ocean some distance below the surface.

Air also enters the machine at top, to replace the air which was removed as high pressure cold air into storage compartment at bottom. The rate of rotation is controlled by diverting high pressure cold air into storage at bottom, replacing water which is released into the ocean. The hot air (recycled and newly captured) is first cooled in a liquid-gas counter-current heat exchanger at the top of the machine, rejecting heat into the cold water which came up through the cold helix and which is then released at intermediate depth. The resulting low-pressure cold air proceeds into the cold helix (indeed, there is little difference between the cold helix and the counter-current heat exchanger). As the machine turns, pockets of cold air are pulled downward through the cold helix, as cold water rises on its way out.

Buoyancy of the machine must be adjusted to avoid undue stress. The central axis is made of strong and heavy metal, but it is not strong enough to avoid bending if the helices are unevenly filled with air. Each segment serves as ballast to balance the buoyancy of the air in the hot and cold helices directly above. If there is less air in a helix segment, then some compressed air is admitted to the ballast chamber in the central axis segment, displacing some water at the appropriate position along the axis. If the helix is full of air, then the central axis segment should be full of water. If a given helix segment is full of water, then the corresponding central axis segment will be full of air.

Second Life

2006-03-22

Archimerged now has a free account named “Archimedes Underall” in the Second Life virtual community.  First attempt to use the Linux port failed due to lack of GLX library…  He hopes to find some interested helpers there.

Inkscape and SVG

2006-03-20

I used inkscape to create some simple scale geometric drawings with labels. I discovered that inkscape doesn’t support nested coordinate systems: I couldn’t create a coordinate system for the geometric drawing separate from the coordinates of the image itself. At least not explicitly. What I ended up doing was ignoring the drawing boundaries completely and laying out the image as needed. Then I grouped everything, copied it, and pasted into a new image which I then sized to fit around the drawing, and saved. Then I converted that to png using gimp.

I discovered that the best way to put points where you want them is to use guidelines. Finding out how to create guidelines is not easy. But creating them is. You drag from the ruler to the drawing, and a guideline appears. To place it at a precise location, use the XML edit window, where you can edit the property and store the exact location.

In file/document preferences, you can select “snap to guides” and points and line endpoints stay where you want them.

I also discovered quite by accident that the xml file includes the full path name of where inkscape saved the file. Not good. An information leak if you didn’t intend to publish your username on the system where you edited the file.

See the post on krazyletter.  Well, maybe I’ll get back to working on the heat engine P vs. V, T vs. S diagram, in SVG…

M4 enigma project

2006-03-12

Still sidetracked, I’ve been looking at the M4 distributed computing project…

Here is a post to their mailing list:

From: “Archimedes Submerged”
To: m4-breakers@bytereef.org
Date: Fri, 10 Mar 2006 17:58:16 -0500
Subject: Redundant hill climbing being done
The workunits I have seen specify start and end keys with the same wheel positions and ring settings. They start with message key BAAA and end with ZZZZ. (Why not AAAA?)

The middle (second from right) wheel’s ring position is allowed to be B to Z (or B to M for wheels 6,7,8). The A position was already tried in an earlier run. Note that the server specifies the middle and right ring positions in the workunit, and the client leaves them constant. (The greek and left ring positions are always AA because there is no difference between changing the ring position and changing the message key for those, since the greek wheel never turns during encryption.)

Now, the ring position on the middle wheel has two effects. It controlls the turnover point, where the left (third from right) wheel is incremented, and it changes the labeling of the message key vs. the actual wheel position. When the starting position (message key) of the middle wheel is such that the left wheel never turns during encryption, then there is no difference between changing the middle ring and changing the middle letter of the message key.

I don’t know what order workunits are being handed out in, but certain groups of workunits include nearly duplicated effort. This occurs whenever two different workunits end up specifying identical path_lookup arrays. (The path_lookup array is constant during a hill climb. It specifies for each letter of ciphertext the permutation performed by the wheels and reflector, accounting for the turning of the wheels after each letter). Fortunately the var arrays (drawn at random) will be different, so the work is not exactly identical. (The var array specifies the order stecker changes should be tried during the hill climb). But it would be better to try all different path_lookup arrays before repeating the same ones. And it would be better to avoid trying certain path_lookup values more often than others.

When does the same path_lookup array arise in different workunits? When the workunits have the same wheel order, the same right ring setting, and similar middle ring settings, and when the turnover point of the middle wheel is not reached before the end of the ciphertext.

Note that when the middle wheel does reach the turnover point (where the left wheel turns), then if the middle wheel message keys differ by n, then n path_lookup array elements (permutations) will differ, i.e., keys B and C would give 1 permutation different, B and D 2 differences, etc. (Different permutations often give different plaintext, but for a given ciphertext, two different permutations at a given position can give the same plaintext. So just comparing plaintext letters — one value — is not the same as comparing the whole path_lookup array element — 26 values).

How could we avoid unintended repetition of the same path_lookup? There are 26 middle ring settings (13 for wheels 6,7,8), and 26 middle wheel message key letters. For each middle wheel starting position, there are 26 pairs (13 for wheels 6,7,8) of ring and message key letters which give the same wheel position but different left ring turnover points. Those pairs with the same wheel position but where the left ring turnover point comes after the end of the ciphertext are all equivalent and should only be hillclimbed once per run.

A workunit includes keys BAAA to ZZZZ, and a specified middle ring setting. There are 26 related workunits, with the same ukw, wheel order, and right ring setting, but a different middle ring setting (13 for wheels 6,7,8). The current ciphertext is 197 characters, 7 to 8 turns of the right wheel. So 18 or 19 different pairs of middle ring setting and middle ring message key letter give the same path_lookup array, out of 26. (Or 5 or 6 different pairs out of 13, for workunits with middle wheel 6,7,8). Only one workunit out of 18 or 19 should do this work. The other 17 or 18 should skip it. But we want to keep the workunits about the same amount of work.

In init_path_lookup_ALL(), if the left wheel turned, then the hillclimb should proceed. Otherwise, we need a reliable way to pick exactly one of the workunits to do the hillclimb. Well, exactly one of them comes within one step of turning the left wheel. So the decision is made in init_path_lookup_ALL(): if the left wheel turned, or if the left wheel would have turned on the next turn of the middle wheel, then the hillclimb proceeds. Otherwise the hillclimb is skipped. This distributes the work among all of the workunits in a uniform manner, because it is the message key letter, not the ring position, which determines if the left wheel turns or would have turned.

From: “Archimedes Submerged”
To: m4-breakers
Date: Fri, 10 Mar 2006 19:24:39 -0500
Subject: re: Redundant hill climbing being done
diff -ur enigma-suite-0.73.1-orig/cipher.c enigma-suite-0.73.1/cipher.c
— enigma-suite-0.73.1-orig/cipher.c 2006-01-18 11:06:35.000000000 -0500
+++ enigma-suite-0.73.1/cipher.c 2006-03-10 19:11:07.000000000 -0500
@@ -144,8 +144,11 @@

/* initialize lookup table for paths through scramblers, models H, M3 */
-void init_path_lookup_H_M3(const Key *key, int len)
+/* returns true if this hillclimb was or will be done on another
+ message key setting */
+int init_path_lookup_H_M3(const Key *key, int len)
{
+ int skip_hillclimb = 1;
int i, k;
int c;

@@ -191,6 +194,7 @@
if (m_offset == m_turn || m_offset == m_turn2) {
p3 = 1;
p2 = 1;
+ skip_hillclimb = 0; /* this path_lookup array is unique */
}

r_offset++;
@@ -219,13 +223,19 @@
path_lookup[i][k] = c;
}
}

+ if (m_offset+1 == m_turn || m_offset+1 == m_turn2) {
+ skip_hillclimb = 0; /* this m_mesg is the one which climbs this hill */
+ }
+ return skip_hillclimb;
}

/* initialize lookup table for paths through scramblers, all models */
-void init_path_lookup_ALL(const Key *key, int len)
+/* returns true if this hillclimb was or will be done on another
+ message key setting */
+int init_path_lookup_ALL(const Key *key, int len)
{
+ int skip_hillclimb = 1;
int i, k;
int c;

@@ -274,6 +284,7 @@
if (m_offset == m_turn || m_offset == m_turn2) {
p3 = 1;
p2 = 1;
+ skip_hillclimb = 0; /* this path_lookup array is unique */
}

r_offset++;
@@ -304,7 +315,10 @@
path_lookup[i][k] = c;
}
}

+ if (m_offset+1 == m_turn || m_offset+1 == m_turn2) {
+ skip_hillclimb = 0; /* this m_mesg is the one which climbs this hill */
+ }
+ return skip_hillclimb;
}

diff -ur enigma-suite-0.73.1-orig/cipher.h enigma-suite-0.73.1/cipher.h
— enigma-suite-0.73.1-orig/cipher.h 2006-01-18 11:06:35.000000000 -0500
+++ enigma-suite-0.73.1/cipher.h 2006-03-10 19:07:13.000000000 -0500
@@ -4,8 +4,8 @@
#include “stdio.h”
#include “key.h”

-void init_path_lookup_H_M3(const Key *key, int len);
-void init_path_lookup_ALL(const Key *key, int len);
+int init_path_lookup_H_M3(const Key *key, int len);
+int init_path_lookup_ALL(const Key *key, int len);
double dgetic_ALL(const Key *key, const int *ciphertext, int len);
void en_deciph_stdin_ALL(FILE *file, const Key *key);

diff -ur enigma-suite-0.73.1-orig/hillclimb.c enigma-suite-0.73.1/hillclimb.c
— enigma-suite-0.73.1-orig/hillclimb.c 2006-01-18 11:06:35.000000000 -0500
+++ enigma-suite-0.73.1/hillclimb.c 2006-03-10 19:15:15.000000000 -0500
@@ -152,15 +152,19 @@
/* initialize path_lookup */
switch (m) {
case H: case M3:
– init_path_lookup_H_M3(&ckey, len);
+ action = init_path_lookup_H_M3(&ckey, len);
break;
case M4:
– init_path_lookup_ALL(&ckey, len);
+ action = init_path_lookup_ALL(&ckey, len);
break;
default:
+ action = 0;
break;
}

+ /* init_path_lookup…() returns true if this hillclimb
+ was or will be done on another message key
+ setting */
+ if (action) continue;

/* ic score */
bestic = icscore(ckey.stbrett, ciphertext, len);

25mm cubes of perfect diamond by 2008.

2006-03-04

After reading comments on digg.com, I followed a link to the Wired story from Sept. 2003. It is quite extensive and covers both the Gemesis high pressure high temperature solid solution method, and the Apollo Chemical vapor deposition method. Apparently the only news is that the Apollo patent issued in June 2005 (actually Feb 2005, see also the June 2003 patent), and that the size of the seed diamond wafers have increased from 10 mm, and are expected to yield 25 mm cubes by late 2007.

read more | digg story