Re: 1D PDE solver for Octave

[Bill Greene]

Yes, I've been aware that this pde1d implementation is slow.

Most users probably don't care about .25 vs .07 seconds but, if the

mesh is dense, as it often needs to be with these simple linear elements,

the execution time can be many minutes; not acceptable.

I'm assuming you are probably right that the oct interface has a faster

interface than mexCallMATLAB to call user-defined m-functions. I haven't

profiled the pde1d code but I'm 99% certain that is where the time is being spent.

I'll try to find time to experiment with the oct equivalent.

Writing the code in m has some obvious attractions and if the octave

implementation of ode15s was more mature I would consider that.

You may have noticed that my code currently relies on the Sundials

ida support for banded jacobians. I don't know if octave/ode15s is

planning to support that or even how it could. What I really need for

my planned, next-version of pde1d is support for general sparse

jacobians calculated efficiently by finite difference. MATLAB/ode15s

supports this but Sundials currently does not; so, at this point, implementing

it in octave/ode15s is moot. So I'm hoping that Sundials will improve their

sparse matrix support and I expect the best way to take advantage of that

is via their c-api.

Another alternative I have been considering is adding a 'Vectorized' option.

This would work similarly to the same-named option in the MATLAB ODE functions

in that the coefficients for all mesh points would be evaluated in a single

call to the user-defined function. This would obviously require some extra

effort by the users in coding their function.

All three of these options have significant disadvantages and it is definitely

not clear to me which is the least worst.

On Tue, Jul 5, 2016 at 2:49 PM, Carlo De Falco <address@hidden> wrote:

On 5 Jul 2016, at 20:32, Bill Greene <address@hidden> wrote:

> Regarding demo, I removed the non-working demo section from pde1d.m,
> created an "examples" directory, and put a single file "heatCond.m" in
> there.

I compared performance of your code to a solution of the same problem
with bim + daspk:

  >> tic, heatCond, toc
  warning: pde1d: User-defined initial conditions were changed to create a consistent solution to the equations at the initial time.
  Elapsed time is 1.26389 seconds.

  >> tic, mytest, toc
  Elapsed time is 1.05033 seconds.

on my system, though, most of the time is spent in producing the plot, so I tried
commenting out the plotting of the results in both examples, and I get:

  >> tic, heatCond, toc
  warning: pde1d: User-defined initial conditions were changed to create a consistent solution to the equations at the initial time.
  Elapsed time is 0.253297 seconds.

  >> tic, mytest, toc
  Elapsed time is 0.0677781 seconds.

This seems to confirm my previous knowledge that the mex interface is not very efficient.
If you don't want to learn Octave's C++ API, you might want to consider writing your code as
m-files. The benefits would be:

- simplify distribution and installation
- trivially solve issues with complex coefficients

I do agree that sundials is many respects superior to daspk and/or lsode so an option
to keep using that is to do so via the new implementation of ode15s instead ...

What do you think about this?

c.