Modifying StarGen

[Tegmine]

I've just been using the -M option, and have gotten some ok results. Haven't tried the other script you wrote though.

I like what you've done with the program!

-M-

[selden]

Tegmine,

I'm glad the modified Stargen is working for you!

The star luminosities calculated when you use the -m option attempt to simulate stars on an idealized main sequence. The brightness of real stars tends to vary from that somewhat. In principle, Stargen could be modified further to slightly randomize the luminosity, but the current code doesn't do that.

The internal tables allow more parameters to be specified for a star system than currently are available from the command line. (e.g. luminosity and some orbital parameters for multiple-star systems) It should be possible to modify the code to expose some of them. I'll investigate.

[omega13a]

I think all you'd have to do is insert your moon code at the end of the (modified) Celestia output code.

However, I think the experimental code which uses planetesimals to generate the moons needs a lot of work. When I tried it, it seemed to generate only 2 or 3 moons at most. That's why I added an option which writes a script which uses an external program to generate moons. Of course, writing such a program is a challenge, too!

Looking at the code, I was sort-of able to do that. I also fixed a problem of Stargen forgetting to tidally lock moons that orbit within a certain distance of their planet. One other major problem with Stargen's moon generation routine is that I have yet to come up with a solution for is that sometimes it creates a very large moon for a planet that is so massive, it and the planet should be orbiting a barycenter outside of the planet's surface. Such a situation is possible (Pluto and Charon are good example of this) but the output should include include the fact that both the planet and moon orbit a barycenter. There is also a couple other problems I've yet to think of a solution for. One is that moons tend to slow down the rotation of planets. The other is sort-of a recent finding I read about on MSNBC's tech and science section sometime in the past few weeks. If a large moon is orbiting too close to an Earth-like planet (or anyother large body for that matter), it could render the planet uninhabitable due to the tidal actions triggering volcanic activity and thus making a 'tidal Venus'.

I haven't played around with your extenernal moon generation program yet. I use Linux and have to run it under WINE since I don't have your program's source code. It gave me the following error:

Code: Select all

err:module:import_dll Library cygwin1.dll (which is needed by L"Z:\\home\\omega13a\\celestia stuff\\StarGenSource_2012\\moon_orbits.exe") not found
err:module:LdrInitializeThunk Main exe initialization for L"Z:\\home\\omega13a\\celestia stuff\\StarGenSource_2012\\moon_orbits.exe" failed, status c0000135
[omega13a@omega13a-desktop StarGenSource_2012]$ err:ntdll:RtlDeleteResource Deleting active MRSW lock (0x1124b4), expect failure

I guess I'll have to see if I can install cygwin under WINE and get it to work (something I've never tried...).

Anyways, here's the source code after my changes. Please note I converted it to a KDevelop project that uses CMake.

http://fedtrek.com/staff/omega13a/celes ... n_2012.zip

One last thing before I forget, it would be nice if it included some default textures to use since the SSC output makes references to non-existant planet textures and cloud maps.

[selden]

I would be very surprised if Cygwin runs under Wine. Running a linux emulator under linux seems just a little perverse

My moon generation program is compiled using g77. I haven't tried to make it compatible with gfortran. It has other problems, too: often its orbits are too close together. I haven't figured out a good way to make them better. One way might be to "evolve" them using an nbody program, but I haven't found one that I really like. Mercury (http://www.arm.ac.uk/~jec/) is a possibility, but its input format is, shall we say, baroque. It does support initial conditions defined using Keplerian orbital parameters, unlike most n-body programs. Evolving Stargen's orbits probably would be appropriate, too, but then its planetary descriptions would need to be changed to correspond to the results.

Most of the textures that I've been using were generated using Mogensen's planet. They could be significantly improved since none of them have any craters.

Both the moon program and the textures are at home and I'm not. I'll try to package them tonight if I have time. The planet textures will be too big to upload here, although the monn generator is relatively small.

[omega13a]

Cygwin doesn't want to install properly under Wine. I guess I'll have to compile the moon generaters code.

Edit: I also fixed somemore bugs regarding moons, the most import one was one that caused the program to crash when outputing a spreadsheet for a system that had a moon with an atmosphere. You can still download the source from the same location as before (link in my previous post).

[selden]

I've attached a zip containing moon_orbits.f (and moon_orbits.exe for Cygwin).

medres textures compatible with my version of stargen are available at
http://www.lepp.cornell.edu/~seb/celest ... medres.zip (8.5MB)

Be sure to read the files README.txt which are included in both.

[omega13a]

Thanks! There is one small typo in the read-me file for moon_orbits.

Code: Select all

g77 moon_orbit.f -o moon_orbit

should be

Code: Select all

g77 moon_orbits.f -o moon_orbits

[selden]

Thanks!

Of course, you also could just type ./moon_orbit

[edit]
fixed.
[/edit]

[omega13a]

I'm getting some rather... odd results for moon orbits. All the moons being generated for a signle planet have the same eccentricity, argument of perhilion, longitude of the ascending node, and mean anomoly. To make it more odd, their argument of perhilion, longitude of the ascending node, and mean anomoly are all the same value. To see what I mean, here's what I got for one planet:

Code: Select all

 "Moon           1 " "GAM Lep/p9"
 {
  Class "moon"
    # mass    =   1.09851272863599075E-007  x Earth =   6.56273474341713664E+017  kg
    # density =   0.92565775064094435     
  Radius    55.315723942237881     
  Mesh "asteroid.cms"
  Texture "tethys.*"
  EllipticalOrbit
  {
    Period             6.1017077145560217     
    SemiMajorAxis      508898.63919234707     
    Eccentricity      2.27451796216104896E-003
    Inclination       -1.0373542739458554     
    ArgOfPericenter    81.882648468017578     
    AscendingNode      81.882648468017578     
    MeanAnomaly        81.882648468017578     
  }
  Albedo   0.21606257805491924     
 }
 
 "Moon           2 " "GAM Lep/p9"
 {
  Class "moon"
    # mass    =   6.05101831167861436E-003  x Earth =   3.61499935976303813E+022  kg
    # density =    3.2999999523162842     
  Radius    1377.7441042333237     
  Texture "ganymede.*"
  EllipticalOrbit
  {
    Period             65.812352473826238     
    SemiMajorAxis      2484288.1405950687     
    Eccentricity      2.27451796216104896E-003
    Inclination       0.32886742076975883     
    ArgOfPericenter    81.882648468017578     
    AscendingNode      81.882648468017578     
    MeanAnomaly        81.882648468017578     
  }
  Albedo   6.06060614817946139E-002
 }
 
 "Moon           3 " "GAM Lep/p9"
 {
  Class "moon"
    # mass    =   2.58214587594485538E-004  x Earth =   1.54262558920697551E+021  kg
    # density =    3.2999999523162842     
  Radius    481.45163221958109     
  Texture "ganymede.*"
  EllipticalOrbit
  {
    Period             15.561399903176579     
    SemiMajorAxis      949939.90492394671     
    Eccentricity      2.27451796216104896E-003
    Inclination       -1.0945741114068084     
    ArgOfPericenter    81.882648468017578     
    AscendingNode      81.882648468017578     
    MeanAnomaly        81.882648468017578     
  }
  Albedo   6.06060614817946139E-002
 }
 
 "Moon           4 " "GAM Lep/p9"
 {
  Class "moon"
    # mass    =   6.52200602378731338E-004  x Earth =   3.89637683873101696E+021  kg
    # density =    1.6866623791964239     
  Radius    820.06459535711338     
  Texture "callisto.*"
  EllipticalOrbit
  {
    Period             10.776803115285004     
    SemiMajorAxis      743573.07466163021     
    Eccentricity      2.27451796216104896E-003
    Inclination      -0.45854004778606688     
    ArgOfPericenter    81.882648468017578     
    AscendingNode      81.882648468017578     
    MeanAnomaly        81.882648468017578     
  }
  Albedo   0.11857737651994464     
 }
 

That I got by running this command: ./moon_orbits -a 1.9389 -m 46.9662 -M 1.2000 -n p9 -N 4 -s 62681 -S GAM Lep

Maybe this has to do with me compiling it with gfortran 4.5.1 instead of g77?

edit: I found the g77 compadibility packages which included the g77 compiler. I recompiled it and the results are more random. It seems that while the code can compile using gfortran, the code isn't entirely compadible.

[Tegmine]

Ok, here's what I type....

Code: Select all

./moon_orbits -a 1.16 -m 2.3872 -M 1.05 -n p4 -N3 -S Shamash

Here's the message I get...

Code: Select all

-bash: ./moon_orbits: is a directory

What am I doing wrong?

-M-

[selden]

I'm guessing that you have the program moon_orbits.exe in the directory moon_orbits

You need to copy or move moon_orbits.exe into the the directory where you want to type the command ./moon_orbits (or where you want to run the script which invokes ./moon_orbits)
e.g.
cp ./moon_orbits/moon_orbits.exe .
(which means copy moon_orbits.exe from the directory moon_orbits into the current directory.

or (in the example you provide) use the command
./moon_orbits/moon_orbits (followed by appropriate arguments)

[omega13a]

I noticed one thing about moon_orbits that is somewhat of an irritation. Lets say stargen generates a solar system that has a brown dwarf that is like 5000 earth masses and tells you to run the moon orbits program to generate 170 moons. You run the moon orbits program command it tells you to. The Moon orbit's program ends up generating some large moons that are so big that it gets caught in what for all intents and purposes should be considered an infinite loop trying to find places to put them after it creates like 8 moons. To see what I mean, run this command:

Code: Select all

./moon_orbits -a 5.9382 -m 5694.3710 -M 2.0000 -n p7 -N 170 -s 7002 -S BET Cas

[selden]

It happens with smaller masses, too. I've been thinking about ways to avoid this. I don't know how soon I'll have a new version available, though.

[omega13a]

I think the best approach might be to either have the masses of the moons decrease at a quicker rate. I also think it would be a good idea if there was something in the code that would force the loop to stop after so many itterations. It may not be realistic from a scientific point of view but it would at least allow for the program to output the moons it did succeffully place. I'm going to try to make a version in C++ since I'm more familiar with that langauge. Another improvement: instead of nameing the moons that it outputs Moon 1, Moon 2, etc have it name the moons like (name of planet)-1, (name of planet)-2, etc. It really bugs me when I install some add-on and discover that there are moons that share the same name in the addon.

[selden]

Developing your own, competing moon generator sounds like a great idea!

[omega13a]

A while back, I started to use stargen's code to make my own solar system generator. Maybe it would be better if I took the algorithm in the moon orbits thing and put it in it...

[selden]

Sounds reasonable to me, so long as you understand and accept the different limitations.

StarGen's system generator (accrete) is an approximation based on early theories of how planetesimals might form from accretion in dust and gas clouds. Modern theories are much more sophisticated, but I don't know of any publicly available software packages to implement them. The programs I've read about seem to require supercomputers so that they'll run in reasonable amounts of time.

The random number generation algorithms in my moon_orbits program have only a minimal relationship to reality -- the total mass shared among the moons is probably the only serious one. The mass/density/radius relationships and period/sma formulae are about right, but their initial choices aren't based on anything much.

[selden]

Here's an updated version of moon_orbits.

The following changes have been made since v1.0:

c 1.01 cleaned up code so ftnchek doesn't complain so much
c 1.02 replaced calls to ran(dmy) by calls to randf()
c 1.03 explicit output formatting instead of just *
c 1.04 place orbits between existing orbits
c instead of randomly within max radius
c 1.05 prefix moon by name of planet so it'll be unique in this star system
c 1.06 include option name when complaining about it being missing
c 1.07 include TestPlanet specs if appropriate
c 1.08 include program name in catalog file

Perhaps as a side effect of the first two changes, compiling with gfortran now seems to produce the correct results.

[omega13a]

It compiled with gfortran. However I noticed something. It is very rare for it to generate a moon that orbits in under a week around a gas giant. I've made moons for probably a dozen or so gas giants and out of them, only two have a moon that orbits in under a week. I find that a little odd considering in our solar system just how many round moons orbit in under a week. I think a possible solution to this could be to start the maximum allowed distance out small and increase it as more and more moons are generated.

[selden]

I found a bug in the orbit placement which might be related. Hopefully I'll be able to post an updated version this evening, about 8 hours from now. (It's at home and I'm not.)