[SciPy-Dev] Boundary Value Problem solver for inclusion in SciPy

Thu Oct 8 08:26:51 EDT 2015

Excellent.  The current design of my API separates solving a BVP into three
parts.

   1. specify your problem (similar to scikits.bvp_solver)
   2. choose your basis functions (currently, any of the polynomial classes
   from NumPy are supported, in very near future I plan to add B-splines, in
   medium term I would hope to add support for a shape-preserving option)
   3. solve (solvers just wrap underlying nonlinear equations solvers in
   SciPy)

I have a number of example notebooks
<https://github.com/davidrpugh/pyCollocation/tree/master/examples> and
would welcome pointers BVPs that would be useful for either examples or
additional tests.

D

On Thu, Oct 8, 2015 at 1:00 PM, <scipy-dev-request at scipy.org> wrote:

> Send SciPy-Dev mailing list submissions to
>         scipy-dev at scipy.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
>         https://mail.scipy.org/mailman/listinfo/scipy-dev
> or, via email, send a message with subject or body 'help' to
>         scipy-dev-request at scipy.org
>
> You can reach the person managing the list at
>         scipy-dev-owner at scipy.org
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of SciPy-Dev digest..."
>
>
> Today's Topics:
>
>    1. scipy.integrate.nquad full_output (Nathan Woods)
>    2. Re: vectorized scipy.integrate.quad (Anne Archibald)
>    3. Re: Boundary Value Problem solver for inclusion in SciPy
>       (Gyro Funch)
>    4. Re: Boundary Value Problem solver for inclusion in SciPy
>       (Pauli Virtanen)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Wed, 7 Oct 2015 09:44:30 -0600
> From: Nathan Woods <charlesnwoods at gmail.com>
> To: SciPy Developers List <scipy-dev at scipy.org>
> Subject: [SciPy-Dev] scipy.integrate.nquad full_output
> Message-ID:
>         <
> CAAYHtCSu+7bJ-HWKFKsN-oPRByws4w+6NiUS3LEY-2_rrhrEzQ at mail.gmail.com>
> Content-Type: text/plain; charset="utf-8"
>
> Hey everyone,
>
> I need a design consult. I'm trying to enable the use of the quad
> full_output option when using nquad, and I'm trying to come up with a good
> way to manage all of the data that comes back from using something like
> that. Any suggestions are welcome.
>
> https://github.com/scipy/scipy/issues/5330
>
> Nathan Woods
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <
> https://mail.scipy.org/pipermail/scipy-dev/attachments/20151007/0caee8e1/attachment-0001.html
> >
>
> ------------------------------
>
> Message: 2
> Date: Wed, 07 Oct 2015 21:16:52 +0000
> From: Anne Archibald <archibald at astron.nl>
> To: SciPy Developers List <scipy-dev at scipy.org>
> Subject: Re: [SciPy-Dev] vectorized scipy.integrate.quad
> Message-ID:
>         <CANm_+ZpCAATk=
> 8tA01d23MYVENP7D7FS2c94degM-+o0D3DpOQ at mail.gmail.com>
> Content-Type: text/plain; charset="utf-8"
>
> On Tue, Oct 6, 2015 at 3:45 AM Sturla Molden <sturla.molden at gmail.com>
> wrote:
>
> > On 03/10/15 01:26, Anne Archibald wrote:
> >
> > > The additional hack where I used coroutines is a different kind of
> > > concurrency; it's a way to squeeze extra concurrency out of recursive
> or
> > > other more-complex algorithms. You can actually do the same using
> > > threads; I have thread- and coroutine-based versions of the integrator,
> > > and they look very similar.
> >
> > Personally I find that I prefer to make pipelines with threads (or
> > processes) and queues, because coroutines make my brain overheat.
> >
>
> Well, that's kind of the point - threads, processes, coroutines, even
> multiple inheritance and other "normal" flow-control procedures can be
> hopelessly confusing if used raw. We need abstractions that make
> concurrency mentally manageable but also allow reasonable parallelism.
>
> Fortunately the language designers have been thinking about this and have
> come up with some models for concurrency with less foot-shooting potential.
> Although concurrency by definition introduces non-determinism, some
> structures for concurrency can completely hide this from the programmer.
> Futures can be used this way, for example. Pipelines can be another way to
> express concurrency; taken to an extreme you can get dataflow languages
> like pd. A sufficiently smart pipeline implementation can prevent headaches
> with buffering and order of evaluation.
>
> Coroutines generally can be quite confusing, but python's asyncio
> implementation is essentially just cooperative multitasking: "async def"
> marks a function that can be suspended (and therefore needs to be run from
> a scheduler ("event loop")), and "await" marks a potential suspension
> point. Otherwise it looks just like threads.
>
> Anne
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <
> https://mail.scipy.org/pipermail/scipy-dev/attachments/20151007/4f918b70/attachment-0001.html
> >
>
> ------------------------------
>
> Message: 3
> Date: Wed, 7 Oct 2015 17:02:09 -0600
> From: Gyro Funch <gyromagnetic at gmail.com>
> To: scipy-dev at scipy.org
> Subject: Re: [SciPy-Dev] Boundary Value Problem solver for inclusion
>         in SciPy
> Message-ID: <mv489i$ns8$1 at ger.gmane.org>
> Content-Type: text/plain; charset=windows-1252
>
> On 10/7/2015 7:49 AM, David Pugh wrote:
> > All,
> >
> > I am developing a pure-python (i.e., no external fortran/C
> > dependencies) two-point boundary value solver tentatively called
> > pyCollocation <https://github.com/davidrpugh/pyCollocation> and I
> > am writing to gauge the level of interest in eventually including
> > the solver in SciPy.
> >
> > v/r,
> >
> > Dr. David R. Pugh Post-doctoral research fellow INET Oxford
> > Mathematical Institute Oxford University
> >
>
>
> I would certainly find this useful for my research and teaching.
>
> -gyro
>
>
>
> ------------------------------
>
> Message: 4
> Date: Thu, 8 Oct 2015 08:16:40 +0000 (UTC)
> From: Pauli Virtanen <pav at iki.fi>
> To: scipy-dev at scipy.org
> Subject: Re: [SciPy-Dev] Boundary Value Problem solver for inclusion
>         in SciPy
> Message-ID: <loom.20151008T101138-153 at post.gmane.org>
> Content-Type: text/plain; charset=utf-8
>
> David Pugh <david.pugh <at> maths.ox.ac.uk> writes:
> > I am developing a pure-python (i.e., no external
> > fortran/C dependencies) two-point boundary value
> > solver tentatively called pyCollocation and?I am
> > writing to gauge the level of interest in eventually
> > including the solver in SciPy.
>
> This would fall into the scope for Scipy.
>
> Existing Python packages for bvps have not been included
> so far largely due to licensing issues and due to the situation
> with free fortran 90 compilers on Windows (this latter problem
> however will likely be solved in near future).
>
> --
> Pauli Virtanen
>
> ------------------------------
>
> Subject: Digest Footer
>
> _______________________________________________
> SciPy-Dev mailing list
> SciPy-Dev at scipy.org
> https://mail.scipy.org/mailman/listinfo/scipy-dev
>
>
> ------------------------------
>
> End of SciPy-Dev Digest, Vol 144, Issue 9
> *****************************************
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/scipy-dev/attachments/20151008/93b766d3/attachment.html>