Detailed star system generation rules

Sweet! 8)

Doesn't look too wordy to me... and if the consistency is as good as this example, I don't see that it would be hard to parse the output and put it in a more visual context... (well, most programers in the last 10 years might have a problem with it, but I can't tell you how many programs I've written to take data like this and normalize it into a DBMS or make pretty plots, etc.)

Curiosity - you are providing stellar evolution data (ZMass = ZAMS mass?).. are you using an accretion type model , or just randomly generating the system based on probabilities? Or... (FYI - the last time I looked at any serious astrobiology was the late '80s)
 
BP said:
Curiosity - you are providing stellar evolution data (ZMass = ZAMS mass?).. are you using an accretion type model , or just randomly generating the system based on probabilities? Or... (FYI - the last time I looked at any serious astrobiology was the late '80s)

Yep - I'm evolving the star from Zero Age Main Sequence (I'm using the latest published stellar evolution grids, from around 2006). Not doing accretion though - I'm generating gas giants, migrating them in, seeing which ones survive that process, generating the rockies after that, seeing which ones survive that process given the gas giants that are there (some may be ejected, some may instead be asteroid belts), and then the worlds that survive are the final system.

This particular system had two more rockies in it to start with (one either side of the LGG) but those got ejected from the system.
 
EDG said:
...I'm using the latest published stellar evolution grids, from around 2006)...

Whoa - sounds pretty hardcore there :shock: :D

Couple off the wall questions -

Does this model also lend itself to stellar atmo - specifically chemical spectra? (actually did some code a while back for making pretty spectra props for planetary atmos, but my stellar model was a total hack loosely based on CT stellar data)

Are the planetary migrations based on n-body calcs and are they repeatable - i.e. is there one seed for the system that can consistently generate the identical migration?

(Please excuse any blatant ignorance here - the last astophysics text I looked at was in the 80's and while I remember doing calc's for collapsar times and shwartz..(sp?) radii and some terms (Wolfe-Rayet?) - I can't recall much about brown dwarfs and would be hard pressed to even layout the sequence of the H-R diagram (which for all I know is obsolete) :cry: )
 
BP said:
Whoa - sounds pretty hardcore there :shock: :D

slighly - lots of table referencing, interpolations, etc. Unfortunately that means it's pretty much impossible to do by hand - you need a computer to calculate it.

Does this model also lend itself to stellar atmo - specifically chemical spectra? (actually did some code a while back for making pretty spectra props for planetary atmos, but my stellar model was a total hack loosely based on CT stellar data)

No, that'd be waaaay too much detail. In fact the spectral types are all just based on temperature-based, not spectral lines. But there's nothing stopping anyone from just tacking on weird spectral properties later.

Are the planetary migrations based on n-body calcs and are they repeatable - i.e. is there one seed for the system that can consistently generate the identical migration?

Nope, migration is pretty simple - all the jovians go in by a random percentage of their starting distance. I should perhaps tweak it so that some go in and some move out, but I have no idea what would be realistic there. And yes, it's repeatable - if I enter the same seeds then I'll get exactly the same systems.
 
EDG said:
... pretty much impossible to do by hand - you need a computer to calculate it.
With computers so readily at hand, nobody is likely to want to do it by hand :wink:

Even if it could 'practically' be done by dice and tables, I think the beauty of what you are doing would be lost...

The key problem is making robust multi-platform software (of course, there is one language that is supported unmodified by almost every platform, but most people are unaware of this fact... and few programers are familiar with it)

...No, that'd be waaaay too much detail. In fact the spectral types are all just based on temperature-based, not spectral lines. But there's nothing stopping anyone from just tacking on weird spectral properties later.
I used the spectral types to reference which prototype star a given star most resembles and its temperature to swag it. Of course this is just 'flava' - I don't see it as a plot element or anything - though if the characters want to try mining a star, why not let them :twisted:

Back to your example -

What does 'migrate' represent?

And MMW?
 
BP said:
The key problem is making robust multi-platform software (of course, there is one language that is supported unmodified by almost every platform, but most people are unaware of this fact... and few programers are familiar with it)

Don't laugh, but I've done all this in FORTRAN :) (in my defence, it's more F90/95 than F77 ;) ). I do have a Python book here that I'll attempt to learn so I can convert it to something more modern (and expandable, which means I may be able to add graphics too). But Fortran works for me :).


Back to your example -

What does 'migrate' represent?

And MMW?

"Migrate" is how far the giants have migrated (it doesn't mean anything for the rockies - they're still where they formed) - if it says (e.g.) 0.25, it means that the jovians have migrated to a quarter of their original distance.

MMW is Minimum Molecular Weight - it's the molecular weight of the lightest gas that can be retained by the planet. I don't randomly roll the atmosphere type (initially) - I figure out the size properties, determine the MMW and then that tells me what kind of atmosphere it has. Doing it this way means I'll never have worlds that are too small to retain breathable atmospheres - after that I can roll to see if it's tainted or whatever. Again, this is where it's advantageous to use a computer because I can use that to calculate the MMW for every planet on the fly.
 
Nothing wrong with FORTRAN (though the last time I used it was F77) :D

Python is a nice language, too. If you are looking for a more recent language you might be interested in F# (it is OCAML based, not Fortran or F). Its really great for scientific work (even includes unit of measure support) - and it interfaces very easily with Interl fortran (and others, as well as all the .NET languages - which are supported on more than just the Windows platforms).

And, there is great graphics support (including OpenGL). Not to mention it is a very easy language to develop in (and everything is free from MS = visual studio express) and fairly fast.


MMW - gotcha! Atmo is one of the more important aspects for an RPG setting IMHO, so I gotta love this! I notice in your example you have a code (Traveller?) - wondering if you've expanded upon this. I don't particularly like the composite atmo code - mixed density with composition characteristics (so no thin/ccorrosive, etc.).
 
BP said:
MMW - gotcha! Atmo is one of the more important aspects for an RPG setting IMHO, so I gotta love this! I notice in your example you have a code (Traveller?) - wondering if you've expanded upon this. I don't particularly like the composite atmo code - mixed density with composition characteristics (so no thin/ccorrosive, etc.).

The atm code is the same as in Traveller (for now at least). And yeah, I never liked the combined pressure/compositional codes either.
 
BP said:
Nothing wrong with FORTRAN (though the last time I used it was F77) :D

Ah, FORTRAN. Brings back memories, that does. Campus mainframe in '84, taking half the time anyone else was for assignments, busting the grading curve in class...
 
They used Fortran a lot at my first job - a forestry commission research station. They had some very complex forest growth models in it. I even got coerced into writing a program in it ... never again ;)

Python's solid, it has some excellent scientific and graphing libraries. It's my language of choice these days.

Simon
 
simonh said:
Python's solid, it has some excellent scientific and graphing libraries. It's my language of choice these days.

I tried Java but just couldn't get my head around it. Python at least looks kinda similar to fortran in some ways, so hopefully I'll be able to make the switch to it. Though I still do really like Fortran (and I don't care how old it is, it does the job I want it to do!).
 
Java is a nice language, but even though it is an imperative language like FORTRAN (and C and Python), it is not an algebraic language.

F# is a funcitonal language (like LISP) and is also very algebraic (like FORTRAN). Python and C# are borrowing functional elements because functional development is often more efficient for a great number of problem domains. The syntax of F# is a little bit of a challenge (because of its terseness - like Python and even C for that matter) - but it is much more natural for math.

Take a peek at this site blog which can get you started and also this one. These aren't very impressive of course, but I can dig up some simple ones that very quickly (less than 1 screen of code) show 3D animations of complex graphs...

There are other reasons for funcitonal programming - notably their state independence which means easy parallelling - very important for today's mutli-core CPUs and massive core GPUs.
 
BP said:
Java is a nice language, but even though it is an imperative language like FORTRAN (and C and Python), it is not an algebraic language.

I tried learning object oriented programming in Java and then C# but both are far too over-engineered for my tastes. You need scads of code to do just about anything.

F# is a funcitonal language (like LISP) and is also very algebraic (like FORTRAN). Python and C# are borrowing functional elements because functional development is often more efficient for a great number of problem domains. The syntax of F# is a little bit of a challenge (because of its terseness - like Python and even C for that matter) - but it is much more natural for math.

I'm just toying with the functional features in Python, and i can realy say I understand them completely.

My only problem with F# is I'm a Mac user at home, so anything based on .NET is out of the question. Are there any attempts at an implementation of F# on a non-proprietary platform?

Simon
 
simonh said:
...I'm just toying with the functional features in Python, and i can realy say I understand them completely.

My only problem with F# is I'm a Mac user at home, so anything based on .NET is out of the question. Are there any attempts at an implementation of F# on a non-proprietary platform?

Simon

Yep!

Found this with a quick google:
I just started using FSharp with Mono 1.2.6 on Mac OS X 10.5 Leopard.
The Mono download is pretty straightforward. If you have Leopard, just go to
http://www.go-mono.com/mono-downloads/download.html,
select Mac OS X, and follow the instructions (mostly you'll be asked to agree to the license, etc).

After you download Mono, go to
http://research.microsoft.com/fsharp/release.aspx
to download the zip file for F# version 1.9.3.14, and follow the
instructions in README-fsharp.html, which essentially asks you to run install-mono.sh. One problem I encountered is that install-mono.sh has MSDOS line endings. So you need to convert the file to have Unix line endings, by using a tool such as ConvertNewlines (google it for the url). Once you've done this, you can run install-mono.sh.

You might want to take a look at
http://cs.hubfs.net/forums/thread/4694.aspx for description of my initial experiences using Mono and FSharp on MAC.

BTW: F# is a .NET language which means that for runtime only CLR support is needed - which means Mono on non-WinOS machines. You can also run Mono on a web server and host a .NET web app (i.e. user does not need .NET platform for browser use).
 
Argh! - I lost another post when I hit submit and was timed-out by forum! :x

(Hope the site update takes care of this - that was my best post ever :roll: )

Anyway - what I meant to say earlier and lost my focus - was there is no good reason to not program in Fortran - just mix programming languages to implement those features Fortran is weak on: GUI, Web, DB.

Python is an excellent language - and since it is imperative it has similarities with Fortran (so infact does Java - but its C/C++ syntax and its strong OOP support are probably going to throw you - rest assured if you know Fortran fairly well then you actually understand the concepts, just have to get around the syntax).

F# is a functional (mixed actually) language, so its syntax and methodology is different. However, most people find this simpler and more efficient - especially when implementing numerical methods.

F#'s numerical support is even better than Fortran's. It has built in big integer and arbitrary sized rational arithmetic support and its syntax matches the way we write equations much better than an imperative language. It even includes unit of measure.

Python is nowhere near as robust in this area. You can add extensions (numpy, etc.), but these add complexity, are still often slow and are not often stable.

It is also designed to be interpreted (though there are compiled versions - it is not well optimized for such) and thus is far slower than Fortran when it comes to many number crunching apps. What takes minutes now may take hours in Python.


Once you get past F#s own cryptic syntax ( |> and the like - which is designed for terseness, not intuitive clarity) and learn to program using functions passed to functions and even recursion it is very powerful and very intuitive and does things in very few lines of code compared to other high-level languages. And F# is fairly fast - likely comparable to Fortran. As a bonus, it supports parallel (multi-threaded) programming with almost no effort - which can make it even faster on most modern CPUs (multi-core/hyper-threaded)

As a full fledged member of the .NET family of languages it is supported by MS and all the tools are free (Visual Studio Express and .NET platform are all that is required - and the professional version is usually given away free at no-cost MS conferences whenever a new version comes out). It can directly interact with any other managed code language (C#, J#, VB.Net, A# , etc.) and call code from other compiled languages (C, C++, Fortran, etc. - there is overhead and caveats to this method, but it works really well).

This means it also has direct access to OpenGL, DirectX, ADO and ASP and all the other goodies of the .NET platform. And the tools are excellent with intellisense, project setup, debugging support, etc. Plus any knowledge here is directly transferable to the other .NET and Visual Studio languages.


Since I lost my original post this one is not as succinct - but, my point is that if I were to choose between Python or F# for your application domain (scientific) - I would try F# with Fortran. Since you can call your compiled Fortran directly from F# code and pass data (not so easy to do in interpreted Python) and F# has better buit in numerical support likely to be needed for later translation (if you so desire). Not to say Python isn't a great language - it just wouldn't be my first choice in this instance, unless I was working with other Python programmers.

FYI - Fortran.NET also exists - but it is not MS and it is not free (or even cheap). Also, IronPython is available for .NET (written in C#), but I have yet to try it (and it likely lacks the stability and support of F#, which has been in development for 5 years before its release last fall and which is monentarily supported by MS).

P.S. - if you have the bandwidth the video here is well done.
 
Back
Top