RamView Bug

Ma non stara' mica per caso cercando di fare le mappe usando il programma esterno Surfer della Golden Software, senza averlo installato ????
Il tipo di messaggio di errore indica che il programma active-X chiamante (Ramsete View) non e' riuscito a lanciare il programma "oggetto" (Surfer)... La spiegazione piu' ovvia e' che Surfer non sia stato installato correttamente...
Prima di mettersi a pistolazzare con strani settaggi di Windows, secondo me e' meglio sempre pensare alla soluzione piu' semplice.
Poi magari il problema non e' questo, e deriva dalla strana configurazione software della macchina (Windows 7 a 64 bit e' in effetti una scelta che puo' portare ad alcuni problemi di compatibilita').
A questo proposito, quale versione di Surfer sta usando? Perche' per il controllo remoto tramite il protocollo Active-X da parte di un altro programma, sotto Windows 7, occorre, che io sappia, avere perlomeno la versione 8.0 di Surfer, con la 7.0 non funziona...


All'aperto, in generale, occorrono molte piu' piramidi che all'interno, in quanto, allontanandosi molto dalla sorgente, esse tendono a diventare troppo grosse per "risolvere" correttamente la geometria degli ostacoli. Come regola del pollice, si deve usare un numero di pramidi tale per cui, alla distanza massima di calcolo, la base della piramide non sia mai piu' di m 2x2. Se quindi faccio un calcolo in esterno sino alla distanza di 100m, occorre un numero di piramidi dato da:

4*pi*100^2/4 = 31400, cioe' 2^15, da cui Level = 12

Hiostory va sempre OFF, sempre!

E Randomize After va a meno di cinque ordini di riflessione , non va mai messo Off, se no la riflessione diventa speculare, cosa che all'aperto non e' MAI vera....
Random=off serve solo se uno vuol simulare una "Camera degli specchi", cioe' un parallelepiopedo rettangolare liscio e perfettamente in squadro, volendo appunto mettere in luce il fenomeno del "flutter echo" che si crea in tali condizioni. A parte questo caso particolarissimo, Random non va mai messo a piu' di quattro ordini di riflessione, e spesso e' prudente impostarlo ad uno o due, soprattutto in sterno, dove sovente la riflessione e' randomizzata gia' dopo il primo rimbalzo...
Random=off significa ordine infinito per le riflessioni speculari, non ha senso, il suono diventa sempre diffuso dopo alcune riflessioni...

Eh si', sicuramente l'installazione di Surfer 9 ha "interrotto" il canale di comunicazione Active-X fra Ramsete e Surfer 8....
La tecnologia Active-X e' potente, consentendo la "collaborazione" di programmi diversi, ma e' tutt'altro che stabile e ben documentata. E quando ci sono dei problemi, l'Active-X engine genera dei messaggi d'errore di ben difficile interpretazione. Come al solito' e' la Microsoft che va biasimata per questo...
Certamente Windows 7 e' un considerevole passo avanti in termini sia di stabilita', che di compatibilita', rispetto a Vista.
E' la scelta della versione a 64 bits che mi lascia leggermente perplesso. Nei benchmarking fatti qui all'Universita', esso risulta di un bel 20% piu' lento della versione a 32 bits (ovviamente lanciando applicazioni a 32 bits, e su macchine che hanno 4Gb di RAM o meno).
Ed ha avuto grossi problemi di compatibilita' hardware, ad esempio non ci funziona con i driver delle schede audio Firewire professionali (motu, M-audio, RME, etc.), ne' con alcuni probgrammi di interfaccia con gli analizzatori di spettro...
Non parliamo delle chiavi hardware che, come avete sperimentato anche voi, hanno dei grossi problemi...
I vantaggi di un S.operativo a 64 bits si apprezzano solo usando applicazioni "native" a 64 bits (al momento sotto Windows non ne posseggo alcuna), ed ovviamente solo se si hanno piu' di 4 Gb di RAM fisica installata, e se si disattiva il sistema di paginazione su disco di Windows.....
Sono condizioni abbastanza poco frequenti, per cui qui abbiamo deciso per il momento di preferire Windows 7 a 32 bits, che funziona veramente bene...
Certo che Ramsete III verra' sviluppato come applicazione nativa a 64 bit, multithred e multicore (e multipiattaforma, girera' nativamente anche sotto Mac OSX e Linux), e quindi trarra' vantaggio dai nuovi s.operativi a 64 bits. Ma passera' ancora circa un anno prima che sia disponibile, e lo stesso secondo me accadra' anche per tutti gli altri programmi. Prevedo che l'anno dell massiccio passaggio ai 64 bits sara' il 2012, non prima...

Con Labiew possono esserci problemi se le schede acquisizioni dati o le periferiche da interfacciare non sono dotate di specifici drivers a 64 bits. I drivers a 32 bits girano entro una "shell" di emulazione, che ne penalizza la performance, per cui puo' crearsi un "collo di bottiglia" che impedisce di fatto di raggiungere la massima velocita' di campionamento da parte di schede multicanale, etc...
E' comunque un problema temporaneo, pressati dalle richieste degli utenti i produttori di hardware si stanno adeguando, rilasciando i drivers nativi a 64 bits per i loro prodotti.
Comunque avere piu' RAM aiuta sempre, avendo un s.op. che li sfrutta io non esiterei un attimo a passare a 8 Gb, o addirittura, potendoselo permettere, a 16 Gb... Immagino come andrebbro con tale memoria progarmmi quali COmsol o Matlab, che ne sono estremamemnte avidi...
Dopo aver espanso la memoria, si puo' tranquillamente disattivare la "memoria virtuale", eliminando il file di paginazione su disco, cosa che velocizza parecchio anche la funzionalita' del disco fisso.
In sostanza, vedo bene il futuro dei 64 bits per macchine dedicate al calcolo, con almeno 16Gb di RAM, nessun file di paginazione, e grossi programmi di elaborazione del segnale, delle immagini, o solutori agli elementi finiti.
Mentre ritengo che per un computer "da laboratorio", che si deve interfacciare a perifiche di ogni tipo, sia tuttora da preferire un sistema a 32 bit, con la conseguente limitazione a soli 4Gb di RAM...
Per quanto riguarda Ramsete, allo stato attuale non vi e' alcun vantaggio nell'uso di un s.op. a 64 bits, ne' di un processore Multicore. Ma questo e' destinato a cambiare nel prossimo futuro...