public inbox for gsl-discuss@sourceware.org
 help / color / mirror / Atom feed
* odeiv2 request
@ 2012-03-02 16:14 Patrick Alken
  2012-03-04  7:02 ` Tuomo Keskitalo
  0 siblings, 1 reply; 4+ messages in thread
From: Patrick Alken @ 2012-03-02 16:14 UTC (permalink / raw)
  To: gsl-discuss

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

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: odeiv2 request
  2012-03-02 16:14 odeiv2 request Patrick Alken
@ 2012-03-04  7:02 ` Tuomo Keskitalo
  2012-03-04  7:26   ` Patrick Alken
  0 siblings, 1 reply; 4+ messages in thread
From: Tuomo Keskitalo @ 2012-03-04  7:02 UTC (permalink / raw)
  To: Patrick Alken; +Cc: gsl-discuss

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
<patrick.alken@colorado.edu> 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

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: odeiv2 request
  2012-03-04  7:02 ` Tuomo Keskitalo
@ 2012-03-04  7:26   ` Patrick Alken
  2012-03-11  8:33     ` Tuomo Keskitalo
  0 siblings, 1 reply; 4+ messages in thread
From: Patrick Alken @ 2012-03-04  7:26 UTC (permalink / raw)
  To: gsl-discuss

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
> <patrick.alken@colorado.edu>  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
>
>

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: odeiv2 request
  2012-03-04  7:26   ` Patrick Alken
@ 2012-03-11  8:33     ` Tuomo Keskitalo
  0 siblings, 0 replies; 4+ messages in thread
From: Tuomo Keskitalo @ 2012-03-11  8:33 UTC (permalink / raw)
  To: Patrick Alken; +Cc: gsl-discuss

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
>> <patrick.alken@colorado.edu> 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

^ permalink raw reply	[flat|nested] 4+ messages in thread

end of thread, other threads:[~2012-03-11  8:33 UTC | newest]

Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2012-03-02 16:14 odeiv2 request Patrick Alken
2012-03-04  7:02 ` Tuomo Keskitalo
2012-03-04  7:26   ` Patrick Alken
2012-03-11  8:33     ` Tuomo Keskitalo

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).