Send Octave-maintainers mailing list submissions to
address@hidden
To subscribe or unsubscribe via the World Wide Web, visit
https://lists.gnu.org/mailman/listinfo/octave-maintainers
or, via email, send a message with subject or body 'help' to
address@hidden
You can reach the person managing the list at
address@hidden
When replying, please edit your Subject line so it is more specific
than "Re: Contents of Octave-maintainers digest..."
Today's Topics:
1. Re: Ode techniques in octave (Sebastian Sch?ps)
2. Re: GSoC 2016 project idea - implementation of ode15s
(Richard Crozier)
3. Re: GSoC 2016 project idea - implementation of ode15s
(Richard Crozier)
4. Re: gplot.txt (Ben Abbott)
5. Re: GSoC 2016 project idea - implementation of ode15s (Sebastian)
6. build-aux/subst-config-vals.sh: line 194: -bundle_loader:
command not found (Ben Abbott)
----------------------------------------------------------------------
Message: 1
Date: Sun, 6 Mar 2016 02:46:03 -0800 (PST)
From: Sebastian Sch?ps <
address@hidden>
To:
address@hidden
Subject: Re: Ode techniques in octave
Message-ID: <
address@hidden>
Content-Type: text/plain; charset=us-ascii
Dear Karthik,
did you consider a (google) search? Then you would have found
https://www.gnu.org/software/octave/doc/interpreter/Ordinary-Differential-Equations.html
and
http://octave.sourceforge.net/odepkg/overview.html
Let's be frank: your question indicates that you should probably not apply
for this GSOC project.
Seb.
--
View this message in context:
http://octave.1599824.n4.nabble.com/Ode-techniques-in-octave-tp4675244p4675245.html
Sent from the Octave - Maintainers mailing list archive at Nabble.com.
------------------------------
Message: 2
Date: Sun, 6 Mar 2016 11:17:58 +0000
From: Richard Crozier <
address@hidden>
To: Sebastian Sch?ps <
address@hidden>,
address@hidden, Nir
Krakauer <
address@hidden>
Subject: Re: GSoC 2016 project idea - implementation of ode15s
Message-ID: <
address@hidden>
Content-Type: text/plain; charset=utf-8; format=flowed
On 05/03/16 19:38, Sebastian Sch?ps wrote:
> Nir Krakauer-2 wrote
>> Hi Richard,
>>
>> I would be willing to be a co-mentor of this if/when we have a suitable
>> student. Can you please add the project description to ?
>>
http://wiki.octave.org/Summer_of_Code_Project_Ideas ?
>>
>> Nir
>
> It's already there.
>
>
>
Thanks for offering to mentor Nir, this would be great. I would do my
best to help with all the 'boring' stuff like mercurial and setting up
for octave development etc.
Sebastian, there is no specific project to implement ode15s, it's
mentioned in the Matlab Compatible DAE, but I don't think ode15s is a
DAE solver? Perhaps you are thinking of ode15i? ode15s is a stiff ode
solver.
I'll add this to the project list.
Richard
--
The University of Edinburgh is a charitable body, registered in
Scotland, with registration number SC005336.
------------------------------
Message: 3
Date: Sun, 6 Mar 2016 11:31:26 +0000
From: Richard Crozier <
address@hidden>
To:
address@hidden
Subject: Re: GSoC 2016 project idea - implementation of ode15s
Message-ID: <
address@hidden>
Content-Type: text/plain; charset=windows-1252; format=flowed
On 05/03/16 19:52, Sebastian Sch?ps wrote:
> Richard Crozier wrote
>> The closest equivalent solver in odepkg is probably
>> ode5r and, at least for the problems I solve this is much slower because
>> the number of steps taken to solve the problem is far smaller with ode15s.
>
> Is your right-hand-side smoot enough? If yes, both ode15s and ode5r should
> have similar performance, both are accurate up to 5th order. however single
> step methods tend to use more function evaluations. if this is the
> bottleneck, then you might go better with odebdi (nonetheless we should get
> an ode15s for octave...)
>
> Seb.
>
>
Well, my process for choosing ode15s was this: try ode45, was really
slow, try ode15s, worked well. This should give you an idea of my
knowledge of the underlying numerical workings of the solvers. However,
this is also pretty much how ML recommend you choose one. My process for
choosing ode5r was pretty similar, although I think this might be the
only stiff solver, or possibly was when I first chose it. It gave best
performance of the odepkg solvers.
I'm solving a transient simulation of a three-phase generator attached
to a resistive load, so an inductive circuit with inductive coupling
between circuits.
As far as I can tell odebdi is an implicit solver for which you need the
initial derivatives, I don't know these.
Thanks for the help and pointing me to possibly new solvers.
I also think in general having an ode15s for octave is desirable anyway.
Richard
--
The University of Edinburgh is a charitable body, registered in
Scotland, with registration number SC005336.
------------------------------
Message: 4
Date: Sun, 06 Mar 2016 08:25:19 -0500
From: Ben Abbott <
address@hidden>
To: Daniel J Sebald <
address@hidden>
Cc: Rik <
address@hidden>, Octave-Maintainers
<
address@hidden>, Lachlan Andrew <
address@hidden>
Subject: Re: gplot.txt
Message-ID: <
address@hidden>
Content-Type: text/plain; charset=utf-8
> On Mar 5, 2016, at 6:08 PM, Ben Abbott <
address@hidden> wrote:
>
>> On Mar 4, 2016, at 8:44 AM, Ben Abbott <
address@hidden> wrote:
>>
>> On Mar 4, 2016, at 07:00, Ben Abbott <
address@hidden> wrote:
>>
>>>> On Mar 4, 2016, at 1:26 AM, Lachlan Andrew <
address@hidden> wrote:
>>>>
>>>>> On 4 March 2016 at 16:37, Daniel J Sebald <
address@hidden> wrote:
>>>>>
>>>>> assign memory even from the start--not a bad strategy. However, at that
>>>>> point, the member pointers r and d are initialized as r(0) and d(0). And
>>>>> 2)
>>>>> delete [] r;
>>>>>
>>>>> Now, the first line of code is more questionable. Typically one isn't
>>>>> supposed to delete a NULL pointer.
>>>>
>>>> Good catch, but deleting NULL pointers is valid in all
>>>> standards-compliant compilers, and some people advocate that rather
>>>> than checking for NULL first. See the discussion at
>>>>
>>>>
http://stackoverflow.com/questions/4190703/is-it-safe-to-delete-a-null-pointer#4190737
>>>>
>>>> Cheers,
>>>> Lachlan
>>>
>>> I tried bisecting again. The results I got is below. Many changes needed to be skipped because the default branch wouldn?t build on Mac OS X.
>>>
>>> Due to skipped revisions, the first bad revision could be any of:
>>> changeset: 21210:4f7d3989c462
>>> user: John W. Eaton <
address@hidden>
>>> date: Sat Feb 06 07:43:32 2016 -0500
>>> summary: move UMFPACK_DNAME and UMFPACK_ZNAME macros to oct-sparse.h
>>>
>>> changeset: 21211:2cf8bc5c7017
>>> user: John W. Eaton <
address@hidden>
>>> date: Sat Feb 06 08:48:47 2016 -0500
>>> summary: use "#if defined (HAVE_FOO)" instead of "#if HAVE_FOO" for feature tests
>>>
>>> changeset: 21212:7eca4ba9bb6d
>>> user: John W. Eaton <
address@hidden>
>>> date: Sat Feb 06 19:18:59 2016 -0500
>>> summary: also distribute octave.css from source tree
>>>
>>> changeset: 21213:f7d1050b9b53
>>> user: Rik <
address@hidden>
>>> date: Sat Feb 06 18:22:32 2016 -0800
>>> summary: maint: Clean up various usages of #ifdef.
>>>
>>> changeset: 21214:7be1f58f9dd7
>>> user: John W. Eaton <
address@hidden>
>>> date: Sun Feb 07 02:03:58 2016 -0500
>>> summary: don't strip pipe character from command in drawnow function
>>>
>>> changeset: 21215:04866fac690a
>>> user: Ben Abbott <address@hidden>
>>> date: Sun Feb 07 02:21:37 2016 -0500
>>> summary: use template keyword to handle dependent template names
>>>
>>> I?ll try Dan?s patch (since I?m using Apple?s clang, and they often don?t conform to other ?standards?. Then I?ll try backingout the above changes until I find the culprit.
>>>
>>> Ben
>>
>> Dan's patch didn't resolve the speye segfault. I'll move on to the changesets isolated by bisecting.
>>
>> Ben
>
> I was unable to confirm the bisecting results, so I went through the process again. This time, I single changeset was implicated. I haven?t had time to examine it yet.
>
> hg bisect --reset
> hg bisect init
> hg bisect --bad 67d2965af0b5
> hg bisect --bad a223cce1daa4
> hg bisect --bad 76e0ef020dae
> hg bisect --good 53bded18aba6
> hg bisect --good 2d7f658daa58
> hg bisect --good f5b17eb2508b
> hg bisect --good 54527108599a
> hg bisect --good 7cac4e7458f2
> hg bisect --bad 538b57866b90
> hg bisect --bad 623fc7d08cc6
> hg bisect --bad 623fc7d08cc6
> The first bad revision is:
> changeset: 21137:623fc7d08cc6
> user: Rik <
address@hidden>
> date: Sat Jan 23 17:44:57 2016 -0800
> summary: maint: Clean up compile warnings in liboctave from cset 7cac4e7458f2.
>
> Ben
I?m able to confirm by reversing changeset 623fc7d08cc6 on my tip. With the changeset reversed speye(10) does not produce a seg-fault, and does produce the proper result.
Ben
------------------------------
Message: 5
Date: Sun, 6 Mar 2016 16:25:46 +0100
From: Sebastian <
address@hidden>
To: Richard Crozier <
address@hidden>
Cc: Octave Maintainers List <
address@hidden>
Subject: Re: GSoC 2016 project idea - implementation of ode15s
Message-ID: <
address@hidden>
Content-Type: text/plain; charset=utf-8
> Am 06.03.2016 um 12:17 schrieb Richard Crozier <
address@hidden>:
>
> On 05/03/16 19:38, Sebastian Sch?ps wrote:
>> Nir Krakauer-2 wrote
>>> Hi Richard,
>>>
>>> I would be willing to be a co-mentor of this if/when we have a suitable
>>> student. Can you please add the project description to ?
>>>
http://wiki.octave.org/Summer_of_Code_Project_Ideas ?
>>>
>>> Nir
>>
>> It's already there.
>
> Thanks for offering to mentor Nir, this would be great. I would do my best to help with all the 'boring' stuff like mercurial and setting up for octave development etc.
>
> Sebastian, there is no specific project to implement ode15s, it's mentioned in the Matlab Compatible DAE, but I don't think ode15s is a DAE solver?
from the wiki: "The goal is to implement a Matlab compatible adaptive BDF solver for Differential Algebraic Equations (DAEs). The interface would need to be compatible with ode15s while for the backend the SUNDIALS library would be used, which has both a C and a MEX interface. This function should eventually be included in Octave core together with the other ODE solvers that will be released with version 4.2, but could be intially developed as an addition to the odepkg package."
> Perhaps you are thinking of ode15i? ode15s is a stiff ode solver.
Both ("s" and "i") use the same BDF method and can be used for DAEs and (stiff) ODEs. However "i" is more tailored for implicit DAEs, i.e., f(x',x,t)=0 instead of M*x'=f(x,t).
Seb.
------------------------------
Message: 6
Date: Sun, 06 Mar 2016 11:41:19 -0500
From: Ben Abbott <
address@hidden>
To: Octave-Maintainers <
address@hidden>
Subject: build-aux/subst-config-vals.sh: line 194: -bundle_loader:
command not found
Message-ID: <
address@hidden>
Content-Type: text/plain; charset=us-ascii
Make is stuck in an infinite loop for me.
build-aux/subst-config-vals.sh: line 194: -bundle_loader: command not found
build-aux/subst-config-vals.sh: line 194: -bundle_loader: command not found
build-aux/subst-config-vals.sh: line 194: -bundle_loader: command not found
build-aux/subst-config-vals.sh: line 194: -bundle_loader: command not found
build-aux/subst-config-vals.sh: line 194: -bundle_loader: command not found
build-aux/subst-config-vals.sh: line 194: -bundle_loader: command not found
build-aux/subst-config-vals.sh: line 194: -bundle_loader: command not found
build-aux/subst-config-vals.sh: line 194: -bundle_loader: command not found
build-aux/subst-config-vals.sh: line 194: -bundle_loader: command not found
build-aux/subst-config-vals.sh: line 194: -bundle_loader: command not found
build-aux/subst-config-vals.sh: line 194: -bundle_loader: command not found
build-aux/subst-config-vals.sh: line 194: -bundle_loader: command not found
build-aux/subst-config-vals.sh: line 194: -bundle_loader: command not found
^CMakefile:26631: recipe for target 'libinterp/build-env.cc' failed
make: *** [libinterp/build-env.cc] Interrupt: 2
The lines from subst-config-vals.sh are ...
190 function expand_var ()
191 {
192 eval tmp="\$$1"
193 while echo "$tmp" | grep '\${[A-Za-z_][A-Za-z0-9_]*}' > /dev/null; do
194 eval tmp="$tmp"
195 done
196 eval $1="\"$tmp\""
197 }
Is anyone else seeing this?
Only happens for the default branch and when I clean up everything.
hg status | grep '^? ' | sed "s/^? /rm /g" | /bin/sh
hg purge
Ben
------------------------------
_______________________________________________
Octave-maintainers mailing list
address@hidden
https://lists.gnu.org/mailman/listinfo/octave-maintainers
End of Octave-maintainers Digest, Vol 120, Issue 22
***************************************************