software di U1 (seconda parte: orbita di un fotone .. fino all’orlo esterno di U1)

E’ chiaro che -grazie a Gauss- (e l’archetipo del sasso che cade in un pozzo) (*1) il comportamento di un ente che subisce una accelerazione gravitazionale fino ad una velocità max raggiunta al centro di una sfera (per esempio di un pianeta), sarà lo stesso ordine di grandezza della decelerazione quando “frena” dopo la mezzeria.

Tuttavia applicando questi concetti ad un fotone dal centro del nostro universo, U1, vi è anche una densità (di U1) in diminuzione (nel moto dell’ente verso la frontiera di U1), e quindi essendo la velocità di un fotone legata al mezzo, ciò genera un aumento della velocità del fotone, se non aumentasse anche la massa di U1 alle spalle del fotone!

Infine alla frontiera di U1 (detto anche “orlo esterno” oppure “orizzonte degli eventi” di U1), dobbiamo ipotizzare che una massa, sia essa radiativa o massiva, non uscirà dal BH_frontiera, poiché “neanche la luce esce da un BH”. Ma va considerato che la “particella” fotone rallenterà fino alla velocità v=0, noi pensiamo, grazie alla formule del “travaso”, già discusse negli articoli precedenti, per poi riprendere velocità dopo avere cambiato direzione nel “cadere”.

Astraendoci dalla percentuale di massa massiva e massa radiativa del fotone in un particolare t=tx del suo “viaggio” il GOAL (dopo molti tentativi dal 2017 su mio blog 6viola rif worpress: https://6viola.wordpress.com/) -allora- è stato -il GOAL- cambiare di modello: Abbiamo -infatti- anche un altro modello di come si comporta una “particella” in un BH! Il modello delle equazioni di Einstein, nella soluzione di Schwarzschild, come modificate da Amadori e Lussardi per la luce! recependo il modello di Gauss nelle condizioni di inizializzazione di Cauchy del software in analisi numerica (*2)

(*1)
—

sasso che cade in un pozzo:

(download):

https://6viola.it/download/2543/?tmstv=1712309468

(lettura):

https://www.6viola.it/wp-includes/doc-web/pozzo-sasso-infn.pdf

—

(*2)
modello di Amadori e Lussardi in riferimento alla luce:

Einstein’s Theory of General Relativity: reverse engineering [k_Fermat solution]
https://6viola.wordpress.com/2018/06/21/einsteins-theory-of-general-relativity-reverse-engineering-k_fermat-solution/

§§§

Da tutto ciò:

ipotesi: (i1)

Dunque anziché calcolare la densità e da questa il raggio di Sch che variava nei software (old) Gauss-Penta-i (vedi trattazione 2017) (*3) all’aumentare della massa alle spalle .. abbiamo calcolato il rs=raggio di Sch totale e lo abbiamo lasciato fisso e con il raggio che indicava la posizione della particella, sia r0, con r0 < rs.

Nota Bene: il nuovo software (new) BH-7-3-2018-O-i.php (BHOi) -però- parte con input da “Gauss-Penta-13” al valore di circa (1/3)*rs. Quindi riprende il viaggio da “Gauss-Penta-13” che sebbene non fosse stabile e tendesse ad aumentare la velocità della luce (superato il valore (1/3)*rs) .. era ancora circa alla velocità della luce ufficiale e ci consentiva un “passaggio dei paramenti” per il nuovo modello BHO-i senza ricalcolare il moto di un fotone versus la frontiera di U1 a partire dal centro di U1.

(*3)
https://6viola.wordpress.com/2018/03/09/gausss-law-for-gravity-from-cmb-to-s1/

La cosa ha richiesto -comunque- (in new software) altri 13 software per il passaggio dei parametri e cioé

che in ultimo sembrava andare oltre rs senza che la “particella” si fosse fermata: e cioé da r1 fino ad rs, denominati in modo più completo:

come input (software):

BH-7-3-2018-O-1.php

BH-7-3-2018-O-13.php

++
cit on
++

Per evitare equivoci -però- nel seguito chiamerò

BHO-1 fino a BHO-13 ..

la stampa dell’_output_ del software BH-7-3-2018-O-i.php -> BHO-i

Mentre considero _input_ il software: BH-7-3-2018-O-i.php

++
cit off
++

Il nuovo problema osservato dall’output di BH-7-3-2018-O-13.php: era che la posizione indicata dalla particella, r0, superava rs (intendo rs come calcolato matematicamente nelle ipotesi di Cauchy/Gauss) ..

ipotesi: (i2)

Abbiamo allora introdotto “un controller del segno di rpunto” e quindi un “if logico” che testava se (in BHO-13)

if logico:

“rpunto < 0?”

il software che modifica BH-7-3-2018-O-13.php introducendo il controllo del segno della velocità misurata con rpunto è ..

BH-7-3-2018-O-13-tris.php

Era come immaginavamo:

ipotesi: (i3)

rpunto prima di giungere ad rs (che abbiamo dotato di uno spessore che tenesse conto che la luce non ci giunge a 45 miliardi di anni luce, ma a 47, e quindi uno spessore di circa 2 miliardi di anni luce) vedi la nota(#)
che cambiava di segno (del moto) come ci aspettavamo. Ed il superamento di rs avveniva perché il passo di campionamento operato da ds=circa 0.3E10 era troppo ampio per vedere il dettaglio nella fase di rallentamento del moto e di cambio di verso senza che si generasse un errore di interpretazione tra lo stato precedente e quello successivo costruito sullo stato precedente alle differenze finite.
(#)
“tale spessore” può essere detto spessore della “cupola di reverbero” che fa rimbalzare la luce che ha rallentato, e poi si è fermata, ed infine ha invertito il moto tornando verso il centro del nostro universo, U1, peraltro con angoli variabili dipendenti dai percorsi di arrivo alla “cupola di reverbero”: che si comporta come una sorta di “specchio”, che come uno specchio (o una cupola di reverbero) ha anche un suo spessore.

Cosa dovrebbe fare una particella rallentata fino a cambiare il verso in un BH (?) se non andare verso il centro del BH?

La risposta è semplice: muoversi verso il centro del BH. Ma volevamo avere la conferma matematica nel passaggio da un moto espansivo ad un moto compressivo.

Inoltre c’era un ulteriore problema:
Normalmente i computer personal sebbene operino a 64 bit e separino le cifre rappresentabili in una parte di circa 14 cifre esplicite e di una parte esponenziale di due cifre

scrivono (ad esempio) ..

3.11999999999999E+26 metri = rs+delta = raggio di rs più spessore della cupola

(quando fanno i calcoli) e poi ..

stampano invece ..

3.12E+26

e noi quindi dovevamo “operare uno zoom” dello stato del sistema in cui l’output non era fedele ma in uno stato di insufficiente spazio di rappresentazione ..

Se abbassavamo il passo di campionamento .. con 50 milioni di iterazioni .. necessitavano ancora molti software di “passaggio dei parametri” per avvicinarsi ad “rs+delta”.

Se non abbassavamo il passo di campionamento .. il software saltava allo stato successivo senza tenere nel giusto conto lo stato precedente, anche per problemi di “overflow della rappresentazione” manifestando “division by zero” poiché nelle equazioni di Einstein c’è un termine a denominatore “r0-rg0” (dove rg0=rs+delta nel nostro caso) e quindi una esplosione della rappresentazione matematica.

Dunque abbiamo operato nel seguente modo:

ipotesi: (i4)

abbiamo individuato l’indice $i=i@ a cui avveniva il cambio di segno di rpunto
abbiamo copiato lo stato attuale relativo al valore i@
anziché indicare r0=3.12E+26 come ci dava l’output abbiamo sostituito r0’=3.11999999999999E+26 metri (che il computer approssimava con 3.12E+26 in fase di output ma non nella fase di calcolo! poiché segnalava errore solo se gli davamo tale valore (3,12E26) come ingresso e non il software come output) che era il valore interno al BH+spessore della cupola di reverbero e quindi interno al raggio di Sch modificato con l’aggiunta dello spessore che restituisce 47 miliardi di anni luce come percorso totale(*)
(*)
(i 2 miliardi di anni luce vanno però aggiunti a 30 miliardi di anni luce, poiché l’origine è in S@1 e solo dopo altri 15 miliardi anni la luce arriva a noi. Il viaggio di andata da S@1 all’inizio dello specchio è 15+15 miliardi. Raggiunto lo specchio aggiungo 2 miliardi. Il viaggio di ritorno verso la nostra posizione è altri 15 miliardi. Il totale=15+15+2+15=47 miliardi di anni luce).

Più in dettaglio:

i@=786 764 207

e si veda (in fondo all’articolo attuale) il software sia come input che come output:

BH-7-3-2018-O-13-tris-last.php

In tale software si hanno le seguenti conferme:

—

1° conferma:

se io do ..
r0=3.11999999999999E26 in input

trovo in output ..
r0=3.12E26

ma il software non va in errore di “division by zero” perché usa due modalità diverse:
più precisa nel calcolo che usa r0
meno precisa nell’output.

—

2° conferma:

al punto di output i@=786 764 207
5=rpunto0=-53.002363085129
Nota Bene: “5” indica l’output numero “5” nelle tabelle seguenti di output.

che dimostra che prima che la particella raggiunga il limite di Sch come raggio .. ha cambiato il verso della velocità(si vede dal segno “meno”) che ora si riavvia a -53 metri al sec verso S@1.

—

3° conferma:

Poiché il software “last” realizza 100 output a partire da i@, (inizializzato correttamente lo stato predecessore dopo il cambio di verso della velocità) .. si vede dall’output .. la velocità aumentare in modulo e mantenere il segno “-“.

—

altre conferme?

basterà esaminare l’output della versione last:

BH-7-3-2018-O-13-tris-last.php (BHO-i)

—

sul sito wordpress avevo scritto una copia del software
link:
https://6viola.wordpress.com/2018/03/09/gausss-law-for-gravity-from-cmb-to-s1/

input del software BHO-i (fonte wordpress) (old):

—

input (software):

input del software BHO-i (fonte 6viola.it) (new):

—

output (software) BHO-i (new):

—

BHO-13:
da i= 750 a 800 milioni di iterazioni; ds=0.3E10;
ma si ferma all’indice i=786 764 216
lo stop è causato dal controllo di “kQ <0?”, a seguito della violazione:

stampa:
kQ(v) minore di zero<br />
k(786764216)=0<br />
i = 786764216<br />

nel prossimo software output un ulteriore controllo sul segno di rpunto mostrerà che la rpunto < 0 in un indice inferiore a quello attuale ..

https://6viola.it/wp-includes/doc-web/file-U1-out/BHO-13.pdf

—

BHO-13-tris:
da i= 750 a 800 milioni di iterazioni; ds=0.3E10;
ma si ferma all’indice i=786 764 207 < i=786 764 216 del predecessore (BHO-13)
lo stop è causato dal controllo di rpunto < 0 ?, a seguito della violazione:

https://6viola.it/wp-includes/doc-web/file-U1-out/BHO-13-tris.pdf

—

BHO-tris-last: (il software è impostato per stampare 100 valori che confermino il percorso all’indietro -verso S@1- della particella ai limiti di U1):
Nelle foto (foto-a & foto-b) seguenti solo i primi valori dell’output:

l’output relativo all’ultimo software BH-7-3-2018-O-13-tris-last.pdf:

(solo in formato foto)

foto-a: link

—

foto-b: link

—

in riferimento al data base “Gauss-Penta-i”:

Gauss-Ux1-22-2-2018-PENTA-1.pdf

Gauss-Ux1-22-2-2018-PENTA-2.pdf

Gauss-Ux1-22-2-2018-PENTA-3.pdf

Gauss-Ux1-22-2-2018-PENTA-4.pdf

Gauss-Ux1-22-2-2018-PENTA-5.pdf