Re: 1D PDE solver for Octave

[Carlo De Falco]

On 5 Jul 2016, at 21:55, Bill Greene <address@hidden> wrote:

> 
> 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.

I agree with most of your comments and, all considered, I think a mostly m-file
implementation of this function is the best way to go.

I would suggest to do an initial implementation based on lsode or daspk then 
move to ode15s when it is released.

Following this route all your building and installation problems will be 
immediately solved.

c.