Re: Maxwell's density function grinds Octave

[mavram]

On Sat, Aug 21, 2004 at 06:18:45PM +1000, Gad Abraham wrote:
> Hi,
> 
> I've been trying to plot Maxwell's speed distribution equation for ideal 
> gases on Octave, using the following code (adapted from a matlab script 
> on http://chemistryresources.tripod.com/physical/maxwell.txt):
> 
> function surf(varargin) mesh(varargin{:}); endfunction
> 
> M = 32e-3;
> R = 8.31451;
> 
> V = 0:1:2000;
> t = 273.15:1:1073.15;
> 
> [v, T] = meshgrid(V, t);
> 
> f = 4*pi*((M./(2*pi*R.*T)).^(3/2)).*(v.^2).*exp(-M.*(v.^2)./(2*R*T));
> 
> surf(v,T,f);
> 
> xlabel('v');
> ylabel('T');
> zlabel('f');
> 
> 
> The problem is that on my rather fast machine (AthlonXP2800, 768MB RAM), 
> this grinds away for almost 10 minutes, and the end result is a gnuplot 
> window with a only few tiny lines in it.
> 
> I'm using Octave2.1, gnuplot 4.0, on Debian Linux.
> 
> 
> Any advice?
> 
> 
> Thanks,
> Gad
> 
> -- 
> http://chookies.homeunix.org
> 
> 
> 
> -------------------------------------------------------------
> Octave is freely available under the terms of the GNU GPL.
> 
> Octave's home on the web:  http://www.octave.org
> How to fund new projects:  http://www.octave.org/funding.html
> Subscription information:  http://www.octave.org/archive.html
> -------------------------------------------------------------
> 
Dear Sir,
I was intrigued by your report. I never used 3D plotting in octave and I
think I'll need it in the near future.
In order to check the problem on my relatively slow machine (600 MHz
celeron with 320 Mb RAM), I did two things:
1-I split the function in two, one creating the v,T and f arrays and the
other performing the plot, and timed separatedly the two steps.
2-I checked how these times change when changing the size of the t
vectory, which I defined as t = 273.15:1:1073.15;, t = 273.15:10:1073.15; 
and t = 273.15:100:1073.15;, respectively.
The results are:
dt      1       10      100
t1      21.887s 0.886s  0.886s
t2      69.88s  7.8s    8.1s

There is no marked increase of the time with increased array size. In my
case, at least this does not cause swapping. Creating the arrays for the
plot takes a lot of time, but, assuming a my machine is slower than
yours by a factor of 4, this is nowhere near the values you reported.

Now, about the plot: In the case of the largest array, after a long
wait, I got an error message: "line 0 out of memory for extend dymarray"
and no plot.
I got no error messages (but no plot either) wiht the smaller arrays.
The number of lines of the temporary files created by octave in /tmp
were 1,604,805 164,085 and 20,013, respectively, which semms reasonable.

It seems that the problem lies with gnuplot (I am using gnuplot 3.8k
patchlevel 1), or, at least with that function in gnuplot, not with
octave itself.

I hope that someone more knowledgeable than me will be able to suggest
to overcome this problem, either in gnuplot or by piping the data to 
an alternative graphic package.
Cheers, Avraham



-------------------------------------------------------------
Octave is freely available under the terms of the GNU GPL.

Octave's home on the web:  http://www.octave.org
How to fund new projects:  http://www.octave.org/funding.html
Subscription information:  http://www.octave.org/archive.html
-------------------------------------------------------------