Airship Sails Addendum

A recent comment gave me reason to read back over my post on using sails on an airship and realize I didn't include any pictures of how the vectors I was talking about were oriented.  In that post I was so much more concerned with finishing and organizing my own thoughts I didn't do a very good job of expressing what I was talking about at all.

This picture shows the two most important vectors when talking about either a triangular sail or a wing.  Blue here represents the prevailing wind, or possibly the current direction of motion for the vehicle.  Green represents the lift, or the direction that the sail causes the vehicle to move in.  Wings convert forward motion into an upward force, while sails convert wind into a forward force.
On a ship the collected forces cause a net motion as shown below:

Here the wind exerts a net pressure (in orange) on the hull which pushes the vehicle in that direction.  This force should be fairly weak, but on an airship can't be compensated for by the keel as on a waterborne sailing ship.  Between the lift and pressure forces a net force creates some velocity (in yellow) which in turn creates a drag force (in red) on the ship.  This is what I calculated in the previous post, merely to demonstrate that such a vehicle could indeed generate a meaningful velocity.

There is a concern in this image that I didn't raise in the previous post.  What happens when the breeze is coming from the fore, rather than the aft, of the ship?  So long as the sail can be angled properly and the wind is coming from at least a little behind, or even directly to the side, of the desired direction then this image is roughly accurate.  When it comes from ahead, though, that pressure force that normally would be compensated for by the keel becomes a serious problem:

Here the pressure and lift create a net velocity not ahead, but to the side.  Obviously a sufficiently well sized sail and a properly sleek ship can somewhat mitigate this issue, but never eliminate it.  By beating to windward, however, this problem is significantly reduced.  Doing so causes the pressure and drag forces to be almost in line, meaning velocity is reduced but the direction is controlled:

This is a pretty complex maneuver used in real sailing, one that I can't possibly do justice to here. In short, it involved keeping the desired momentum more or less opposite the direction of the prevailing wind.  The ship constantly moves back and forth about that vector, so the wind is always coming slightly to either side.  In this case so long as the forward component of Lift is greater than the backwards components of Drag and Pressure then the ship will continue moving forwards.  Since the sideways components of the two orientations are opposite each other they cancel out over time and the drift is minimal.  Unfortunately the effect of pressure here will make this a much less effective maneuver than it is for a ship at sea, but it ensures the ship can maintain forward velocity regardless of the direction of wind.

I haven't bothered here with the particulars of design or calculation, the majority of which was done in the first post.  While the new issues raised here would impact any real attempt to construct such a vehicle we've also seen that such issues could be overcome by a sufficiently dedicated designer.  There is a combination of hull and sail design that would make this work.  That is enough for now, unless we want to start really building one.

Dungeons and Dimensions: Generating a Dungeon as a Network

In Part One of this series I introduced the basics of network science and how it might be applied to dungeon design.  In Part Two I went over some of the basics of analyzing a network, and what those terms might mean when applied to a dungeon.  In this third entry I'll talk about what all this buildup has been for: producing a new dungeon and describing it from scratch.  Actually, I'll be producing it from a collection of functions and subroutines designed for this express purpose.  Basically the same thing, right?

Before I go too deeply into this topic, though, I'd like to answer the most obvious question here: is this Procedural Dungeon Generation?  Well, it is a procedure that generates a dungeon, so by the most obvious definition it is.  But, is it really?

No, not really.  Most procedural content generation (PCG) systems actually produce a completed map, and I've been very explicit that that is not what I'm doing.  Not yet, anyway.  The most common PCG methods for dungeons are built around removing walls from a solid grid, placing rooms, generating mazes, and then populating the completed building with encounters.  This network based method is more about determining which encounters lead to which other encounters, then drawing a dungeon around that.

You can find a great write-up on a procedural dungeon generation method here, by the way.  There's a clear contrast between this kind of procedure with those of the network based procedure I'm employing in terms of both their method and their goal.

Dungeons and Dimensions: Finding the Center

In the last entry I posted, titled Dungeons and Dimensions, I introduced the idea of graph theory and network science and how they might be applied to the classic dungeon crawl.  Hopefully I've explained the what and how effectively in that article, but have I really addressed why?  In that article I said that, given any dungeon, I could find the number of rooms you must pass through to get from any one room to any other room in that dungeon.  But it seems like a lot of work to go through just to get that.  Is there any more that we can learn?  Is there anything else we can do with this idea?

The answer is obviously yes and those are rhetorical questions.  Otherwise this would be a very short post.  Still, we have to introduce a little more theory and a few more new ideas before we get there.  In the last post we were looking at the whole network but in this post we'll find information about individual nodes.  We'll start talking about individual nodes and what properties the network as a whole gives them.

Dungeons and Dimensions: Network Theory Applied to Gaming

Quick confession, when I learn about some new concept my first thought isn't always about how it can be applied to space travel.  That is what I think of when I learn new things about science or engineering, but when the subject is mathematics or programming my first thought is usually, "how can I use this in gaming?"  Specifically, tabletop gaming like Dungeons and Dragons.
So when I started learning more about network science the very first thing I thought to do was see how I could use it in D&D.  So I started looking at the abstract definitions of a network, nodes, and links as a dungeon with rooms and doors.  Then I started trying to see where I could go with it.
Of course, there's some basics to get out of the way first.  Like what is a network?

Saha Equation and Simultaneous Equilibrium Dissociation-Ionization Reactions

Abstract

Reaction coordinates derived from the Saha equation and stoichiometry are used to describe the dissociation of diatomic molecules and the ionization of dissociation products. This results in a system of 2 coupled nonlinear equations. In previous literature [1] this was resolved by assuming two different, independent regimes, which works provided that dissociation energy and ionization energy are sufficiently different. For substances like nitrogen, however, these two values are close and this assumption may not be valid. For this reason we solve the system numerically and use this result to test the two regime assumption.