Re: Working on bvp4c

[Bill Greene]

I have recently added the calculation of the residual error and the

capability to adaptively refine the mesh based on this error measure.

I believe that now my code basically corresponds to the algorithm described

in the Kierzenka/Shampine paper.

If there is someone out there who has some experience with the bvp4c function,

has access to MATLAB, and could do some comparisons between bvp4c and this code,

I would be much-obliged.

The source code is here: https://github.com/wgreene310/bvp1d.

If you look at "Release 1" on this page, there are prebuilt binaries

for Octave 4.0 on windows, macos, and linux. Alternatively, the Makefile I used to build

the code for these three platforms is also included with the source code.

(I happen to call the function bvp1d to distinguish it from bvp4c but the

intent is that is closely corresponds to bvp4c.)

Thanks.

Bill Greene

On Tue, Aug 23, 2016 at 5:29 AM, lakerluke <address@hidden> wrote:

Maybe I've misunderstood this but from page 6, f_{i - 1/2} is given by odefun
evaluated at the point (*):

[ (x_{i - 1} + h/2) , 0.5*(y_{i - 1} + y_{i}) - (h / 8) * (f_{ i } - f_{ i -
1}) ]

However,in order to evalue f at this point requires us to know how to
evaluate the components of f at x = (x_{i - 1} + h/2), which we do not know.

Take for example demo 1 given here:

http://octave.sourceforge.net/odepkg/function/bvp4c.html

f = @(t,u) [ u(2); -abs(u(1)) ];

Seeing as u is a function of t, in order to evaluate f at (*) do we not need
to know u as a function of t (e.g. the solution) in order to evaluate it?
Or, seeing as in this example, f does not explicitly depend on t, do we just
evaluate the u components of f at the second component of the point (*) -
effectively treating f = f(u)?

I hope this makes sense. My point essentially comes down to my
interpretation of evaluating f at the point (*). I would think that in order
to do this we must know the solution, u(t), in order to evaluate u at point
(x_{i - 1} + h/2).


Bill Greene-3 wrote
> Not sure what you mean by "_expression_". Implementation-wise,
> f(...) means call the user's odefun with the arguments in ().
> So that is what the code does with the last two equations of page 6.
> Similarly, g(...) means call the user's bcfun.
>
> Bill
>
> On Mon, Aug 22, 2016 at 12:33 PM, lakerluke <

> luke_purnell@

> >
> wrote:
>
>> The last equation on page 6 gives f_{i - 1/2} in terms of f evaluated at
>> x_{i
>> - 1} + h/2 .
>>
>> Does this not mean that we need an _expression_ for f evaluated at this mid
>> way point between mesh-values?
>>
>>
>>
>> --
>> View this message in context: http://octave.1599824.n4.
>> nabble.com/Working-on-bvp4c-tp4677540p4679405.html
>> Sent from the Octave - Maintainers mailing list archive at Nabble.com.
>>
>>





--
View this message in context: http://octave.1599824.n4.nabble.com/Working-on-bvp4c-tp4677540p4679432.html

Sent from the Octave - Maintainers mailing list archive at Nabble.com.