Re: two points BVP

[John Salvatier]

(please cc the email list in the future, so others can benefit from your question). 

I'm not sure why this might be so, but I think the BVP_SOLVER author, Paul Muir, might have some insight, so I've CC'd him.  

On Sun, May 25, 2014 at 6:37 PM, Hwan C. Lin <hwa...@gmail.com> wrote:

John,

How are you?

Recently, I worked on a BVP problem using scikits.bvp_solver. For this problem, I set boundary_points = (0, d), where d = 500.0; see below.

-------
 problem = bvp.ProblemDefinition (
                                            num_ODE = 7,
                                            num_parameters = 0,
                                            num_left_boundary_conditions = 3,
                                            boundary_points = (0, d),
                                            function = patent.dudt,
                                            boundary_conditions = patent.bc  )
------

I supposed that the resulting mesh points must always spread over the closed interval of  [0, 500], and therefore the solver will generate a vector of  continuous solution functions on [0, 500]. What puzzled me was that the solver gave a vector of solution functions  on an interval of [0, x], where x is less than d. With this problem, The functions are not defined in the interval of (x, d].

I checked on the runtime information using trace =2 and saw that the initially given interval of [0, d] keep shrinking to some extent. Does it mean the bvp_solver has bugs, or that is what is supposed to be in some particular cases. I will appreciate your thoughts on the problem I described above.

Thanks.

Hwan

[Paul Muir]

Dear Hwan,

Thanks for your question (and thanks to John for passing it on to me.)

Unfortunately I have no insight regarding the difficulty you are describing.

The underlying Fortran code is supposed to maintain the problem interval to be
whatever is given initially, throughout the computation. I have not had anyone
else report an issue with the interval changing as the computation proceeds.

In fact, it takes some effort to change the problem interval; there is a

routine called BVP_EXTEND that can make this happen, but unless one

uses this routine, the original problem interval should remain fixed
throughout the computation (and thus the approximate solution computed

by the code will be defined on this problem interval.)

Paul

--
Paul Muir,

Department of Mathematics and Computing Science,
Saint Mary's University, Halifax, NS, B3H 3C3,
mu...@smu.ca, http://cs.stmarys.ca/~muir,
Phone: 902-420-5794, Fax: 902-420-5035

[John Salvatier]

Maybe you could post the output trace=2?

--

---
You received this message because you are subscribed to the Google Groups "scikits.bvp_solver" group.
To unsubscribe from this group and stop receiving emails from it, send an email to scikits-bvp_sol...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Hwan C. Lin]

Paul:

Thanks for the information.

For the bvp problem I tried to solve using scikits.bvp_solver, I did not at all touch any internally computational mechanism. So when the initially set interval, denoted by [0, d], was changed to a smaller one, I was puzzled. Interestingly, after I rearranged the boundary conditions, this puzzling problem has no longer appeared. I realized that one boundary condition was redundant so that the required boundary conditions are, in fact, insufficient. This may explain why I got the puzzling problem.

Once again, thank you very much.

Hwan

 

[Paul Muir]

Hi Hwan,

Thank you for the extra information. It sounds like there may be an issue with

memory management and thus the right end point value is overwritten when
the number of boundary conditions is different from what it is required to be:

If you have a total of n ordinary differential equations then there must be

(exactly) a total of n boundary conditions, with at least one imposed at each
end of the problem interval.

I am not sure what you mean by "one boundary condition was redundant so that
the required boundary conditions are, in fact, insufficient." I wonder if you might

be able to send us the code that defines the problem?

Thanks, Paul

[Hwan C. Lin]

Paul,

I am still working in the code, and now the problem has not appeared any more.

In the 7 ode equations system I have, there are supposed to be seven boundary conditions, as you mentioned. In my earlier code, I did impose 7 boundary conditions. However, one of them is redundant, because once I impose three other boundary conditions, this redundant condition must hold. So, effectively, these 7 boundary conditions are just equivalent to six boundary conditions. This oversight from me should the source of the earlier problem I encountered.

Thank you very much.

Hwan