TheiaSim

SRMeister

Registriertes Mitglied
Das ist ungefähr das selbe wie mein alter Laptop und dort habe ich auch starke Probleme mit VS2010.
Vielleicht können wir ja eine gute kostenlose Entwicklungsumgebung finden? Die haben ja zumeist wenig features und sind dadurch auch schneller. In der Schule haben wir mal mit Dev C++ gearbeitet. Was hälst du davon?
 
Zuletzt bearbeitet:

Bernhard

Registriertes Mitglied
Was hälst du davon?
Hallo SRMeister,

das ist ein interessanter Vorschlag. Der Gnu-Cpp-Compiler ist langfristig eventuell wirklich die bessere Wahl. Allerdings läuft inzwischen Visual Studio auf meinem Rechner auch ganz gut. Die erneute Installation hat scheinbar irgendetwas verändert. Eine weitere, wichtige Frage wäre auch, ob Dev-C++ mit Fortran klar kommt. BTW: Hast Du meine eMail erhalten? Ich habe Dir zwei Fortran-Dateien auf Deine eMail-Adresse geschickt.

Ich habe heute übrigens noch das Buch von Danby, "Fundamentals of Celestial Mechanics" bestellt, um den Einstieg in die Thematik etwas zu erleichtern. Da das Buch aus USA verschickt wird, dauert der Versand aber voraussichtlich bis Mitte Oktober.
Gruß
 

SRMeister

Registriertes Mitglied
ob Dev-C++ mit Fortran klar kommt.
Nein ich denke nicht, aber irgendeine IDE, die Fortran und C++ kann, muss es doch geben?? (Außer Visual Studio mit Intel Composer)
BTW: Hast Du meine eMail erhalten?
Ja die habe ich erhalten, ich könnte im Prinzip die Funktion mit in die Bibliothek kompilieren, aber eigentlich wäre es doch gut, wenn man die Funktion in C++ hätte? Sagmal, bist du jetzt auf Fortran umgestiegen??? :) :)

Zur Problematik x64 und x86: ich kompiliere meine Programme generell für x86, die laufen auf Win7x64 ja auch. Bynaus und allen anderen stillen Mitlesern könnte man ja eine x86 .exe zur Verfügung stellen? ich glaube auch nicht dass das Prog mit 64 Bit merkbar schneller wird.
Gruß

@Kibo: Das Programm gefällt mir richtig gut, ich bin gespannt wie das mit OpenGL aussehen wird! Sehe ich das richtig, dass du bis jetzt nur in 2 Dimensionen rechnest?
 

Kibo

Registriertes Mitglied
Ja das siehst du richtig, ist ja im Moment noch ein Prototyp, sollte kein großes Problem sein da noch eine extra Dimension mit einzufügen.
Die Linien sind gdi+, im Prinzip ist der Umstieg auf OpenGl kein Problem und für eine ansprechende 3D-Ausgabe wohl auch nötig. Im Moment habe ich noch ein andere Projekt am laufen, daher läuft der Simu eher auf Sparflamme.
Ich plane für das Programm noch ein GUI an der linken Seite zum manipulieren der Planeten in Echtzeit, sowie mehrere Einstellungsmöglichkeiten für Ansicht, Geschwindigkeit, Zentrierung, Zoom und natürlich wären beschriftete Gitternetzlinien auch nicht schlecht. Man soll ja die Umlaufbahnen auch mit der Realität irgendwie vergleichen können.
 

Bernhard

Registriertes Mitglied
Nein ich denke nicht, aber irgendeine IDE, die Fortran und C++ kann, muss es doch geben?? (Außer Visual Studio mit Intel Composer)
Das wäre wichtig, weil wir so schnell auf das Fortran-Programm nicht verzichten können. Das Debuggen des Cpp-Codes ist mittlerweile so kompliziert geworden (alle offensichtlichen Fehler sind behoben), dass ich mich erst mal mit dem Programm selbst beschäftigen werde, angefangen bei dem Buch von Danby

Zur Problematik x64 und x86: ich kompiliere meine Programme generell für x86, die laufen auf Win7x64 ja auch.
Das wäre gut. Ich habe da allerdings auch schon Gegenteiliges erlebt.

Bynaus und allen anderen stillen Mitlesern könnte man ja eine x86 .exe zur Verfügung stellen?
Bynaus habe ich bereits eine x86.exe geschickt und ich hoffe, dass er damit bald erste Tests machen kann.

ich glaube auch nicht dass das Prog mit 64 Bit merkbar schneller wird.
Um Geschwindigkeit geht es gar nicht, sondern darum möglichst bald erste wissenschaftlich verwertbare Ergebnisse zu bekommen.

@Bynaus: Lass mich bitte kurz zusammenfassen, was wir bisher erreicht haben:

Wir haben ein Programm (SCATR), welches das Sonnensystem für mindestens eine Millionen Jahre simulieren kann und das maximal 30 Tausend Testkörper mitberechnen kann. Über die Startbedingungen können wir die Anzahl der Testkörper festlegen. Wir können den Eintrittswinkel von Theia relativ zur Ekliptik festlegen und wir können den maximalen Streuwinkel der Trümmer festlegen.

Welche Ziele wollen wir uns ausgehend davon setzen?
a) Soll die Simulationszeit vergrößert werden? -> In den Veröffentlichungen seit etwa 1980 wurden Zeiten bis 3 Milliarden Jahre berechnet.
b) Wie tiefgreifend müssen wir uns mit der Stabilität des Sonnensystems über diese Zeiträume beschäftigen? -> Etliche Veröffentlichungen zeigen bereits sehr detaillierte Ergebnisse zu diesem Thema, wie z.B. die Stabilität der Plutobahn, die Stabilität der inneren Planeten usw.
 
Zuletzt bearbeitet:

Bernhard

Registriertes Mitglied
@Kibo: Das Programm gefällt mir richtig gut, ich bin gespannt wie das mit OpenGL aussehen wird! Sehe ich das richtig, dass du bis jetzt nur in 2 Dimensionen rechnest?
Hallo,

könntet Ihr dieses Parallelthema bitte in einem eigenen, bzw. neuen Thema verfolgen? Das Engagement von Kibo ist zwar sehr zu begrüßen, aber ich empfinde es ehrlich gesagt als ziemlich störend, wenn hier immer wieder themenfremde Einschübe kommen.
Gruß
 

Bernhard

Registriertes Mitglied
Zur Problematik x64 und x86: ich kompiliere meine Programme generell für x86, die laufen auf Win7x64 ja auch. Bynaus und allen anderen stillen Mitlesern könnte man ja eine x86 .exe zur Verfügung stellen?
Hallo SRMeister,

es wäre auch für unser Projekt hier sehr hilfreich auf der sourceforge-Seite sowohl eine 32-Bit, als auch eine 64-Bit Variante des Programmes zu veröffentlichen, weil meine 32-Bit-Version laut Bynaus nicht auf seinem 64-Bit Rechner läuft. Es wäre also hilfreich, wenn Du mit Deiner 64-Bit-Software ebenfalls eine Release-exe erzeugen könntest. Ich schicke Dir dann meine 32-Bit-Release-exe zu und Du könntest dann beide Dateien auf Deiner sourceforge-Seite veröffentlichen.

Würdest Du das machen?

Und wie gesagt. Solche "Problemchen" zwischen 32-Bit und 64-Bit sind alles andere als ungewöhnlich.
 

SRMeister

Registriertes Mitglied
ich konnte das Problem mit der rand() Funtion lösen. Hier mal alle Zeilen die was damit zu tun haben:
....
USE IFPORT
....
integer iseed
real*8 rran
....
iseed = 35791246
call srand(iseed)
....
rran = rand()
y = rran * (y_max - y_min) + y_min
....
Ich musste keine Compilereinstellungen ändern.
 
Zuletzt bearbeitet:

Bernhard

Registriertes Mitglied
Hallo SRMeister,

die genaue Position der USE IFPORT-Direktive war für meinen Compiler sehr wichtig. Könntest Du deswegen bitte die gesamte Datei als Forenbeitrag mit den Code-Tags veröffentlichen?
Gruß
 

Bynaus

Registriertes Mitglied
@Bynaus: Lass mich bitte kurz zusammenfassen, was wir bisher erreicht haben:

Wir haben ein Programm (SCATR), welches das Sonnensystem für mindestens eine Millionen Jahre simulieren kann und das maximal 30 Tausend Testkörper mitberechnen kann. Über die Startbedingungen können wir die Anzahl der Testkörper festlegen. Wir können den Eintrittswinkel von Theia relativ zur Ekliptik festlegen und wir können den maximalen Streuwinkel der Trümmer festlegen.

Welche Ziele wollen wir uns ausgehend davon setzen?
a) Soll die Simulationszeit vergrößert werden? -> In den Veröffentlichungen seit etwa 1980 wurden Zeiten bis 3 Milliarden Jahre berechnet.
b) Wie tiefgreifend müssen wir uns mit der Stabilität des Sonnensystems über diese Zeiträume beschäftigen? -> Etliche Veröffentlichungen zeigen bereits sehr detaillierte Ergebnisse zu diesem Thema, wie z.B. die Stabilität der Plutobahn, die Stabilität der inneren Planeten usw.

Yay, ich kann auch wieder was beitragen! :)

Zuerst eine Frage: Was meinst du genau mit dem "Eintrittswinkel" von Theia bzw. dem Streuwinkel der Trümmer? Wie genau gehen sie in die Simulation ein? Verstehe ich das richtig: das Programm simuliert nun also nicht mehr eine sphärische Verteilung aller Trümmer von der Position der Erde aus? Die Sache ist natürlich die, dass wir keine Ahnung haben (können) in welchem Winkel zur Ekliptik Theia die Erde getroffen hat, bzw. in welchem Streuwinkel die Trümmer davonflogen. Je nach Szenario wird da was anderes naheliegen, aber belegen kann man nichts davon. Deshalb würde ich vorschlagen, grundsätzlich eine sphärische Verteilung der Trümmer anzunehmen. Nicht, weil das realistisch wäre, sondern weil uns dies erlaubt, alle möglichen Fälle abzudecken (sonst müssten wir ja alle möglichen Eintrittswinkel und Streuwinkel separat durchprobieren). Dann sehen wir, ob diese Winkel überhaupt irgend eine Konsequenz haben (z.B.: "Die meisten Trümmer, die den Mars treffen, kommen von der sonnenzugewandten Seite der Trümmerwolke" vs. "Alle Trümmer haben etwa die gleiche Chance, Mars zu treffen").

Dann zu deinen Fragen.

a) Nein, die meisten Trümmer werden ja eher klein sein, selbst wenn sie in Asteroidenform vorliegen. Das heisst, die Sonne wird ihre Bahnen in wenigen Millionen Jahren auf einen Kollisionskurs mit sich selbst zwingen (Yarkovsky, YORP Effekte). Die Simulation sollte deshalb an sich nicht über ein paar Millionen Jahre hinaus gehen, andernfalls müssen wir diese Kräfte einbeziehen, und dann wirds wirklich kompliziert.
b) Da es ja um die Frage geht, was mit den Trümmern passiert ist, muss uns die Stabilität des Planetensystems nicht weiter gross beschäftigen (es sei denn, wir könnten zeigen, dass massive Trümmer einer bestimmten Grösse dieses destabilisieren - das wäre natürlich ein wichtiges Ergebnis).

Ich könnte mir einen Fall vorstellen, wo die Simulation über längere Zeit nützlich sein könnte: Wir sollten, um das obere Ende des Trümmerspektrums abzudecken, ein paar Simulationen mit massiven Trümmern machen (einzeln, oder bis zu maximal 10 davon): vielleicht von der Masse des Mondes, dh, 1% der Erdmasse, und schauen, welchen Einfluss diese auf das Planetensystem haben bzw mit welchen Himmelskörpern sie wann ungefähr kollidieren. Eine solche Simulation müsste dann wohl über deutlich längere Zeiträume laufen, evtl. 4.5 Mrd Jahre oder zumindest so lange, bis alle massiven Trümmer das System verlassen haben oder mit der sonne kollidiert sind.
 

Bernhard

Registriertes Mitglied
Was meinst du genau mit dem "Eintrittswinkel" von Theia bzw. dem Streuwinkel der Trümmer? Wie genau gehen sie in die Simulation ein? Verstehe ich das richtig: das Programm simuliert nun also nicht mehr eine sphärische Verteilung aller Trümmer von der Position der Erde aus? Die Sache ist natürlich die, dass wir keine Ahnung haben (können) in welchem Winkel zur Ekliptik Theia die Erde getroffen hat, bzw. in welchem Streuwinkel die Trümmer davonflogen. Je nach Szenario wird da was anderes naheliegen, aber belegen kann man nichts davon. Deshalb würde ich vorschlagen, grundsätzlich eine sphärische Verteilung der Trümmer anzunehmen. Nicht, weil das realistisch wäre, sondern weil uns dies erlaubt, alle möglichen Fälle abzudecken (sonst müssten wir ja alle möglichen Eintrittswinkel und Streuwinkel separat durchprobieren). Dann sehen wir, ob diese Winkel überhaupt irgend eine Konsequenz haben (z.B.: "Die meisten Trümmer, die den Mars treffen, kommen von der sonnenzugewandten Seite der Trümmerwolke" vs. "Alle Trümmer haben etwa die gleiche Chance, Mars zu treffen").
OK. Das ist eine gute Idee. Momentan werden die Trümmer symmetrisch zur Ekliptik in einem Bereich von +/- 20° gestreut. Aufgrund von Ralfs Einwand, dass manche Bahnen von heutigen Kleinplaneten relativ stark von der Ekliptik abweichen, sollte man diesen Bereich also auf +/- 40° vergrößern.

Ich könnte mir einen Fall vorstellen, wo die Simulation über längere Zeit nützlich sein könnte: Wir sollten, um das obere Ende des Trümmerspektrums abzudecken, ein paar Simulationen mit massiven Trümmern machen (einzeln, oder bis zu maximal 10 davon): vielleicht von der Masse des Mondes, dh, 1% der Erdmasse, und schauen, welchen Einfluss diese auf das Planetensystem haben bzw mit welchen Himmelskörpern sie wann ungefähr kollidieren. Eine solche Simulation müsste dann wohl über deutlich längere Zeiträume laufen, evtl. 4.5 Mrd Jahre oder zumindest so lange, bis alle massiven Trümmer das System verlassen haben oder mit der sonne kollidiert sind.
Ich werde dann nochmal testen, wie gut der SCATR-Code mit dem Mond zurecht kommt. Falls solche gebundenen Bahnen ebenfalls stabil berechnet werden, kann ich x Trümmer bei der Liste der Planeten einbauen.
 

Bynaus

Registriertes Mitglied
Momentan werden die Trümmer symmetrisch zur Ekliptik in einem Bereich von +/- 20° gestreut. Aufgrund von Ralfs Einwand, dass manche Bahnen von heutigen Kleinplaneten relativ stark von der Ekliptik abweichen, sollte man diesen Bereich also auf +/- 40° vergrößern.

Ja, das kann man, wenn genügend Rechenzeit zur Verfügung steht, nur schon um zu sehen, ob das einen Unterschied im Ergebnis macht. Ich erinnere mich, dass Planetenembryos - zumindest in einschlägigen Simulationen - gelegentlich auch relativ hohe Inklinationen haben können.

Ich werde dann nochmal testen, wie gut der SCATR-Code mit dem Mond zurecht kommt. Falls solche gebundenen Bahnen ebenfalls stabil berechnet werden, kann ich x Trümmer bei der Liste der Planeten einbauen.

Okay. Ich würde bei den massiven Trümmern vorschlagen, dass wir deren Anfangsparameter zufällig auswählen.

Vielleicht könnte man drei Serien von Simulationen machen:

1) Nur masselose Trümmer
2) Nur massive Trümmer
3) Sowohl masselose als auch massive Trümmer

Wenn wir eine grobe Anhnung davon haben, was in allen Fällen passiert, kann man entscheiden, wie wir weiter vorgehen wollen, ob wir uns etwa auf einen Aspekt fokussieren wollen, etc.
 

Bernhard

Registriertes Mitglied
Okay. Ich würde bei den massiven Trümmern vorschlagen, dass wir deren Anfangsparameter zufällig auswählen.
D.h. Verteilung der Anfangsorte und Anfangsgeschwindigkeiten wie bei den masselosen Trümmern?
Wieviel Trümmer mit Masse sollen es sein?
Welche genaue Massenverteilung sollen die Trümmer mit Masse dann haben?
 

SRMeister

Registriertes Mitglied
Dein 32bit Programm läuft bei mir fehlerfrei, ohne dass es nötig wäre, spezielle Kompatibilitätsoptionen zu setzen.
Ich kann mir im Moment nicht so recht vorstellen, woran es liegen könnte, dass es auf einem anderen x64 System nicht läuft.
Benutzt das Programm die gleiche theia_tp_200.in, die ich auch benutze? Weil bei meinem "Kompilat" bleibt eine andere Anzahl Körper übrig.
Ich werde jetzt deine 32bit und meine 64bit Version veröffentlichen, wobei die 64 Bit Version momentan die TPs über deine Funktion selbst erzeugt, die Datei theia_tp.in ist also erstmal überflüssig.
Als nächsten Teilschritt habe ich mir überlegt, möchte ich die Planetenkollision aktivieren. Die ist ja leider noch ausgeschaltet und r(Planet) sind auch noch nicht vorgegeben. Das wird wohl auch der Grund sein warum so viele TPs das System verlassen: sie tunneln vorher durch Planeten und bekommen dabei nen ordentlichen Schubs.

Zur Initfunktion:
Sonst habe ich noch die Verwendung von rand() verändert, so dass bei jeder Benutzung eine neue Zufallsvariable bereit steht.
Code:
[SIZE=0]
c Last revision: 9/25/12 S.R.
      
	subroutine io_init_tp_theia(ntp,npl,x_earth,y_earth,z_earth,
     &     vx_earth,vy_earth,vz_earth,
     &     xht,yht,zht,vxht,vyht,vzht,istat,rstat,frame)
      USE IFPORT
	include '../scatr.inc'
	include 'io.inc'

c...    Input
	integer ntp,npl
      real*8 x_earth,y_earth,z_earth
      real*8 vx_earth,vy_earth,vz_earth
	character*80 frame

c...    Output
	real*8 xht(NTPMAX),yht(NTPMAX),zht(NTPMAX)
	real*8 vxht(NTPMAX),vyht(NTPMAX),vzht(NTPMAX)
      real*8 rstat(NTPMAX,NSTATR)
	integer istat(NTPMAX,NSTAT)

c...   Internal
      integer iseed
      real*8 rran
	integer i,j,ierr,ns,ftest
      real*8 v_esc,r_earth
      real*8 y,phi,vn,y_min,y_max
      real*8 nx,ny,nz
      integer SCATTERING_ANGLE

c-----
c...  Executable code

c     Initialize
c     1 AU=149597870691 m

c	Initialize random generator
      iseed = 35791246
      call srand(iseed)

      SCATTERING_ANGLE = 20
	v_esc = 6.4604555902823027300785018765024e-3     ! AU/day = 11186.0 m/s
	r_earth = 4.2563891254523551325458216979349e-5;  ! mean radius of earth in AU (=6367467.5 m)

	y_min = 0.5 * (1.0 - cos((90.0 - SCATTERING_ANGLE)/PI*180.0))
	y_max = 0.5 * (1.0 - cos((90.0 + SCATTERING_ANGLE)/PI*180.0))

      if(ntp.gt.NTPMAX) then
         write(*,*) ' SWIFT ERROR: in io_init_tp_theia: '
         write(*,*) '   The number of test bodies,',ntp,','
         write(*,*) '   is too large, it must be less than',NTPMAX
         call util_exit(1)
      endif

	write(*,*) ' '
	write(*,*) 'ntp : ',ntp

      if(ntp.eq.0) then
         write(*,*) ' '
         return
      endif               ! <===== NOTE

c...  Determine the number of istat and rstat variables.  In what follows,
c...  we assume that they are the same.
      ns = npl + 2
      
      if(ns.ne.NSTAT) then
         write(*,*) 'Warning:  The size of istat and rstat arrays is '
         write(*,*) '          not NSTAT=',NSTAT,', but is ',ns
      endif

c Read in the x's and v's and istat(*,*)
	write(*,*) ' '
	do  i=1,ntp
          rran = rand()
          y   = rran * (y_max - y_min) + y_min   ! add random number instead of 0.5d0
          rran = rand()
	    phi = rran * TWOPI                     ! add random number instead of 0.5d0
          rran = rand()
	    vn  = rran * 0.4d0 + 1.0d0             ! add random number instead of 0.5d0   

	    nx = 2.0d0 * sqrt(y - y * y) * cos(phi)
	    ny = 2.0d0 * sqrt(y - y * y) * sin(phi)
	    nz = 1.0d0 - 2.0d0 * y

	    xht(i) = -9.814911942588033e-001 + nx * r_earth
	    yht(i) = -1.866158863169087e-001 + ny * r_earth
	    zht(i) = 5.097029871362697e-006  + nz * r_earth

	    vxht(i) = 2.931839043977104e-003  + vn * v_esc * nx
	    vyht(i) = -1.697334005001157e-002 + vn * v_esc * ny
	    vzht(i) = 3.022067795326298e-007  + vn * v_esc * nz
	
          do  j=1,ns
	      istat(i,j) = 0
          enddo

          do  j=ns+1,NSTAT
	  	    istat(i,j) = 0
	        if (j.eq.NSTAT-2.and.
     &            (frame(1:3).eq.'hel'.or.frame(1:3).eq.'HEL')) then
	          istat(i,j) = 1
	        endif
          enddo
        
          do  j=1,NSTATR
	        rstat(i,j) = 0.0d0
          enddo
	enddo

 	return
	end    ! io_init_tp_theia.f
c-----------------------------------------------------------------[/SIZE]
 
Zuletzt bearbeitet:

Bernhard

Registriertes Mitglied
Dein 32bit Programm läuft bei mir fehlerfrei, ohne dass es nötig wäre, spezielle Kompatibilitätsoptionen zu setzen.
@Bynaus: Dann fehlen bei Dir sehr wahrscheinlich noch weitere Bibliotheken oder Du hast das falsche Redistributable-Paket erwischt. Wir können vorerst aber auch so weitermachen.

Die Ausgaben des Programmes sind bereits so aussagekräftig, dass man jetzt auch mal nachsehen sollte, wo die masselosen Trümmer im Laufe einer Million Jahre "herunterkommen". Ansonsten erscheint mir ein großes Bruchstück mit der Masse 1% der Erde als sehr wichtig. Es wäre sehr interessant, wenn dieser "Mondkeim" in der Simulation ebenfalls Trümmer einfangen würde. Die Startgeschwindigkeit dieses "Keimes" müsste man in etwa so groß wählen, wie die Geschwindigkeit von Theia. Ich habe da aber wenige Ideen, wie groß diese Geschwindigkeit sein sollte.

BTW: Das Thema nimmt so langsam richtig Fahrt auf, WOW.
 
Zuletzt bearbeitet:

Bynaus

Registriertes Mitglied
D.h. Verteilung der Anfangsorte und Anfangsgeschwindigkeiten wie bei den masselosen Trümmern?
Wieviel Trümmer mit Masse sollen es sein?
Welche genaue Massenverteilung sollen die Trümmer mit Masse dann haben?

1) Ja, so dass wir verschiedene Richtungen mal durchprobieren und schauen, was rauskommt. Evtl nichts, aber das sollten wir zuerst überprüfen. Aber natürlich sollten wir pro Simulationsrun nicht hunderte von massiven Fragmenten haben, sondern nur soviele wie einigermassen realistisch.
2) & 3) Die totale Masse der massiven Trümmer sollte 1 Marsmasse = 10 Mondmassen = 0.1 Erdmassen nicht überschreiten. Wie gross sie allerdings genau sein sollten, ist schwierig zu sagen. Fragmentation bei einem solchen Impakt ist ein schwieriges Thema, das zudem kaum erforscht ist. Ich hätte jetzt - vom Blick auf die Hit-and-run-Impakt-Videos - gesagt, dass die grössten Fragmente stets etwas kleiner als 1 Mondmasse sind. Also nehmen wir doch 1 Mondmasse für das grösste Fragment. Und dann vielleicht noch vier mit 0.1 Mondmassen dazu. Ich würde darüber hinaus die Bahnen (Abstrahlwinkel & Geschwindigkeit) dieser Fragmente einigermassen ähnlich setzen, innerhalb eines Dec/Rect Winkels von nicht mehr als 15°. Das heisst, in jeder Simulation könnte zuerst eine Hauptrichtung festgelegt werden, um die dann die tatsächlichen Fragmentbahnen geringfügig variiert werden. Die Geschwindigkeit der Trümmer sollte sich im Bereich zwischen 1 und 1.4 * v_esc bewegen.

EDIT:

@Bynaus: Dann fehlen bei Dir sehr wahrscheinlich noch weitere Bibliotheken oder Du hast das falsche Redistributable-Paket erwischt.

Ja, mir scheint "MSVCR100.dll" zu fehlen (Meldung nach Installation der 64bit Version auf sourceforge).
 
Zuletzt bearbeitet:

Bernhard

Registriertes Mitglied
2) & 3) Die totale Masse der massiven Trümmer sollte 1 Marsmasse = 10 Mondmassen = 0.1 Erdmassen nicht überschreiten.
Hallo Bynaus,

ich habe gerade den SCATR-Code mit den Startbedingungen für Merkur-Venus-Erde-Mond-Mars-Jupiter-Saturn-Uranus-Neptun vom 01.04.2011, sowie Null Testkörper gestartet und 1 Millionen Jahre in die Zukunft rechnen lassen. Ergebnis: Mond und Mars verlassen das Sonnensystem und vagabundieren irgendwo bei 1.0e5 bis 1.0e6 AU durch das freie All :confused: . Genau so etwas hatte ich ein wenig befürchtet, weil der Ansatz des Wisdom/Holman-Algorithmus davon ausgeht, dass die Bewegung der Planeten in erster Linie von der Sonne bestimmt wird und der Rest lediglich Bahnstörungen sind. Beim Mond trifft das aber gar nicht zu. Dessen Bewegung wird natürlich maßgeblich von der Erde mitbestimmt, so dass man für eine korrekte Bahnberechnung vermutlich den SCATR-Code entsprechend anpassen müsste und das ist keine leichte Aufgabe. Dass auch der Planet Mars das Sonnensystem verläßt finde ich etwas eigenartig, aber vielleicht fehlt hier ja der Asteroidengürtel als Stabilisator?
Gruß
 
Oben