From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 3142 invoked by alias); 4 Mar 2012 07:26:58 -0000 Received: (qmail 3134 invoked by uid 22791); 4 Mar 2012 07:26:56 -0000 X-SWARE-Spam-Status: No, hits=-1.9 required=5.0 tests=BAYES_00,T_RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Received: from ipmx2.colorado.edu (HELO ipmx2.colorado.edu) (128.138.128.232) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Sun, 04 Mar 2012 07:26:43 +0000 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av4EAG0YU0/AqBGa/2dsb2JhbABDtD+BCIF9AQEFJxEeIhELGAkWDwkDAgECASceEwYCAQEXh2yvLokHjTuDIgSIUJ0AgwM Received: from omr-raz-1-priv.int.colorado.edu ([192.168.17.154]) by ipmx2-priv.int.colorado.edu with ESMTP; 04 Mar 2012 00:26:43 -0700 Received: from c-71-237-29-152.hsd1.co.comcast.net (EHLO _192.168.0.33_) ([71.237.29.152]) by omr-raz-1-priv.int.colorado.edu (MOS 4.1.10-GA FastPath queued) with ESMTP id ESU62167 (AUTH alken); Sun, 04 Mar 2012 00:26:42 -0700 (MST) Message-ID: <4F531931.7060702@colorado.edu> Date: Sun, 04 Mar 2012 07:26:00 -0000 From: Patrick Alken User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: gsl-discuss@sourceware.org Subject: Re: odeiv2 request References: <4F50F1BE.10603@colorado.edu> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit 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: 2012-q1/txt/msg00019.txt.bz2 Well, I had a PDE which reduced to a set of ODEs via the method of characteristics. I wanted to know the solution on a fixed grid, so for a given grid point, I would integrate along the characteristic curve to the boundary, and then use the boundary condition as the initial condition to integrate backwards to the original grid point where I wanted to find the solution. Changing the sign of driver->h worked very nicely but it would be best to make a function to do this, and check that its less than hmax, etc. As a side note, does the _reset function reset the step size back to the original hstart value given to the alloc routines? A quick glances indicates that it doesn't. Does this mean that when you start a new integration, it begins with the last step size from the previous integration? Also I was using driver_apply for both integrations. I kept a tight tolerance on hmax to make sure it didn't go too far past the boundary or too far past the original point. Patrick On 03/04/2012 12:02 AM, Tuomo Keskitalo wrote: > Hello, > > that's an interesting use case. May I ask why you needed to integrate > backwards? Did you use driver_apply for integration? > > I haven't really considered anyone "hotswapping" the direction of > integration using driver functions.. I think that the stepper at least > must be reset if integration direction is changed, to be safe with > multistep methods. This needs some thinking and testing. I can try to > see to this in a week or few. > > Tuomo > > On Fri, Mar 2, 2012 at 6:13 PM, Patrick Alken > wrote: >> I had a problem recently where I needed to integrate forward along a curve >> (positive step size h) and then integrate backward again (negative h). But >> there is currently no way to change the sign of the step size h using the >> driver routines, so I had to modify driver->h directly. >> >> I propose adding a routine gsl_odeiv2_driver_set_h() to allow the user to >> reset the step size to what they want. Tuomo: do you see any negative issues >> with this? I can make the addition if you want. >> >> Thanks, >> Patrick > >