This is the mail archive of the
gsl-discuss@sourceware.org
mailing list for the GSL project.
Re: ode-initval implicit solvers and development
- From: Tuomo Keskitalo <Tuomo dot Keskitalo at iki dot fi>
- To: Brian Gough <bjg at gnu dot org>
- Cc: GSL Discuss Mailing List <gsl-discuss at sourceware dot org>
- Date: Mon, 02 Feb 2009 19:05:41 +0200
- Subject: Re: ode-initval implicit solvers and development
- References: <48E25CA9.6080306@iki.fi> <490DE4BD.7070907@iki.fi> <m3y700znqd.wl%bjg@network-theory.co.uk> <497B00F6.2080400@iki.fi> <m38woqp3je.wl%bjg@network-theory.co.uk>
Hello,
On 02/01/2009 05:42 PM, Brian Gough wrote:
- Currently the control object is only used by the multistep adams
stepper. What other types of methods might need access to the error
control?
All steppers that do some kind of iterative solution internally. For
example the methods that use Newton iteration.
- In modnewton1.c there is the comment
/* Stopping tolerance for Newton iteration */
/* FIXME: tol should be user defined */
How would you handle the newton tolerance--do we need a way to pass
that in as well?
Yes, I think that is needed. This would be done similarly to msadams,
e.g. modnewton1 asks the tolerance via gsl_odeiv_control_errlev.
I plan to implement the Newton iteration for BDF methods first, and then
modify modnewton1. I'd also like to implement the implicit 5th order
Radau method, which also needs Newton iteration. This will take some
time. It might be best to wait until then to see what other changes I'll
have to make to the ode-initval interfaces. Hopefully none.
Valgrind detects an uninitialised variable in msadams.c, which is
flagged with -Wall as well.
I'll add initialization to those, to get rid of the warnings, in the
next release. Thanks for your comments!
I'd appreciate if anyone has the chance to test and report how msadams
compares to other steppers in practice and if there are any problems
with it!
--
Tuomo.Keskitalo@iki.fi
http://iki.fi/tuomo.keskitalo