From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 6257 invoked by alias); 11 Mar 2012 08:33:46 -0000 Received: (qmail 6247 invoked by uid 22791); 11 Mar 2012 08:33:45 -0000 X-SWARE-Spam-Status: No, hits=-1.8 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_NONE,TW_BZ X-Spam-Check-By: sourceware.org Received: from gw01.mail.saunalahti.fi (HELO gw01.mail.saunalahti.fi) (195.197.172.115) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Sun, 11 Mar 2012 08:33:31 +0000 Received: from [192.168.0.102] (a91-156-39-232.elisa-laajakaista.fi [91.156.39.232]) by gw01.mail.saunalahti.fi (Postfix) with ESMTP id 8691715150F; Sun, 11 Mar 2012 10:33:26 +0200 (EET) Message-ID: <4F5C6356.6040905@iki.fi> Date: Sun, 11 Mar 2012 08:33:00 -0000 From: Tuomo Keskitalo User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.27) Gecko/20120216 Thunderbird/3.1.19 MIME-Version: 1.0 To: Patrick Alken CC: gsl-discuss@sourceware.org Subject: Re: odeiv2 request References: <4F50F1BE.10603@colorado.edu> <4F531931.7060702@colorado.edu> In-Reply-To: <4F531931.7060702@colorado.edu> 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/msg00020.txt.bz2 Hello, OK. I've committed modifications to ode-initval2 to bzr trunk, which contains new function gsl_odeiv2_driver_reset_hstart function for this. Hopefully that does the trick (safely). You are right, driver_reset does not reset the original step size, but uses the last suggested value. Now, with driver_reset_hstart, that is hopefully more clearly implied. BR, Tuomo On 03/04/2012 09:26 AM, Patrick Alken wrote: > 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 >> >> > > -- Tuomo.Keskitalo@iki.fi http://iki.fi/tuomo.keskitalo