Fonte: Turtur, C. (2011). DFEM-Simulation of a Zero-point-energy Converter with realisable Dimensions and a Power-output in the Kilowatt-range. PHILICA.COM Article number 219.


1. Definizione del progetto

Una prova di principio l'utilizzo di punto-zero-energia è stato dato in [Tur 09].
Una conoscenza di base del fondamento fisico
come convertire punto-zero-energia è stato mostrato in [Tur 10a],
ma non è stato ancora possibile presentare un modello per una macchina con i parametri di realizzo...

Cioè ? Qualcuno mi può spiegare cosa serve pubblicare documentazione estesa se poi si VIOLA il fondamento principale della FISICA, che dice: "non esiste fisica se non tramite esperimento e poi descrizione matematica..."

Da cui SI CONGETTURA: è bello e fa bene: stimola!

Seconda cosa: nell'algoritmo DOVE è possibile fare studio sulle VARIAZIONI da portare per VERIFICARE... come dice questo documento... che io studio e quindi rifletto su di esso da giorni...

Terzo ed ultimo argomento: Turtur ha pubblicato da qualche anno... e questo è il suo documento più recente... indica che lui è professore, ma non è riuscito a trovare tempo per realizzare la macchina SUA... Come mai ?

Se ci sono problematiche - anche se Turtur afferma che i materiali per la costruzione sono reperibili in economia... dove sono i problemi di realizzazione ? e dov'è lo schema completo per esperire la macchina sperimentale di questo professore ?

Scusate, ma io ho dei limiti di comprensione sulla parte elettronica e matematica, ed ho 34 immagini grafiche di solo questo doc da digerire...

Secondo articolo DFEM tradotto

Ciao a tutti
Mi scuso per la latitanza, ma il lavoro mi ha fagocitato!
Vi metto in allegato il secondo articolo di Turtur, al solito tradotto e reso divulgativo al meglio delle mie capacità.
Vi invito a leggerlo integralmente ed a provare il codice sorgente inserito, è facilmente copiabile ed incollabile, un compilatore pascal lo trovate facilmente e gratis... Come? Attivare i neuroni, usare google ed il gioco è fatto... Mi capisci sorvolante?

Il bello di questo articolo è che l'algoritmo presentato è di base, di facile comprensione e sperimentabile praticamente.
Consiglio a tutti di iniziare da quì per avere una visione più completa delle intuizioni di Turtur, il successivo articolo affronta problematiche più complesse ed ho notato che seuendo questo articolo si spiegano molte scelte del più complesso algoritmo successivo, peraltro gia pubblicato in questo topic.

Ovviamente ho controllato tutti i calcoli a livello formale e sono convincenti, non ho avuto il tempo di controllare il codice sorgente, ma visto la semplicità non credo che Turtur abbia commesso errori formali di implementazione. Se qualcuno ha tempo e voglia il sorgente può anche essere trasformato in altro linguaggio più moderno, ammesso che serva! Attualmente non ho molto tempo libero ma farò del mio meglio per completare l'opera divulgativa, poi con calma mi dedicherò se possibile ad una sintesi dell'intero lavoro di Turtur e magari anche a qualche proposta sperimentale.
Invito tutti a valutare il fatto che il lavoro di comprensione e divulgazione, oltre al controllo teorico non è cosa semplice, tuttavia, vale la pena di approfondire il DFEM perchè è di certo la strada giusta per un realistico motore ad energia punto zero.

Sperando che il mio lavoro vi sia stato utile, vi saluto ed attendo i vostri commenti...

X sorvolante: se ti documenti meglio vedrai anche che Turtur ha realizzato un esperimento funzionante, e ti posso assicurare che la teoria presentata non vìola nessuna legge di fisica moderna ne di fisica classica, anzi la novità è che mette daccordo finalmente teorie a cui macavano riscontri oggettivi. Evita di fare considerazioni astratte e leggi meglio i documenti, sono in italiano e tradotti bene!

Credo di potere dimostrare che c'è errore in formula o programmazione.

Vengo e mi spiego....

Nel sito ufficiale di Turtur che è
http://www.ostfalia.de/export/sites/default/de/pws/turtur/FundE/Series-english.pdf

è scritto che...

phip[0]:=UmAn*2*pi

dove
pi è il famoso Pi greco che è 3,141592
UmAn è 100

quindi phip[0] dovrebbe circa 628


poi c'è scritto che
K3[0]:=1/2*J*Sqr(phip[0]);

J è il momento d'inerzia che dovrebbe essere 2,8344768 x 10^-4

questo valore è fornito dal programma che è stato gentilmente offerto da sandro_meg nel messaggio numero 29.

K3[0]=1/2*J*Sqr(phip[0])

K3[0]=1/2*2,8344768 x 10^-4*Sqr(628,31)

K3[0]=1/2*2,8344768 x 10^-4*25,066

K3[0]=1/2*2,8344768 x 10^-4*25,066

K3[0]=0,0035524498

ma nel file test_04.dat generato dal programma, K3[0] risulta essere 55,95032954904861

Forse c'è un problema di parentesi ?

cioè si dovrebbe fare...
K3[0]=1/ (2*2,83447685 x 10^-4*25,066)

ma anche cosi' viene 70,37
e 70,37 è diverso da 55,95032954904861

quindi arrivati a questo punto non so cosa pensare...

Volevo convertire tutto in java, ma se le equazioni sono sbagliate in partenza, cosa serve che vado avanti ?

Qualcuno mi risolva questo problema, altrimenti abbandono la cosa.

Mi dispiace ma Sqr non vuol dire radice quadrata come hai erroneamente interpretato ma bensi' elevato al quadrato.
Per la radice quadrata si usa Sqrt (come puoi vedere in altri calcoli dell'algoritmo)
Inoltre, per chi usa linux, e' stato fatto un programma in Perl sempre disponibile su Yahoo (Yahoo! Groups )
Poiche' hanno variato l'algoritmo originale di Turtur,io l'ho rimodificato per avere dei valori identici a quello originale. perl_turturmo.zip
Buon divertimento.

x Giorep

Grazie della traduzione, appena posso lo leggo

Corretta interpretazione...

Prego! Troverai interessanti alcuni passaggi, in particolare sul come è nato il codice del DFEM, a mio parere il sorgente riportato è utile perchè facilmente comprensibile, e spiega meglio il metodo di implementazione dei calcoli adottato da Turtur.

Come promesso continuerò con le traduzioni ed implementazioni!

Ciao

Ho letto ed archiviato... lo rileggerò per settimane... un ottimo studio multidisciplinare... piuttosto difficile... le mie considerazioni però non ci sono... me ne guardo bene di astrarre in materie che non conosco bene... ho riportato il dire suo e poi ho domandato tre cose... Bene, ora il codice c'è... il tuo secondo documento è utile... c'è divulgazione dettagliata... ma non divulgazione per tutti... a quella penso io... dopo che capisco questa macchina... che deve ricevere i parametri... da chi li sa modellare...

Mi sembra di avere capito che occorre una oscillazione in verticale... ovviamente altre decine di frasi da passare in discussione ma fate voi... questo doc riempie la settimana...

Mi permetto di porre in discussione questo:

...organizzare il movimento dei corpi (di Fig.1) in modo ingegnoso...
possiamo ottenere che oscillino relativamente a vicenda, (a causa del loro collegamento a molla elicoidale) in modo che abbiano una ridotta forza di Coulomb nel corso degli intervalli di tempo, quando aumentano loro distanza reciprocamente, mentre "sentono" un’aumentata forza di Coulomb nel corso di tempo, quando diminuiscono la distanza reciprocamente...

N.B. ho preso dal doc. (copy an paste). Come traduttò poi in pratica? Se mi metto a fare esperienze di meccanica... in verticale dovrei portare in alto mediante attrazione e poi rilasciare questo corpo in alto? mentre in basso, dovrei fare repulsione e poi mandarla in attenuazione durante il "ritorno giù del corpo basso"? ... e fare pulsare la meccanica che è aiutata dalla molla?... io comincio a vedere la parte magnetomeccanica... ternetemi instradato... Ciao.

P.S. sto compilando i DUE codici... sono bacati... ho scaricato il DEV-Pascal (GNU)
Nel codice.1 tradotto forse da sandro-meg, le "accento delle stringhe" fanno a pugni con la sintassi del Pascal... che non conosco molto bene, ma è simile al C... e vedo ora se me lo compilerà e manderà in output... pure questo, uffa!

Il disegno in figura 1 è chiaro... Una molla due corpi ed un vincolo al centro della molla. Il tutto disposto in orizzontale, mi sembra semplice da capire! Da dove hai dedotto che si metteva il tutto in verticale?
OK! Cerco di essere più chiaro...
Se leggi bene tutto il doc, capisci che il moto deve raggiungere un'oscillazione armonica entro parametri ben precisi, altrimenti niente energia punto zero dal vuoto quantistico, tale oscillazione deve rientrare in tempi, ampiezze, e forze dei campi precise e calcolate dal programma... per questo è stato messo a punto un programma, altrimenti con le prove sperimentali potresti anche passare tre vite senza ottenere niente!!!
Prima di passare alla "meccanica del sistema" è meglio approfondire lo studio teorico...
Ciao
Per il pascal ti consiglio di installare questo: http://www.bloodshed.net/devpascal.html e questo: http://www.freepascal.org/ uno è l'ambinete di sviluppo e l'altro è l'interprete... Vedrai che il codice pubblicato da Sandro ed anche quello di turtur originale, ma anche quello pubblicato sul mio doc, vengono compilati senza problemi...

Prime difficoltà superabili

Pag.3 di 24: ..."La molla va immaginata verticalmente collegante i corpi n. 1 e 2... Ovviamente l'oscillazione non è armonica"...

Puoi spiegarmi ciò ?

Intanto assumo il modello di macchina orizzontale... so bene che i parametri ci vogliono e tramite la osservazione del codice e info farò in fretta... intanto uso questo DEV-Pascal 1.9.2 e sto a farlo girare su posizione disco a stringa più corta che si può... ad es. path = V:\

Dunque il debug del sorgente inizia per me con questo:

{$APPTYPE CONSOLE}
uses
Windows, Messages, SysUtils, Classes, Graphics, Controls, Forms, Dialogs;

Il compilatore mi dice di togliere... e fare rimanere così:

Windows, SysUtils ;

Successivamente si impianta sulle apostrofi...
che la sintassi usa come delimitatori di stringhe di messaggio d'interfaccia...

Infine, la compilazione+linker produce un eseguibile non a posto... per via che sfugge... attivando la finestra DOS ed eseguendo a riga di comando però ci siamo anche così... abbiamo l'elaborazione delocabile in casa mia... è chiaro che si dovrà manipolare il compilatore per fargli fare il programma DOS per Windows... eccetera...

Ecco il mio default di elaborazione sul codice elaborato a trascrizione di messaggistica di interfaccia in italiano (Codice1)... si basa o genera il file test_04.dat ... ?

Ecco il mio default (e da domani, a ritroso sulle info e tra le formule...)

V:\>Codice1.exe
Valori del dispositivo ZPE.
Velocita della luce c = 2.997924580105028E+008 m/s
Induttanza della bobina: L = 2.605762610593518E+000 Henry
Frequenza oscillatore= 1291.7208 Hz => T = 4.8641976E-003sec.
Lunghezza filo della bobina: 9.0477868423386042E+0002 m
Resistenza filo della bobina: R = 19.58 Ohm
Massa inerziale del magnete: mt = 3.727122692365859E-001 kg
Momento di inerzia del magnete: J = 2.834476807544236E-004 kg*m^2
Durata della osservazione: 1.0000000000000000E+0000 sec.
Dati sulla risonanza elettrica e meccanica.
valore energia meccabica:
E_inizio = ( 55.9381347 +/- 0.0037039) Joule
E_fine = (682.9811784 +/- 3.5114743) Joule
=> variazione energia : delta_E = (627.0430436 +/- 3.5114763) Joule
=> potenza meccanica generata = (627.0430436 +/- 3.5114763) Watt
pot.generata sulla Resitenza Rlast = 1070.4163786 Watt

Ciao.

Si tratta di esempio atto a dimostrare la necessità di una dinamica da applicare al calcolo FEM classico... Basta leggere il periodo successivo.

Hai fatto "un caciucco" con il codice sorgente...
Devi usare il compilatore ed il sistemoa di sviluppo che ti ho suggerito, poi il file parameter.dat lo modifichi con un semplice editor di testo (ti consiglio notepad++)... Non puoi modificare a piacere il codice ed il file parametri NON HA SENSO!!!

Dammi retta per una volta... studiati i due documenti e leggili più volte, approfondisci e poi sarai gratificato dalle sperimentazioni, quello che fai ti fa solo perdere tempo, arrancado a destra e manca senza un preciso ordine non ottieni niente!

D'accordo, come ho detto le fonti le rileggo... e da questa mattina penso allo schema orizzontale...

Devi divulgare dal tuo ultimo doc la faccenda della oscillazione del sistema... immagina di doverlo costruire... anche per giocare (senza parametri ok, solo provare la meccanica... e i imagneti...) cosa vedi nella tua immaginazione ?

Per la compilazione ed esecuzione, con il Codice1 ci sono, mentre con il COPIATO ed INCOLLATO del pezzo di contributo ultimo tuo ci sono errori... risolvibili... da TE... (e da me con analisi comparata e studio svelto di questi 2 codici...) Insomma: no caciucchi, ma inserimento da fonte in ambiente di programmazione Pascal... io non creo confusione, ma cerco di capire... e se i documenti si estendono a trenta e più pagine di fonti è chiaro che ci sono da capire i paragrafi, ed il senso di tutta la fonte dati...) io oggi tento di risolvere il codice2 bacato...

E PROVATE anche voi ad esempio a fare interfaccia di stringa per il DOS in Pascal, scrivendo ad esempio:

Writeln('L'Oscillatore in DFEM con OVER-UNITY:');

VEDETE le due apostrofi?
la prima che apre la stringa, e la seconda che intoppa la compilazione?...
[Attenzione a tradurre in italiano...]

Il baco da aggiustare per il Codice2 è il seguente:

{ The first function is the Position of particle No. 1:}
Str(x1[i]:10:5,Zahl);

58 / 27 codice2.pas
Error: Integer or real expression expected!


Ciao.

1° sorgente DFEM

Ad uso di tutti coloro che vorranno cimentarsi, allego il file con il sorgente del primo programma DFEM di Turtur, quello postato nel documento potrebbe creare problemi dovuti al copia&incolla.
Così anche sorvolante avrà un originale su cui lavorare!!!

Appena ho tempo metto mani ad un successivo documento, che descriverà nel dettaglio un setup pratico per una macchina a z.p.e.

Un saluto a tutti

Note per il codice più recente

Ciao.

FONTE: http://www.ostfalia.de/cms/de/pws/tu.../Var_L_025.dpr

che è il codice newest (...il più recente... a detta del sito...)

Copiato e incollato nell'editor ASCII più giusto: Textpad (ottimo per scrivere...)

Quindi ho distribuito il codice senza indentarlo, solo suddividendolo... e salvandolo...
come [ codex.pas ] che sta insieme al [parameter.dat] di default...
(tutto in minuscolo e senza andare oltre il vecchio limite di 8 caratteri.3 per l'estensione)
il risultato sintattico è OK... si forma l'eseguibile...

Per il controllo di output, io faccio le prove di confronto con l'eseguibile originale, scaricato... cioè il file: [ Var_L_025.exe ]

Per il controllo semantico scientifico pensateci voi... che siete più dentro questa cultura.

Note per il newest:

Per il file [ 1° sorgente DFEM.txt ]
copiato, incollato e salvato nell'editor Pascal, si ripetono gli errori...

Che sia da provare il Turbo Pascal... oppure metterci le mani a rivederlo...
ecco la info del software:

Free Pascal Compiler version 1.0.6 [2002/04/23] for i386
Copyright (c) 1993-2002 by Florian Klaempfl
Target OS: Win32 for i386
Compiling t:\codex.pas
codex.pas(60,27) Error: Integer or real expression expected
codex.pas(68,27) Error: Integer or real expression expected
codex.pas(76,27) Error: Integer or real expression expected
codex.pas(84,27) Error: Integer or real expression expected
codex.pas(273) Fatal: Unexpected end of file

Che differenze ci sono dal codice vecchio a quello nuovo ?

(...io le capirò bene tra qualche settimana...)

Ciao.

questo è il sorgente in java.

Giorep, ieri ho lottato con il codice1,
quello nel file: Esempio di un semplice algoritmo DFEM.doc
l'ho suddiviso a paragrafi con il controllare e ricontrollare le fasi di programma...
questa attività non include lo studio della matematica interpretata in Pascal (o in qualsiasi altro linguaggio di progammazione) ma solo sul fare in modo che il compilatore svolga la sua analisi sintattica... il Dev-Pascal non ce la fa... oppure io...

La compilazione si blocca per errori sulla chiamata delle variabili di array...

Str(x1[i]:10:5,Zahl);

Error: Integer or real expression expected!

E pure per la fine del codice... Fatal: Unexpected end of file!

anche se io penso che le due scritture siano giuste...
per cui provo a vedere in altri ambienti software... e i file di uforobot...

A me sembra che il codice1 sia particolare per qualcosa da capire poi... cioè fare variazioni, rimodellarlo... e che per l'output di programma sia obsoleto rispetto a quello più recente, codice2 che è quello anche tradotto da sandro-meg, ed è quello che è reso eseguibile da fonte web, cioè il file: Var_L_025.exe

Questi eseguibili (tranne quello di codice1) producono circa stessi output...
ho notato qualche variazione di dato per la fine di parti decimali o esponenziali...

Dunque la base di elaborazione per i parametri è il codice2,
che prende sempre l'input dal file parameter.dat
e manda in output l'interfaccia di calcolo numerico e poi il file test_04.dat .

Ho provato le oscillazioni random sulla solita mia macchinetta di studio... che conosco... e non richiede alcun calcolo, solo meccanica di fare interazioni... le oscillazioni sono davvero interessanti e vorrei saperne di più... per questo tema e per le mie ricerche.

Oggi cerco di farmi un'idea delle fonti sparse sul web di questo professore Turtur,
e ovviamente rileggere i file scaricati da questa discussione.

Ciao.

Ho fatto girare il tuo java... sicuramente più attuale e gestibile del pascal (old style).
Ottimo lavoro... Complimenti!
I primi risultati appaiono in linea con le aspettative teoriche, non ho avuto tempo per approfondire il codice java che hai implementato, ma sono certo che i calcoli siano rispettati, visto che i risultati sono in linea con lo stesso codice in pascal.
Direi che il gioco di squadra sta dando dei frutti!
Che ne dici di "javizzare" anche il primo codice di turtur che ho allegato? E' un semplice algo, ma trovo interessante la tipologoa di implementazione basilare che potrebbe servire agli sperimentatori.
Inoltre sto traducendo anche l'articolo di turtur sulle sue idee per un setup di utilizzo pratico, che mi sembra interessante, ovviamente anche in questo vi è lo sviluppo del relativo codice...
Mi sembra che il lavoro di comunicazione stia generando dei buoni frutti! O no?

Ciao a tutti.
x sorvolante...
ti ho già detto che è meglio usare l'ide Bloodshed Software - Dev-Pascal ed il compilatore Free Pascal - Advanced open source Pascal compiler for Pascal and Object Pascal - Home Page
Lascia perdere il dev pascal... Segui le procedure, che è meglio!
Il java di uforobot è ottimo, ti scarichi il java Download gratuito del software Java e avvii il file allegato con l'estensione .jar
...//...

risolto bugs del codice1

Sto usando il Bloodshed Software - Dev-Pascal...
e finalmente ho risolto anche questo STALLO... cioè errore di compilazione e non procedura di esecuzione... dovuto dal codice1 (2010 penso... in cui Turtur esplorava le sue idee, prima di formarle meglio nel codice2 ... uforobot penso che ha javizzato il codice2... OK ?)

Il codice1 è più di ricerca iniziale... e chissà... a lanciarlo andava in "perpetual", distribuendo dati senza posa... un trucco è di fare in modo di selezionare al volo... e quindi potere bloccare... ma non si ha l'history dei dati da inizio... allora: ho tolto il blocco di codice corrispondente ad un ragionamento implementato in codice... ora te lo do riveduto... in modo che lo rileggete... e sistemate semanticamente... e poi se si fa in java ancora meglio... Dunque nested comments, qualcosa per cui si devono togliere tutti i commenti e poi fare undo... compila, poi undo ancora sino a capire circa il punto di blocco... che incideva sull' End.

Inoltre, gli errori venivano dati dal porre: x1,x2,v1,v2 : Array [0..200000] of Real48;
invece di metterci un [of Double]... o qualcosa d'altro... si vedrà... io avevo fato esperienze di linguaggio C ... Matematica Discreta tratta di linguaggi di informatica ? vabbé...

Insomma, per me questo codice1 è da variare a piacimento... sapendo però come programmare per queste ed altre ricerche... in effetti sto osservando mie ricerche che perturbano il rotore... che avvengono scatti, guizzi, effetti strani dati ANCHE ora che ho provato... da indurre oscillazione... senza che lo statore compia i giri... mai visto cose strane appunto OSCILLANDO... appena trovo gli ingranaggi si vedrà... se molle o altra meccanica appunto interagente con queste ricerche fanno uscire lo ZPE... hai visto il filmato di turtur con la pentola riempita d'acqua e la tolla tagliata in due... ed elettronica... da dare o prendere... 2Kw ... se l'avessi io mi salta il contatore di casa per overflow di consumo interno...

ora a voi davvero il testimone... lavorateci su mentre io studio i documenti di Fisica, di Turtur e degli altri ricercatori...

questo è l'output di default, come è ora il codice1 che fa uscire i dati non ordinati... uno in fila all'altro... pnso che va a capo il DOS (auto carriage return).

Oscillator in DFEM with OVER-UNITY:
epo = 8.854187817000E-012;
muo = 1.256637061436E-006;
c = 2.997924580105E+008
m1,m2 = 1.0000000E+000, 1.0000000E+000;
D = 0.0000000E+000

El.-force: 6.286462600188775E-002
and -6.286462600188775E-002 Newton

Spring-force: 3.200000000000000E-001
and -3.200000000000000E-001 Newton

Part 2 is ready.

reversal-point: 3.000000 m

El.-force: 8.987551787997911E-001
and -8.987551787997911E-001 Newton

spring-force:
-5.400000000000000E+000
and 5.400000000000000E+000 Newton

enhancement of the amplitude: 0.000000 Meter.

The machine-power is 7.4073582603531201E+0002 Watt.

Ciao.

Sono lusingato!
grazie !
probabilmente hai già intuito che sono un amante della programmazione java.

Per quanto riguarda di javizzare il primo codice di turtur che avevi allegato, se ne parla fra una settimana o 10 giorni, perché in questi giorni sono molto impeganto a fare altre cose, e poi vorrei prima dedicare del tempo per capire il principio fisico che Turtur sta proponendo, il quale ancora non ho capito bene.

"...vorrei prima dedicare del tempo per capire il principio fisico che Turtur sta proponendo, il quale ancora non ho capito bene..."

Anch'io. Ma credo che sia solo "fisica teorica" pura, cioè fantascienza.

Conversion of Vacuum-Energy into Mechanical Energy

Ciao a tutti... penso che Turtur abbia iniziato a divulgare più o meno da questo pdf del 2008, tre anni da questo ultimo codice... che java elegante (il codice ed anche l'interfaccia amichevole)... i miei complimenti a uforobot...

il codice1 manda in output due files di dati... esaminatelo prima che si può... potrebbe dare informazioni per compiere personalmente i percorsi che si riflettono sulla attività di questo ricercatore... e inoltre esperimenti di variazione del codice...

Maxwelliano, (e per tutti) esiste da fonti di Free-Energy molta letteratura, che io non riesco per ora a comprendere... a quanto sembra da queste fonti, e da questo PDF, l'idea iniziale è di cercare lo ZPE mediante effetti di elettrostatica... che io non desidero replicare... però il software ANSYS lo cita... tu ti fidi del virtuale ?

PDF di solo 4 pagine, e in fondo i riferimenti, però include foto di un suo esperimento... quindi e un ricercatore che ci prova... essendo professore saprà quello che combina... ora tende a usare i magneti permanenti...

Conversion of the zero-point energy of the vacuum
che pare un portale su tutte o quasi info ed esperimenti di Turtur...
il primo link è proprio quello della pentola d'acqua, eccetera...
YouTube - Turtur Zero Point Energy Rotor

Ciao.

"...tu ti fidi del virtuale ?..."

appunto!

Il virtuale è FINZIONE. E quindi per finta si ricava tutto... come con la lampada di Aladino!

Come immaginavo è pura fantascienza...

Il mio padrino Mirko era convinto del moto perpetuo, e tutta la sua lunga vita - passata nelle Officine Vidali Pietro fu Angelo - nei suoi brevi momenti di "ozio", progettava macchine ingegnosissime per sfruttarla...

Chiedo scusa, ma nella versione 1.00 c'era un piccolissimo errore in formula.

Adesso lo messo a posto, questa è la versione 1.01

Virtualizzare Scienza e Tecnica

Intendevo dire il virtual delle applicazioni di SIMULAZIONE ... cerca COMSOL ... c'è quasi tutto per l'ingegneria... COMSOL include anche software per il magnetismo... ma ovviamente quello classico, elettromagnetismo... per le mie ricerche la descrizione è importante... per queste di Turtur INDISPENSABILE.

Per il codice.1 [che cerca... cosa? me lo divulgherete voi...] lo sto sistemando in Pascal, come da fonte... e capendo le fasi del programma (ci vorrebbe un software Pascal che proceda a fare debug step-by-step... come il vecchio Basic...) anche senza steppper si può capire qualcosa in più... e sono al giorno 3 (serata...) di software... ma non la semantica... per quella ci volete voi...

Io non sono convinto del moto perpetuo... lo studio con i magneti permanenti... tutto qui... ho solo neanche un mese di esperienze, calcolando le ore trascorse da circa 6 mesi... Non sono più quello di prima... perché anche studio le materie scientifiche...

Sto pensando alle molle... LE MOLLE da usare per questo tema che tipo sono ?

Dato che ho ripreso passioni antiche... anche questa sera niente... tranne rivedere e sistemare il codice.1 che allego come sistemato, commentato dove occorre la sintassi e a voi ancora la semantica da aggiungere... su qualche DOC come i precedenti... il file di progetto e del compilatore che uso e che mi piace... NON HA LO HELP della sintassi... ma basta scrivere in browser web che si trova info... i software aprono la mente... danno continuamente problemi... e quando si trova l'equilibrio è più bello... non si fa più debug ma miglioramenti continui...

Questo eseguibile genera due file su disco:
XLS-Nr-02.DAT , XV-03.DAT

Per Giorep, uforobot, e per tutti coloro che capiscono questa semantica... buona analisi di questi dati di default... di Claus W. Turtur...

Ciao.

Ho guardato il filmato della conferenza di Turtur...sono rimasto stupito della sua spiegazione del fenomeno che verifico giornalmente (da un mese circa): cioè che i campi elettrico e magnetico modificano la lunghezza d'onda!
Credevo di essere il primo ad averlo scoperto e invece è lui.

Quindi mi sto ricredendo. Resta il fatto che le energie in gioco sono di nanojoule...
Probabilmente saranno alla base della vita...? Interrogativo. Da dove trae energia un seme per germogliare e per sbucare dal terreno?
Credevo che fosse la fusione fredda... ed invece potrebbe essere quella del ...vuoto! (Perchè vuoto non capisco, dovrebbe essere anche nel "pieno": fra atomo ed atomo c'è il...vuoto, no?)

Sono domande a cui tanti hanno cercato di dare risposta...
Mi viene in mente il pazzo di Reich e l'altro pazzo di Flanagan...

Io sono un po' ignorante. Cosa significa modificare la lunghezza d'onda? Lunghezza d'onda di cosa?

Note di Moderazione: Attenzione a non citare un msg integralmente !! 3d) Le citazioni devono riportare solo parti significative del messaggio alle quali si vuole aggiungere un commento/chiarimento. Citazioni integrali o comunque di evidente inutilità (specialmente tra messaggi consecutivi) non sono tollerate e comportano provvedimenti.

"...Io sono un po' ignorante. Cosa significa modificare la lunghezza d'onda? Lunghezza d'onda di cosa?..."

siamo tutti ignoranti della Natura, che qualcuno addirittura nega.
La lunghezza d'onda elettromagnetica, ovvio: dalle radioonde ai raggi millikan.

Questa è l'elaborazione dell'algoritmo di Turtur in chiave software da parte di un membro di overunity.org
Ready-To-Use Software for Prof. Turturs Free Energy by Magnet Rotation

Magari può tornare utile anche questa

chiedo aiuto

Prima di tutto chiedo umilmente scusa del sarcasmo che, ignorando del tutto l'argomento, posso aver messo nei miei precedenti post. Era arroganza di un ignorante. (vanno sempre a bracetto!).

Chiedo a voi che avete letto Turtur :

1-in quale passaggio viene descritta la variazione di lunghezza d'onda per effetto dei campi magnetico ed elettrico, e magari anche gravitazionale?

2- è stata sperimentata quella variazione o è solo una sua previsione teorica?

3- se ha dimostrato sperimentalmente , per piacere, mi sapete indicare dove è la descrizione?
Se risulta che è solo una previsione virtuale, allora ... tanto di cappello!Ringrazio e mi riscuso.

A me mancano le basi matematiche per seguire Turtur, ma sto facendo l'esperimento che dimostra il suo assunto...

Maxwelliano puoi leggerti il primo doc tradotto da Giorep ,al quarto paragrafo c'e' una piccola parte che a te interessa.

Veniamo a Turtur.... allora il discorso di Turtur non e' 'nuovo' anche se ha fornito un software che dovrebbe permettere di risolvere i problemi che hanno tutti quelli che sono interessati alle macchine zpe .
Il problema e' che l'algoritmo implementato nel codice non funziona e' questo e' un fatto. Ora anche se il discorso di Turtur fila e riusciamo a trovare il baco ( e sono sicuro che lo si possa trovare facilmente per chi ha fatto analisi matematica ), il discorso di replicabilita' di un dispositivo che possa essere OU la vedo molto difficile per un hobbysta.
La perfezione di realizzazione deve essere non accurata.... ,di piu'..... qualsiasi piccola tolleranza pregiudica il funzionamento del dispositivo.
Si sta parlando di sfruttare differenze di velocita' di una scala enorme rispetto alle dimensioni del dispositivo (velocita comparabili a quella della luce su oggetti di pochi cm), si puo' fare ma....non e' semplice.
L'esperienza fatta sul MEG mi suggerisce che la strada intrapresa da Turtur sia quella giusta ma ancora non disponibile....forse basta poco ma non saprei metterci le mani su quelle equazioni.
Giorep non pensi che Turtur abbia sbagliato i calcoli (oltre che il software) nel suo dispositivo da 1,07 Kw ?

Tutti sappiamo che l'elettromagnetismo classico NON vale nei limiti del "troppo piccolo" e della carica "troppo piccola". Inoltre sappiamo pure che l'elettrone non ha una dimensione geometrica ben definita. Ergo, applicare la formula per il calcolo dell'energia elettrostatica alla "superficie" dell'elettrone (formula n° 3) prendendo come suo raggio il cosiddetto raggio classico è un puro esercizio matematico privo però di significato fisico.