From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 9723 invoked by alias); 18 Aug 2008 18:11:54 -0000 Received: (qmail 9712 invoked by uid 22791); 18 Aug 2008 18:11:53 -0000 X-Spam-Check-By: sourceware.org Received: from mail.network-theory.co.uk (HELO mail.network-theory.co.uk) (66.199.228.187) by sourceware.org (qpsmtpd/0.31) with ESMTP; Mon, 18 Aug 2008 18:11:06 +0000 Date: Mon, 18 Aug 2008 18:11:00 -0000 Message-ID: From: Brian Gough To: Tuomo Keskitalo Cc: gsl-discuss@sourceware.org Subject: Re: GSL ode-initval development In-Reply-To: <48A7E377.3020607@iki.fi> References: <48A7E377.3020607@iki.fi> User-Agent: Wanderlust/2.14.0 (Africa) Emacs/22.2 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII X-Message-Mac: 8e4f113f95cf1440544325caa59c367f Mailing-List: contact gsl-discuss-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gsl-discuss-owner@sourceware.org X-SW-Source: 2008-q3/txt/msg00017.txt.bz2 At Sun, 17 Aug 2008 11:38:15 +0300, Tuomo Keskitalo wrote: > Implicit solvers result in a group of algebraic non-linear > equations, for which there exists several solution strategies. The > choice of the efficient strategy depends on the problem. For > example, some modified Newton iteration methods are suitable for > stiff systems, while functional iteration works for non-stiff > systems. I would like to give the user the freedom to choose the > non-linear eq solver separately from the stepping method. Does > anyone see a way to do this with current framework? If it is only a small number (and they don't need any additional parameters) then it's simplest to use the existing framework with explicit names for each combination, e.g. gsl_odeiv_step_foo_newt, gsl_odeiv_step_foo_imp, etc We mainly need additional stiff solvers, so in practical terms the functional iteration case probably isn't needed -- the non-stiff case should be covered adequately by the existing RK-type rules. Of course, in terms of internal implementation it's better to have the methods interchangeable and it is worth implementing it that way if it's not too complicated -- but in terms of exposing them to the user I don't think it's necessary to have all the permutations. > I am currently considering to add a new framework part for specifying > the non-linear equation solver. However, this would break the > current framework. I wonder if I should write a separate > "ode-initval2" library because of this. Any comments? In terms of testing and being useful in existing code, it's a lot easier to go with the current framework. -- Brian Gough