Saturday, March 30, 2013

The problem of radius

While I have data that I can set up in a simple table for Main Sequence stars, I do not have similar data for non-main-sequence.  Fortunately, much of our data has color index values.  That means I can use the formulas on  this site to compute radius directly.

Friday, March 29, 2013


In addition to the 7176 stars massed in the first pass, I looked at a few samples where the spectral type is present and the class is absent, and decided that, based on absolute magnitude, they are close enough to main sequence.  Running with that massed 9054 stars, leaving 8408 cases.  The next most common well-formed cases are class III.  Using the same sort of interpolation table will let me deal with almost 1000 more cases.

Lets look at mass

First, I have applied a simple filter to the data, I have drastically reduced the bulk of the HYG dataset; by restricting myself to a 100 parsec radius from sol I get down to 24,638 objects.  This is convenient since, among other things, it lets me load data into a spreadsheet to play with various formulas.

Now I can work through the first set of mass and luminosity calculations. The data has 7176 well-formed solitary spectral entries for class V (main sequence) starts.  I will use a table from Gillet's World Building to interpolate the mass and luminosity.  There are more sophisticated techniques I could apply based on bolometric correction and relationships between main sequence stars, but in terms of fitness for use this should be good enough.  If I get better mass data (say from exosolar planet search) I will backfit it.

Tuesday, March 26, 2013

Reminder to self

Update the file splitter to exclude (with a rejects file) stars with bad data per this post.

For my next trick...

The file splitter program now works. The next two steps will be
  • An analysis program to take one of the "rejects" file and work out what spectral types are most common.  This should help drive "bang for buck" planning on what to process next.
  • Many entries, I already know, are very clean spectral-type/number/class with no qualifiers.  I will start with those as the first to process.  In order to break up conversion of spectral data into mass and luminosity, I will start with a single class (probably class V since that's "us").

Sunday, March 24, 2013

Off to a start

I am making progress on splitting the data file.  I am using opencsv for my very lightweight file handling needs, and the latest eclipse as a platform.  Very utilitarian Java; so far I have produced a name file with 234,512 distinct names - most stars, o course, having multiple entries.

Friday, March 22, 2013

A file processing approach

You can tell I am old by the fact I am going to do the initial processing by files.  Remember, though, the objective is to produce a set of files that can be loaded into a relational database.

The first step (phase 0) will be to split the full Hyg2.0 file to extract the name information and location information for loading.  This will let us concentrate on a file of core fields that will describe the spectral information from which mass and luminosity will be derived along with simplified spectral types.

After that, the core fields file will be processed in a series of steps each of which will solve one processing problem and generate an output file with the stars solved in that step.  Stars that cannot be solved will be output to an ever-decreasing rejects file which will be input for the next phase.

Once no rejects are left, all the phase outputs will be loaded into the database.

Monday, March 18, 2013

More about fuel

Lets take the table from the last post, and work with the Tsiolkovsky equation to get some concrete numbers.  First we have to nail a couple of data points down.
  • Engine - we will assume an exaust velocity of 500,000 m/s.  This is very hot, but not entirely insane.
  • Mass -  We will assume we are delivering something of the mass of a Kirov battle-cruiser.  That's 28,000 tons, or near as matters 3x10^7 Kg.
So with using the table from the last post, and having confidence in our high school algebra:

Acceleration, G Days Fuel Mass, Tonnes Mass Ratio
2.00E+00 6.40E+00 7.65E+13 2.55E+09
1.50E+00 7.38E+00 4.20E+12 1.40E+08
1.00E+00 9.04E+00 1.34E+11 4.48E+06
1.00E-01 2.86E+01 3.78E+06 1.27E+02
1.00E-02 9.04E+01 1.09E+05 4.63E+00
1.00E-03 2.86E+02 1.87E+04 1.62E+00
1.00E-04 9.04E+02 4.97E+03 1.17E+00
1.00E-05 2.86E+03 1.49E+03 1.05E+00

Of course,what this really underscores is the un-realism of SF in which large warships plunge through solar systems at multi-G accelerations for days on end.I am not sure I know how important this is to me, though.

Sunday, March 17, 2013

Continuous Acceleration, Time and Fuel

This table sets aside looking at the mass of fuel directly, and just looking at how long it takes to go 10 AUs at various accelerations, the following table is just the Brachistochrone equation.

Distance, AU Acceleration, G Hours Days Delta-V, G-Hours
10 2.0E+00 153.484 6.39515 306.967333
10 1.5E+00 177.228 7.38449 265.8415085
10 1.0E+00 217.059 9.04411 217.0586827
10 1.0E-01 686.4 28.6 68.63998234
10 1.0E-02 2170.59 90.4411 21.70586827

Saturday, March 16, 2013

Systems and the "Hyg" database

There are two sorts of analysis it occurs to me that I have not done yet with these data.
  1. I have not attempted to group the individual records into "systems".  I can tell from the spectral data that many "star" entries are close multiples, but I have not looked to see how many have even identical X/Y/Z coordinates let along those indicating close grouping.  In terms of data reduction I think that is my first step.
  2. I have not looked how I will want to look at the reduced data when I am done, and to wold-build and record non-generated information on to of that.  No knowing a good chunk of  the endpoint is premature and I need to address it.

Thursday, March 7, 2013

Better processing software

Data reduction is what bogged me down last time.  How can I improve on it?  Here's my thinking right now.

Parts that work:
  • Java.  While I considered Perl for a while, I now know at least enough about regular expressions in Java to be dangerous.
  • Breaking the problem down, and solving the easy parts first.
Parts that I can improve:
  •  Premature data modelling.  I was focused on targeting a relational data model.  While there will ultimately be a relational database, concentrating on what I had specified for that model and generating load files for it was putting the cart before the horse.  Derive an object model first, tweak as needed, and then decide how the data should sit relationally.
  • Lack of a scorecard.  While I had processed the data in order of increasing difficulty, the capability to do so was not designed into the rather ad-hoc software.  The program needs a serious redesign to filter and attack the problem in a more systematic way.  Being able to measure progress is a side-effect of a good design in that respect.
If I re-attack the software design with those criteria in mind I should be able to sustain the effort to the end -- and to make something that is easier to return to after a break.

Wednesday, March 6, 2013

Getting re-inspired

I've just been re-reading Jack Campbell's The Lost Fleet: Beyond the Frontier: Dreadnaught.  A tad formulaic, but good fun and reminding me how much fun a science fiction world can be.

I've mused on this a couple of times recently, and there are two points to re-starting this project that I keep coming back to:
  • The amount of data to process is very large and for the values I need for my plans so far require extracting one of the most indirect values (mass) for every data point.  It finally occurred to me that I could us a proxy that we have for every object - luminosity.  OK, so there is no reason to believe that luminosity relationships would make it possible to travel faster than light; but there is no reason to think that gravity would either, it just feels more like it should.  Interestingly enough, luminosity is also the relationship Pournelle uses for his Alderson drive.  I don't think I run much risk of ending up with the same results however.  The important thing is that it will get me to having "jump maps" faster.
  • As far as data reduction goes, I waffle back and forth on JAVA vs a scripting language such as Perl.  I will stick with Java for now, but perhaps more on this later.
So, consider this project re-started.