Klassieke gravitatie met eindige voortplantingssnelheid en Mercurius

[Xilvo]

Je zegt dat je, met de "Mercurius situatie", na tien rondjes dezelfde baan krijgt met en zonder delay. Ik zeg dat het verschil, mocht het effect overeenkomen met wat de ART voorspelt, na tien rondjes te gering is om te zien.

dat heb ik wel degelijk begrepen en daarom ook expliciet toegevoegd dat je computer het moet aankunnen qua benodigde stapgrootte (qua vereiste nauwkeurigheid) en aantal stappen (voor zoveel rondjes).
Enige wat ik op dit moment kan concluderen is dat ik nog geen aanleiding zie voor de prullenbak optie.

Precies daarom schreef ik eerder dat rekentijd een probleem kan zijn. Het effect is heel klein dus moeten veel omlopen berekend worden, heel nauwkeurig berekend worden.
Het nauwkeurig bepalen van de richting van de lange as is een uitdaging op zich.
Een snelle computer en slim programmeren is dan zeker noodzakelijk. Geheugen is geen probleem op iedere niet al te primitieve computer.

[HansH]

Precies daarom schreef ik eerder dat rekentijd een probleem kan zijn. Het effect is heel klein dus moeten veel omlopen berekend worden, heel nauwkeurig berekend worden.
Het nauwkeurig bepalen van de richting van de lange as is een uitdaging op zich.
Een snelle computer en slim programmeren is dan zeker noodzakelijk. Geheugen is geen probleem op iedere niet al te primitieve computer.

Dus dan zou het moeten lukken, evt wat langer wachten en een nachtje rekenen is ook geen probleem immers. maar ik ben al wel een keer tegen het maximale aantal punten aangelopen met mathcad, dus er ligt wel een grens ergens alleen weet ik niet of die begrenst is door het pakket zelf of door de computer.

evt kun je nog een andere situatie bekijken met meer precessie en te kijken of die dan overeen komt met de door de ART berekende precessie van dezelfde situatie. maar zover zijn we nog niet. eerst maar eens zien of de juiste code te maken is voor het te onderzoeken model.

[Xilvo]

Dus dan zou het moeten lukken, evt wat langer wachten en een nachtje rekenen is ook geen probleem immers. maar ik ben al wel een keer tegen het maximale aantal punten aangelopen met mathcad, dus er ligt wel een grens ergens alleen weet ik niet of die begrenst is door het pakket zelf of door de computer.

In, bijvoorbeeld, een gigabyte kun je ruim honderd miljoen floating point getallen kwijt, dus het zal eerder aan mathcad liggen. Bovendien hoef je niet ieder punt te onthouden.

[HansH]

omlooptijd=88 dagen=ca 8 miljoen punten als je elke seconde een punt neemt. Voor elk punt heb je al snel een stuk of 20 bijkomende variabelen nodig dus zit je op 150 Miljoen floating points per omwenteling dus dan zit je al op 1.5 GB data per omwenteling. Mathcad reserveert de datastructuur op basis van de code. geen idee of die ook slim weggooit als data niet nodig is. waarschijnlijk niet.
100 rondjes is dus al snel 150GB. ik had per uur of per 1/10 uur een stap dus is dan 40MB of 400MB per 100 rondjes. berekening duurt dan ordegrootte 5 minuten.

[Xilvo]

omlooptijd=88 dagen=ca 8 miljoen punten als je elke seconde een punt neemt.

Als zo'n kleine tijdstap al nodig mocht zijn, dan is het zeker niet nodig ieder punt te onthouden. Tenslotte wil je, per omwenteling, alleen de richting van de lange as van de ellips bepalen. Die bepaling kun je net zo goed met 8 duizend als met 8 miljoen punten doen.
Heb je die richting bepaald, dan kan je zelfs al die punten wissen.

Voor elk punt heb je al snel een stuk of 20 bijkomende variabelen nodig

En die kunnen meteen weggegooid worden zodra een punt bepaald is.

In Python kan ik op mijn computer (32 GB) vijf miljard 64-bit floating-point getallen reserveren. Bij zeven miljard krijg ik een foutmelding.

Het voordeel van zelf programmeren t.o.v. een (zonder meer prachtig) pakket als mathcad is dat je alles helemaal in eigen hand hebt.

[HansH]

Voordeel is dat prof p. het dan ook kan.

[Professor Puntje]

Voordeel is dat prof p. het dan ook kan.

Ja - maar prof p. vindt dat niet leuk...

Ik moet er eerst van overtuigd zijn dat het analytisch niet lukt voordat ik met Python aan de slag ga.

[HansH]

Ik moet er eerst van overtuigd zijn dat het analytisch niet lukt voordat ik met Python aan de slag ga.

qua analytisch kun je misschien eens kijken of je uit de hoek waarover de zwaartekracht vector op elk punt van de curve geroteerd wordt tgv de vertraging over een complete ellips een berekening kunt doen hoeveel daarmee de baan verdraait per rondje.

[Professor Puntje]

Ik moet er eerst van overtuigd zijn dat het analytisch niet lukt voordat ik met Python aan de slag ga.

qua analytisch kun je misschien eens kijken of je uit de hoek waarover de zwaartekracht vector op elk punt van de curve geroteerd wordt tgv de vertraging over een complete ellips een berekening kunt doen hoeveel daarmee de baan verdraait per rondje.

Die hoek lijkt op het eerste gezicht de oplossing, maar bij nader inzien is die uiterst problematisch. Een constant werkend koppel resulteert namelijk in een versnellende rotatie. En dat is niet wat we moeten hebben, en bovendien in strijd met energiebehoud. Ik probeer nu eerst uit te vogelen of daar iets aan te doen is zonder hier de reeds bestaande klassieke of relativistische theorieën te reproduceren.

[HansH]

Die hoek lijkt op het eerste gezicht de oplossing, maar bij nader inzien is die uiterst problematisch. Een constant werkend koppel resulteert namelijk in een versnellende rotatie. En dat is niet wat we moeten hebben, en bovendien in strijd met energiebehoud. Ik probeer nu eerst uit te vogelen of daar iets aan te doen is zonder hier de reeds bestaande klassieke of relativistische theorieën te reproduceren.

dat was al bekend en de voorgestelde oplossing ook:
Vervorm de ruimte op het punt waar je de berekening doet zodanig dat de vector weer precies de kant van de andere massa op wijst. daarmee los je het energiebehoud op in ruil voor een baan in een gekromde ruimte. omdat de kromming dan een functie wordt van de positie op de ellips krijg je daardoor automatisch de perihelium precessie voor een ellips en niet voor een cirkel omdat daar de kromming overval hetzelfde is dus netto geen effect over een heel rondje.

[Professor Puntje]

Het antwoord op je voorstel is ook al gegeven. Zonder differentiaalmeetkunde en/of tensorrekening kun je niets met "gekromde ruimte", maar als je er toch differentiaalmeetkunde en/of tensorrekening bij wilt halen kun je net zo goed of zelfs beter gelijk de ART bestuderen.

[HansH]

Het antwoord op je voorstel is ook al gegeven. Zonder differentiaalmeetkunde en/of tensorrekening kun je niets met "gekromde ruimte", maar als je er toch differentiaalmeetkunde en/of tensorrekening bij wilt halen kun je net zo goed of zelfs beter gelijk de ART bestuderen.

ik had het over een simpele rotatie en niet over een gekromde ruimtetijd zoals bij de ART. voor een rotatie heb je geen tensoren nodig, immers de rotatie is een directe functie van de positie en snelheid op het pad en de afstand tot de zon.

[HansH]

blijkbaar heb je mijn voorstel niet goed begrepen.

[Xilvo]

Het wordt wel een krom verhaal, zo. Een kracht waarvan de grootte vertraagd is maar de richting wel instantaan naar de huidige positie van het andere lichaam wijst.

[HansH]

Het wordt wel een krom verhaal, zo. Een kracht waarvan de grootte vertraagd is maar de richting wel instantaan naar de huidige positie van het andere lichaam wijst.

We weten dat zwaartekracht vertraagd doorgegeven wordt. dat staat vast. en we weten ook dat de banen bij benadering door de Newton formule met straal in het kwadraat beschreven worden. alleen beiden gaat niet samen. Daar heeft de natuur dus iets op gevonden.
Ik had het een aantal berichten terug daarom iet anders omschreven:

viewtopic.php?p=1189661#p1189661
puur retardatie-effect in klassieke gravitatie leidt tot niet-behoud van energie en impuls. mijn oplossing daarvoor is aan te nemen dat de ruimte vanuit het perspectief van de massa gaat roteren zodat de zwaartekracht vectoren weer in de zelfde richting wijzen. dat is immers een eis en gaat de natuur dan blijkbaar aan voldoen via de rotatie of kromming hoe je het wilt noemen.