yanl-develop Mailing List for YaNL Yet another Numerical Library
Brought to you by:
karstenahnert
Menu
▾
▴
yanl-develop
You can subscribe to this list here.
| 2009 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
(1) |
Oct
(21) |
Nov
(14) |
Dec
(3) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2010 |
Jan
|
Feb
|
Mar
(2) |
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|
From: Karsten A. <kar...@gm...> - 2010-03-10 07:38:00
|
Hi all, I have changed the interface of stepper functions. Now, one has manually adjust the size of the internal containers. Therefore, every stepper function has a function _adjust_size( x )_ . The reason is simple: Checking the size during each step might be time consuming, think for example of a badly implemented lists or graph types. Best regards, Karsten |
|
From: Karsten A. <kar...@gm...> - 2010-03-01 21:56:54
|
Hi all, we need a little help about the nomenclature of the odeint stepper orders. In principle the steppers can have three different kinds of order: 1. the order of one step, when the error is NOT calculated. 2. the order of one step, when the error is calculated 3. the order of the error step, when the error is calculated In most steppers 1 and 2 should be equal, but in some cases they differ, for example in rk78. Do you have any suggestions how to name them? We have some possibilities, but they don't fit so well and might be misleading. Best regards, Karsten |
|
From: Karsten A. <kar...@gm...> - 2009-12-15 07:50:57
|
Hi, this is great. To submit your code you can get an account for the boost sandbox by writing an email to boo...@li.... Otherwise you can send us the code and we are integrating it into odeint. Thank you very much, Karsten 杨苏立 Yang Su Li wrote: > Hi， > > I guess I will start by working on DNLS and then move to the couple > Landau-Stuart oscillator. > > For the implicit Euler, I would try to find some other implementations > first, and see what I can do from there. > > So how do I submit my codes? Do I get an svn account or something? > > Thank you very much! > > Suli > > > > 2009/12/13 Karsten Ahnert <kar...@gm...>: >> Hi, >> >> first of all, the source code lives in >> >> https://boost.org/svn/boost/sandbox/odeint >> >> Some examples already exist in the libs/numeric/odeint/examples. There >> is also one examples for the Discrete Nonlinear Schroedinger equation >> (DNLS). In principle you can take this example and implement it the DNLS >> in terms of their real and imaginary values and compare the performance >> of both. A basic performance comparison is shown in lorenz_stepper.hpp >> >> You can also do the same with coupled Landau-Stuart oscillators, which >> behave like >> \dot{A}_k = ( 1 + i \omega ) A_k - |A_k|^2 A_k + ( c_1 + i c_2 ) ( >> A_{k+1} - 2 A_k + A_{k-1} ) >> >> Up to now, we have only implemented explict ODE solvers, so we are not >> very experienced with implicit solvers. So, if you like to implement the >> implicit Euler (or Backward Euler), i think the best way is to find an >> existing implementation and try to adapt it to our interface. >> >> If you have any question or want to discuss some issues please let us >> know. Thanks for your help. >> >> Best regards, >> >> Karsten >> >> >> >> 杨苏立 Yang Su Li wrote: >>> Hi, >>> >>> I am interested in doing the following: >>> >>> * An example of an extended, complex-valued system (like the discrete >>> Nonlinear Schrödinger equation or coupled Landau-Stuart oscillators), >>> where the performance of the an implementation in real values is >>> compared against an implementation in complex values. >>> >>> Or >>> >>> * the implict Euler method. >>> >>> Please give me more details and requirements. >>> >>> Thank you very much :) >>> >>> Suli >>> >>> 2009/12/11 Karsten Ahnert <kar...@gm...>: >>>> Hi Yang, >>>> >>>> the build system is included and works fine. >>>> >>>> At the moment we need any of the following: >>>> >>>> * an example of an extended two dimensional system (like the complex >>>> Ginzburg-Landau Equation, the Fermi-Pasta-Ulam system or somethink >>>> similar) in which the different matrix type are tested and their >>>> preformance is compared. >>>> >>>> * An example of an extended, complex-valued system (like the discrete >>>> Nonlinear Schrödinger equation or coupled Landau-Stuart oscillators), >>>> where the performance of the an implementation in real values is >>>> compared against an implementation in complex values. >>>> >>>> * the implict Euler method. >>>> >>>> * Integration of the boost unit testing system. >>>> >>>> * or you have some other interesting problems which can be used as examples. >>>> >>>> Please, let us know what you want to do. Then, we can you more >>>> informations about the implementation. >>>> >>>> Best regards, >>>> >>>> Karsten >>>> >>>> >>>> >>>> >>>> 杨苏立 Yang Su Li wrote: >>>>> Hi, >>>>> >>>>> I am sorry for the late reply, but last few weeks I was in my vacation >>>>> and had very poor internet access. >>>>> >>>>> I am not very familar with the boost.build system. But I am happy to >>>>> help testing, writing examples or some implicit methods >>>>> >>>>> Please let me know what I can do. >>>>> >>>>> Thank you very much. >>>>> >>>>> Yang Suli >>>>> >>>>> >>>>> >>>>> 2009/11/16 Karsten Ahnert <kar...@gm...>: >>>>>> Hi, >>>>>> >>>>>> we discuss everything about yanl our mailing list: >>>>>> >>>>>> https://lists.sourceforge.net/lists/listinfo/yanl-develop >>>>>> >>>>>> Please register there. At the moment, we are working on the ODE solvers. >>>>>> The code lives in the boost sandbox >>>>>> >>>>>> https://boost.org/svn/boost/sandbox/odeint >>>>>> >>>>>> >>>>>> and we try to become a subpart of the boost libs. We wrote an article >>>>>> about the design of the solvers, which has been posted on codeproject. >>>>>> Maybe this is a good introduction for you: >>>>>> >>>>>> http://www.codeproject.com/KB/recipes/odeint.aspx >>>>>> >>>>>> At the moment we have several open tasks: >>>>>> >>>>>> * documentation >>>>>> * midpoint methods and some implicit methods >>>>>> * build-system for the examples >>>>>> * writing examples >>>>>> * testing >>>>>> >>>>>> Please, let us know where you want to contribute to. >>>>>> >>>>>> Best regards, >>>>>> >>>>>> Karsten >>>>>> >>>>>> >>>>>> Suli Yang wrote: >>>>>>> Message body follows: >>>>>>> >>>>>>> Hi, >>>>>>> >>>>>>> I saw your post asking for contribution to yanl. >>>>>>> >>>>>>> I am a physics Ph.D student who would like to help. I had >>>>>>> some experiences in C++ programming in a small group of >>>>>>> about 5 co-workers. Though I don't know too much about >>>>>>> numerical computing yet... >>>>>>> >>>>>>> Please let me know what I can do. >>>>>>> >>>>>>> Suli >>>>>>> >>>>>>> -- >>>>>>> This message has been sent to you, a registered SourceForge.net user, >>>>>>> by another site user, through the SourceForge.net site. This message >>>>>>> has been delivered to your SourceForge.net mail alias. You may reply >>>>>>> to this message using the "Reply" feature of your email client, or >>>>>>> using the messaging facility of SourceForge.net at: >>>>>>> https://sourceforge.net/sendmessage.php?touser=2701949 >>>>>>> >>>>> >>> >>> >> > > > |
|
From: Karsten A. <kar...@gm...> - 2009-12-13 11:32:29
|
Hi, first of all, the source code lives in https://boost.org/svn/boost/sandbox/odeint Some examples already exist in the libs/numeric/odeint/examples. There is also one examples for the Discrete Nonlinear Schroedinger equation (DNLS). In principle you can take this example and implement it the DNLS in terms of their real and imaginary values and compare the performance of both. A basic performance comparison is shown in lorenz_stepper.hpp You can also do the same with coupled Landau-Stuart oscillators, which behave like \dot{A}_k = ( 1 + i \omega ) A_k - |A_k|^2 A_k + ( c_1 + i c_2 ) ( A_{k+1} - 2 A_k + A_{k-1} ) Up to now, we have only implemented explict ODE solvers, so we are not very experienced with implicit solvers. So, if you like to implement the implicit Euler (or Backward Euler), i think the best way is to find an existing implementation and try to adapt it to our interface. If you have any question or want to discuss some issues please let us know. Thanks for your help. Best regards, Karsten 杨苏立 Yang Su Li wrote: > Hi, > > I am interested in doing the following: > > * An example of an extended, complex-valued system (like the discrete > Nonlinear Schrödinger equation or coupled Landau-Stuart oscillators), > where the performance of the an implementation in real values is > compared against an implementation in complex values. > > Or > > * the implict Euler method. > > Please give me more details and requirements. > > Thank you very much :) > > Suli > > 2009/12/11 Karsten Ahnert <kar...@gm...>: >> Hi Yang, >> >> the build system is included and works fine. >> >> At the moment we need any of the following: >> >> * an example of an extended two dimensional system (like the complex >> Ginzburg-Landau Equation, the Fermi-Pasta-Ulam system or somethink >> similar) in which the different matrix type are tested and their >> preformance is compared. >> >> * An example of an extended, complex-valued system (like the discrete >> Nonlinear Schrödinger equation or coupled Landau-Stuart oscillators), >> where the performance of the an implementation in real values is >> compared against an implementation in complex values. >> >> * the implict Euler method. >> >> * Integration of the boost unit testing system. >> >> * or you have some other interesting problems which can be used as examples. >> >> Please, let us know what you want to do. Then, we can you more >> informations about the implementation. >> >> Best regards, >> >> Karsten >> >> >> >> >> 杨苏立 Yang Su Li wrote: >>> Hi, >>> >>> I am sorry for the late reply, but last few weeks I was in my vacation >>> and had very poor internet access. >>> >>> I am not very familar with the boost.build system. But I am happy to >>> help testing, writing examples or some implicit methods >>> >>> Please let me know what I can do. >>> >>> Thank you very much. >>> >>> Yang Suli >>> >>> >>> >>> 2009/11/16 Karsten Ahnert <kar...@gm...>: >>>> Hi, >>>> >>>> we discuss everything about yanl our mailing list: >>>> >>>> https://lists.sourceforge.net/lists/listinfo/yanl-develop >>>> >>>> Please register there. At the moment, we are working on the ODE solvers. >>>> The code lives in the boost sandbox >>>> >>>> https://boost.org/svn/boost/sandbox/odeint >>>> >>>> >>>> and we try to become a subpart of the boost libs. We wrote an article >>>> about the design of the solvers, which has been posted on codeproject. >>>> Maybe this is a good introduction for you: >>>> >>>> http://www.codeproject.com/KB/recipes/odeint.aspx >>>> >>>> At the moment we have several open tasks: >>>> >>>> * documentation >>>> * midpoint methods and some implicit methods >>>> * build-system for the examples >>>> * writing examples >>>> * testing >>>> >>>> Please, let us know where you want to contribute to. >>>> >>>> Best regards, >>>> >>>> Karsten >>>> >>>> >>>> Suli Yang wrote: >>>>> Message body follows: >>>>> >>>>> Hi, >>>>> >>>>> I saw your post asking for contribution to yanl. >>>>> >>>>> I am a physics Ph.D student who would like to help. I had >>>>> some experiences in C++ programming in a small group of >>>>> about 5 co-workers. Though I don't know too much about >>>>> numerical computing yet... >>>>> >>>>> Please let me know what I can do. >>>>> >>>>> Suli >>>>> >>>>> -- >>>>> This message has been sent to you, a registered SourceForge.net user, >>>>> by another site user, through the SourceForge.net site. This message >>>>> has been delivered to your SourceForge.net mail alias. You may reply >>>>> to this message using the "Reply" feature of your email client, or >>>>> using the messaging facility of SourceForge.net at: >>>>> https://sourceforge.net/sendmessage.php?touser=2701949 >>>>> >>> >>> >> > > > |
|
From: Karsten A. <kar...@gm...> - 2009-12-11 10:49:34
|
Hi Yang, the build system is included and works fine. At the moment we need any of the following: * an example of an extended two dimensional system (like the complex Ginzburg-Landau Equation, the Fermi-Pasta-Ulam system or somethink similar) in which the different matrix type are tested and their preformance is compared. * An example of an extended, complex-valued system (like the discrete Nonlinear Schrödinger equation or coupled Landau-Stuart oscillators), where the performance of the an implementation in real values is compared against an implementation in complex values. * the implict Euler method. * Integration of the boost unit testing system. * or you have some other interesting problems which can be used as examples. Please, let us know what you want to do. Then, we can you more informations about the implementation. Best regards, Karsten 杨苏立 Yang Su Li wrote: > Hi, > > I am sorry for the late reply, but last few weeks I was in my vacation > and had very poor internet access. > > I am not very familar with the boost.build system. But I am happy to > help testing, writing examples or some implicit methods > > Please let me know what I can do. > > Thank you very much. > > Yang Suli > > > > 2009/11/16 Karsten Ahnert <kar...@gm...>: >> Hi, >> >> we discuss everything about yanl our mailing list: >> >> https://lists.sourceforge.net/lists/listinfo/yanl-develop >> >> Please register there. At the moment, we are working on the ODE solvers. >> The code lives in the boost sandbox >> >> https://boost.org/svn/boost/sandbox/odeint >> >> >> and we try to become a subpart of the boost libs. We wrote an article >> about the design of the solvers, which has been posted on codeproject. >> Maybe this is a good introduction for you: >> >> http://www.codeproject.com/KB/recipes/odeint.aspx >> >> At the moment we have several open tasks: >> >> * documentation >> * midpoint methods and some implicit methods >> * build-system for the examples >> * writing examples >> * testing >> >> Please, let us know where you want to contribute to. >> >> Best regards, >> >> Karsten >> >> >> Suli Yang wrote: >>> Message body follows: >>> >>> Hi, >>> >>> I saw your post asking for contribution to yanl. >>> >>> I am a physics Ph.D student who would like to help. I had >>> some experiences in C++ programming in a small group of >>> about 5 co-workers. Though I don't know too much about >>> numerical computing yet... >>> >>> Please let me know what I can do. >>> >>> Suli >>> >>> -- >>> This message has been sent to you, a registered SourceForge.net user, >>> by another site user, through the SourceForge.net site. This message >>> has been delivered to your SourceForge.net mail alias. You may reply >>> to this message using the "Reply" feature of your email client, or >>> using the messaging facility of SourceForge.net at: >>> https://sourceforge.net/sendmessage.php?touser=2701949 >>> >> > > > |
|
From: Karsten A. <kar...@gm...> - 2009-11-28 19:04:54
|
Hi,
lambda expression in the observer will not work immediately if the
container_type is std::tr1::array. But you can do the following:
array< double , 3 > x = {{ 1.0 , 10.0 , 0.5 }};
integrate_const_steps( rk4 , lorenz , t , dt , x , 10000 ,
cout << _1 << "\t" << ret<double&>(_2[0]) << "\t"
ret<double&>(_2[1]) << "\t"
ret<double&>(_2[2]) << "\n" );
See the attached source file for a comparison with the std::vector.
Best regards,
Karsten
|
|
From: Karsten A. <kar...@gm...> - 2009-11-24 21:05:54
|
Hi everybody, we have changed the method names of the stepper functions: In all steppers next_step() is now do_step() and in the controlled stepper this method is now called try_method(). This clarifies the functionality of the method. Best regards, Karsten |
|
From: Karsten A. <kar...@gm...> - 2009-11-22 20:54:33
|
Hi everyone, just one short notes: maybe people are confused if the controlled step is a stepper. It does not perform one step it tries one step. Maybe we should call the method try_step(). We can also clarify the method names for the the Stepper and ErrorStep by chaning next_step() to do_step(). Regards, Karsten Mario Mulansky wrote: > Hi everyone, > > I have just reorganized the code of the stepsize_controller and created > controlled_stepper on its behalf. So I want to take the opportunity to give > a short review on current status of the stepper design: > > There are three different types (you may say concepts) of stepper classes: > - Stepper: fixed step size, no error estimation, examples: stepper_euler, > stepper_rk4 > > - ErrorStepper: fixed step size, with error estimation, examples: > stepper_half_step, stepper_rk5_ck > > - ControlledStepper: variable step size, uses error estimation for adjusting > the stepsize, example: controlled_stepper_standard > > As you might imagine, they have the following purposes: Steppers are for > simple, fixed step size, straight forward integration without thinking about > errors at all. ErrorSteppers give you the opportunity to check the errors > while integrating. They are hardly used alone, but serves as a basis for > ControlledSteppers. The ControlledSteppers can control the error of a step > and adjust step size (and maybe also order) of the individual integration > steps. This enables you to ensure that the error of each step is below a > certain threshold, for example. ControlledSteppers require some underlying > ErrorStepper which actually does the step and estimates the error. > > The respective steppers provide the following methods: > > Stepper: > > order_type order() Returns the order of the method. that is the error of hte > method scales as dt^(order+1). order_type is typically unsigned short > > void next_step( system, x, t, dt ) Applies one integration step of size dt > using x as starting point at time t. system represents the rhs of the > equation x' = f(x,t). The result of the step is stored in x (in-place step). > > void next_step( system, x, dxdt, t, dt ) Same as above, but additionally > x'(x,t) is provided in dxdt, which might reduce calls of the system function. > > > ErrorStepper: > > order_type order() > Returns the order of the method. that is the error of hte method scales as > dt^(order+1). order_type is typically unsigned short > > order_type order_error() > Returns the order of the error estimation, that is the error of the error > estimation scales as dt^(order_error+1) > > next_step( system, x, t, dt, xerr ) > Applies one integration step of size dt using x as starting point at time t. > system represents the rhs of the equation x' = f(x,t). The result of the step > is stored in x (in-place step). An additional error estimation is performed > and the result is stored in xerr. > > next_step( system, x, dxdt, t, dt, xerr ) > Same as above, but with dxdt = x'(x,t) provided as an additional parameter. > > > ControlledStepper: > > order_type order() > Returns the order of the last step(!) performed by this class. > > controlled_step_result next_step( system, x, t, dt ) > Performs a controlled step starting with x at t using system to define the rhs > of x' = f(x,t). This means to try a step with dt and check the error (usually > by using an ErrorStepper). If the error is too large, the result of the step > is discarded, an appropriate step size dt is set (dt is an In/Out parameter > here) and the value step_size_decreased is returned. If the error was too > small, the step is applied (result stored in x), t is increased t+=dt (t is > also In/Out), dt is set to a better stepsize and step_size_increased is > returned. If the error was ok, the result of the step is stored in x, t is > increased t += dt and success is returned. > > Regards, Mario > > ------------------------------------------------------------------------------ > Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day > trial. Simplify your report design, integration and deployment - and focus on > what you do best, core application coding. Discover what's new with > Crystal Reports now. http://p.sf.net/sfu/bobj-july > _______________________________________________ > Yanl-develop mailing list > Yan...@li... > https://lists.sourceforge.net/lists/listinfo/yanl-develop > |
|
From: Karsten A. <kar...@gm...> - 2009-11-16 09:27:06
|
Hi, we discuss everything about yanl our mailing list: https://lists.sourceforge.net/lists/listinfo/yanl-develop Please register there. At the moment, we are working on the ODE solvers. The code lives in the boost sandbox https://boost.org/svn/boost/sandbox/odeint and we try to become a subpart of the boost libs. We wrote an article about the design of the solvers, which has been posted on codeproject. Maybe this is a good introduction for you: http://www.codeproject.com/KB/recipes/odeint.aspx At the moment we have several open tasks: * documentation * midpoint methods and some implicit methods * build-system for the examples * writing examples * testing Please, let us know where you want to contribute to. Best regards, Karsten Suli Yang wrote: > Message body follows: > > Hi, > > I saw your post asking for contribution to yanl. > > I am a physics Ph.D student who would like to help. I had > some experiences in C++ programming in a small group of > about 5 co-workers. Though I don't know too much about > numerical computing yet... > > Please let me know what I can do. > > Suli > > -- > This message has been sent to you, a registered SourceForge.net user, > by another site user, through the SourceForge.net site. This message > has been delivered to your SourceForge.net mail alias. You may reply > to this message using the "Reply" feature of your email client, or > using the messaging facility of SourceForge.net at: > https://sourceforge.net/sendmessage.php?touser=2701949 > |
|
From: Karsten A. <kar...@gm...> - 2009-11-12 18:38:04
|
Hello everybody, I wrote a small article about odeint: http://www.codeproject.com/KB/recipes/odeint.aspx which explains the main ideas of the source code and the background on solving ODEs. Best regards, Karsten |
|
From: Karsten A. <kar...@gm...> - 2009-11-12 14:37:59
|
Hello everybody, in short: we need a build system for the examples for odeint. We have three possibilities: make, cmake or bjam. Of course, the build process has to be boost conform, so I guess it should be bjam or cmake. Is there anybody who can do this? Thanks, Karsten |
|
From: Constantine A. <aco...@us...> - 2009-11-12 13:19:33
|
Karsten, I wrote the example harmonic oscillator which is attached. I'm having trouble evaluating the results, because the structure of the library is rapidly changing when I do an svn update. The library also seems somewhat complicated to use to me. Each of the boost libraries has a web-based introduction to the library on the boost website. Most of them do a good job of telling the story of how the library is used, and why it evolved the way it did. I find the pages for Concept Check especially exemplary of this. Does odeint have anything similar? That might make it easier for newcomers to understand the changes that are taking place, and the design decisions that have been made. Constantine On Fri, Oct 30, 2009 at 9:26 AM, Karsten Ahnert <kar...@gm...> wrote: > Hi Constantine, > > Thanks for your reply. Maybe, first of all it would be nice, if you > could contribute some examples to odeint (similar to lorenz.cpp in > libs/numeric/odeint/examples): > > with appropriate constants A, omega, phi, kappa. It would be great here, > if it could be shown that the precision of Euler is much smaller than > that of RK4. > > 2. Speed test for the same ODE, with different containers. For example, > it would be nice to see, which Container in lorenz.cpp is the fastest: > vector<double>, list<double>, array<double,3>? > > If you need any help or have any questions, just ask. Maybe, you have > also some suggestion on the interface of the odeint classes. > > Thank you a lot, > > Karsten > > [1] http://en.wikipedia.org/wiki/Harmonic_oscillator , the universal > oscillator and the damped oscillator section. > > > Constantine wrote: >> Message body follows: >> >> >> Karsten, >> >> Thanks for the reply. I have checked out the code from >> https://boost.org/svn/boost/sandbox/odeint. As far as ODEs >> and TMP, I >> am comfortable with both. I would be happy to jump into >> either or both >> on this project. >> >> Constantine >> >> -- >> This message has been sent to you, a registered SourceForge.net user, >> by another site user, through the SourceForge.net site. This message >> has been delivered to your SourceForge.net mail alias. You may reply >> to this message using the "Reply" feature of your email client, or >> using the messaging facility of SourceForge.net at: >> https://sourceforge.net/sendmessage.php?touser=2670242 >> > > > ------------------------------------------------------------------------------ > Come build with us! The BlackBerry(R) Developer Conference in SF, CA > is the only developer event you need to attend this year. Jumpstart your > developing skills, take BlackBerry mobile applications to market and stay > ahead of the curve. Join us from November 9 - 12, 2009. Register now! > http://p.sf.net/sfu/devconference > _______________________________________________ > Yanl-develop mailing list > Yan...@li... > https://lists.sourceforge.net/lists/listinfo/yanl-develop > |
|
From: Karsten A. <kar...@gm...> - 2009-11-06 15:50:46
|
Dear all, yes I have thought about something similar. But I am not sure these journals accept an article about standard methods with templates metaprogramming. If they do, this will be a nice opportunity to present our lib to the scientific community. Nevertheless, I will try to write this weekend some small articles for more programming oriented platforms, like codeproject.com or some C++ sites or journals. Best regards, Karsten Markus Abel wrote: > Dear all, > > I just read the last computer physics communication. > It would be a good platform (or Jcp journal of computational physics) > to present the yanl work. > > Since I am programming absolutely zero (and have even problems > following the code) > I would be ready to write a small summary of the scope and the state > of the project, once we are ready to go public. > > You can look at the journal at > http://www.sciencedirect.com/science/journal/00104655 > This is really nothing but a list of programs the people want to sell > to their colleagues. > > Best, Markus > |
|
From: Markus A. <mar...@go...> - 2009-11-06 15:28:02
|
Dear all, I just read the last computer physics communication. It would be a good platform (or Jcp journal of computational physics) to present the yanl work. Since I am programming absolutely zero (and have even problems following the code) I would be ready to write a small summary of the scope and the state of the project, once we are ready to go public. You can look at the journal at http://www.sciencedirect.com/science/journal/00104655 This is really nothing but a list of programs the people want to sell to their colleagues. Best, Markus -- Priv.-Doz. Dr. rer. nat. Markus Abel http://www.stat.physik.uni-potsdam.de/~markus Department of Physics and Astronomy University of Potsdam Karl-Liebknecht-Str 24/25, Bldg 28 D-14476, Potsdam, Germany Tel. +49-331-9775139 Fax +49-331-9775947 |
|
From: Karsten A. <kar...@gm...> - 2009-11-03 10:42:31
|
Hi all, I have thought a little bit about this topic_ 1 .it would be nice to have functions integrate, like integrate( stepper , system , dt , start_time , start_state , steps ) which in-place integrate the start state 2. Functions, like integrate_and_fill( stepper , system , dt , start_time , start_state , container ) integrate_and_fill( stepper , system , dt , start_time , start_state , start_iter , end_iter ) which fill one container with a "time series", (the container version only calls the iterator version), 3 . A version with integrate_and_insert( stepper , system , dt , start_time , start_state , steps , inserter ) which insert the time series into a (mayby empty) container. The inserter is the most general syntax for doing so, but we can also write some other wrappers for this function. I think every funtion is only a two (or three) liner, so there is no much overhead and we have a function for nearly all applications. And of course, we have to introduce some kind of observer concept. Best regards, Karsten Mario Mulansky wrote: > Hi all, > >> void integrate( stepper , system , dt , start_time , start_state , >> end_time , inserter ); >> void integrate( stepper , system , dt , start_time , start_state , >> num_of_steps , inserter ); >> void integrate( stepper , system , dt , start_time , start_state , >> start_iter , end_inter ); >> void integrate( stepper , system , dt , start_time , start_state , >> state_container ); > > I don't exactly understand why we need inserter, start/end_iter and > state_container. All our routines are in-place and work on start_state. If > the user doesn't want his start state overwritten he should copy it himslef > before. I also think one method with number_of_steps is sufficient. For > constant dt the relation to t is obvious and can be left to the user. > > Regards, Mario > >> Maybe one gets into troubles with the first two versions, since end_time >> can easily by casted in num_of_steps. For the inserter one needs the >> InsertIterator requirement[1] and the stepper needs the next_step >> function without error estimation. >> >> Best regards, >> >> Karsten >> >> >> [1] http://www.sgi.com/tech/stl/insert_iterator.html >> >> --------------------------------------------------------------------------- >> --- Come build with us! The BlackBerry(R) Developer Conference in SF, CA is >> the only developer event you need to attend this year. Jumpstart your >> developing skills, take BlackBerry mobile applications to market and stay >> ahead of the curve. Join us from November 9 - 12, 2009. Register now! >> http://p.sf.net/sfu/devconference >> _______________________________________________ >> Yanl-develop mailing list >> Yan...@li... >> https://lists.sourceforge.net/lists/listinfo/yanl-develop > > ------------------------------------------------------------------------------ > Come build with us! The BlackBerry(R) Developer Conference in SF, CA > is the only developer event you need to attend this year. Jumpstart your > developing skills, take BlackBerry mobile applications to market and stay > ahead of the curve. Join us from November 9 - 12, 2009. Register now! > http://p.sf.net/sfu/devconference > _______________________________________________ > Yanl-develop mailing list > Yan...@li... > https://lists.sourceforge.net/lists/listinfo/yanl-develop > |
|
From: Karsten A. <kar...@gm...> - 2009-11-02 20:25:16
|
Hi everybody, what do you think about some integration routines with fixed times step. I have some suggestions for an interface: void integrate( stepper , system , dt , start_time , start_state , end_time , inserter ); void integrate( stepper , system , dt , start_time , start_state , num_of_steps , inserter ); void integrate( stepper , system , dt , start_time , start_state , start_iter , end_inter ); void integrate( stepper , system , dt , start_time , start_state , state_container ); Maybe one gets into troubles with the first two versions, since end_time can easily by casted in num_of_steps. For the inserter one needs the InsertIterator requirement[1] and the stepper needs the next_step function without error estimation. Best regards, Karsten [1] http://www.sgi.com/tech/stl/insert_iterator.html |
|
From: Karsten A. <kar...@gm...> - 2009-10-30 14:23:25
|
Hi Constantine, Thanks for your reply. Maybe, first of all it would be nice, if you could contribute some examples to odeint (similar to lorenz.cpp in libs/numeric/odeint/examples): 1. Numerical integration of the harmonic oscillator [1] and comparison with the analytical solution. The ODE is d^2x/dt^2 = - x - gamma dx / dt, and the analyitcal solution has the form x(t) = A cos( omega t + phi ) E^( - kappa t ) with appropriate constants A, omega, phi, kappa. It would be great here, if it could be shown that the precision of Euler is much smaller than that of RK4. 2. Speed test for the same ODE, with different containers. For example, it would be nice to see, which Container in lorenz.cpp is the fastest: vector<double>, list<double>, array<double,3>? If you need any help or have any questions, just ask. Maybe, you have also some suggestion on the interface of the odeint classes. Thank you a lot, Karsten [1] http://en.wikipedia.org/wiki/Harmonic_oscillator , the universal oscillator and the damped oscillator section. Constantine wrote: > Message body follows: > > > Karsten, > > Thanks for the reply. I have checked out the code from > https://boost.org/svn/boost/sandbox/odeint. As far as ODEs > and TMP, I > am comfortable with both. I would be happy to jump into > either or both > on this project. > > Constantine > > -- > This message has been sent to you, a registered SourceForge.net user, > by another site user, through the SourceForge.net site. This message > has been delivered to your SourceForge.net mail alias. You may reply > to this message using the "Reply" feature of your email client, or > using the messaging facility of SourceForge.net at: > https://sourceforge.net/sendmessage.php?touser=2670242 > |
|
From: Karsten A. <kar...@gm...> - 2009-10-29 15:07:45
|
Hi Constantine, we decided to split the whole lib into smaller pieces. First, we want to develop routines for solving ordinary differential equations (ODEs). We think, that this might be interesting for a broad audience, such that we moved the development into the boost sandbox. But we still use the YaNL mailing list for communication and discussion. The code can be found here: https://boost.org/svn/boost/sandbox/odeint Do you have any experience in solving ODE's numerically? If you have, you can implement some implicit algorithms, like implicit Euler... Furthermore, we need to write documentation (possibly with the standards of the boost) and neat some examples. If you have much experience in template-meta-programming you can also review the current state of the code. Just tell us, what you want contribute to and we can give you the details. Thanks, Karsten Constantine wrote: > Message body follows: > > Hi, > > What is the current state of development on YaNL? I thought > I saw a post looking fro developers for this project > recently, though currently none appear. > > I'm an electrical engineer and C/C++ developer looking for a > few small projects to contribute to. > > Thanks, > > Constantine > > -- > This message has been sent to you, a registered SourceForge.net user, > by another site user, through the SourceForge.net site. This message > has been delivered to your SourceForge.net mail alias. You may reply > to this message using the "Reply" feature of your email client, or > using the messaging facility of SourceForge.net at: > https://sourceforge.net/sendmessage.php?touser=2670242 > |
|
From: Karsten A. <kar...@gm...> - 2009-10-22 18:49:37
|
Hello everybody, have a look in euler.hpp. We have added std::tr1::array support for the euler class. Two points: 1. we should go back to iterators in the the derivative function, because the iterators of array are usually pointers. 2. I don't know how we can specialize the resize_container class for arrays. Maybe somebody knows how it works. Then we can avoid the explicit declaration of the array resizer, as in lorenz_array.cpp Bye, Karsten |
|
From: Karsten A. <kar...@gm...> - 2009-10-21 14:26:01
|
Hello everybody, I started the project in the boost sandbox: https://www.boost.org/svn/boost/sandbox/odeint Getting the code is simple: svn co https://www.boost.org/svn/boost/sandbox/odeint For submitting code you need an account, which you can easily get. Just write a mail to boo...@li... Best regards, Karsten |
|
From: Mario M. <mar...@gm...> - 2009-10-19 21:09:06
|
Hi,
> Nevertheless we should consider to implement some dynamical system classes.
> Maybe no basic one, as now, but some useful
> wrappers for building dynamical systems of dynamical systems, as I
> implemented it in my class (I don't know if you had a close look on it).
> I find this very useful and use it a lot. I mean something like this:
>
> coupled_chain< hopf_oscillator , complex_coupling<1,2> >
> ginzburg_landau( 1000 );
> sparse_network< roessler > net( 123 );
> coupled_grid< lotka_volterra > rauber_beute_gebiet( 100,100
> );
>
> Something like this should exist in parallel to the steppers in order to
> provide more reusable code.
I think this is generally a good idea and it indeed seems usefull to provide
such dynamical system classes within the library. However, one has to make
sure that the corresponding state representations are properly working
together with the steppers, as they basically expect plain 1D sequences of
doubles/complex and won't work with chains of 2 or higher dimensional
objects. Maybe this can be overcome, though.
Anyways, if it is possible to implement something like "chain of dynamical
system" that works with the stepper I agree that this would be a usefull
thing.
Regards, Mario
>
> tschüssikovsky,
> André
>
>
> -------- Original-Nachricht --------
>
> > Datum: Fri, 16 Oct 2009 14:53:30 +0200
> > Von: Karsten Ahnert <kar...@gm...>
> > An: yan...@li...
> > Betreff: Re: [Yanl-develop] my thoughts about current development state
> >
> > Hello everybody,
> >
> > First of all, it is nice that we started a very constructive discussion.
> > In my eyes it goes in the right direction.
> >
> > I would suggest that we write and discuss here some minimal code which
> > is then implemented. I would also suggest that we use the euler steper
> > as the basis for discussion, because its the most simple one and we drop
> > any discussion about names, const, ... to a later point, until main
> > points have been clarified.
> >
> > My suggestion for a minimal stepper design is the following (avoiding
> > any discussion about autonomous and non-autonomous systems)
> >
> > template<class ContainerType>
> > class ode_step_euler
> > {
> >
> > ContainerType dxdt;
> >
> >
> > public:
> >
> > template<class CallMethod, class Iterator>
> > void do_step(
> > CallMethod derivative ,
> > double dt ,
> > Iterator start ,
> > Iterater end )
> > {
> > ContainerType::iterator dxdtiter = dxdt.begin();
> > derivative( start , dxdtiter );
> > while( start != end )
> > *start++ += dt * (*dxdtiter++);
> > }
> >
> > template< class CallMethod , class StateContainer >
> > void do_step(
> > CallMethod derivative ,
> > double dt ,
> > StateContainer state )
> > {
> > do_step( derivative , dt , state.begin() , state.end() );
> > }
> > };
> >
> > I think this design has all we need and is very flexible:
> > * no virtual functions are used anymode
> > * One can use the iterator and the container version
> > * CallMethod can be a function or a class, whatever one likes.
> >
> >
> > What we have to do now is, define how dxdt is created, which is indeed
> > not trivial.
> >
> > > Concerning the current discussion:
> > > If the standard C-like usage (via functions) is not supported, as
> > > currently discussed and which is also my position, I would recommend to
> > > put the
> > > system's state definition (the ContainerType) into the dynamical_system
> > > class (or some derivation of it) as I did it in my
> > > lib. This is less error prone, since the user must not care about what
> > > kind of variable (s)he has to create for storing the state.
> > > In Mario's example with the harmonic oscillator the user has to provide
> > > the state-container-type twice, once to the stepper and to the system.
> > > The latter seems to be kind of redundant and should be part of the
> > > system and not the user's choice.
> >
> > You are right, with the above approach this is possible but not
> > necessary...
> >
> > > In stepper:
> > > The current time point 't' should, if needed (as for non-autonomous
> > > systems), be part of the system's state and being integrated by the
> > > system using dt.
> >
> > This is not possible, the time has to be a parameter. It will not work
> > in RK4 or others for the intermediate points.
> >
> > Bye, Karsten
>
> ---------------------------------------------------------------------------
>---
>
> > Come build with us! The BlackBerry(R) Developer Conference in SF, CA
> > is the only developer event you need to attend this year. Jumpstart your
> > developing skills, take BlackBerry mobile applications to market and stay
> > ahead of the curve. Join us from November 9 - 12, 2009. Register now!
> > http://p.sf.net/sfu/devconference
> > _______________________________________________
> > Yanl-develop mailing list
> > Yan...@li...
> > https://lists.sourceforge.net/lists/listinfo/yanl-develop
>
> --
> Neu: GMX DSL bis 50.000 kBit/s und 200,- Euro Startguthaben!
> http://portal.gmx.net/de/go/dsl02
>
> ---------------------------------------------------------------------------
>--- Come build with us! The BlackBerry(R) Developer Conference in SF, CA is
> the only developer event you need to attend this year. Jumpstart your
> developing skills, take BlackBerry mobile applications to market and stay
> ahead of the curve. Join us from November 9 - 12, 2009. Register now!
> http://p.sf.net/sfu/devconference
> _______________________________________________
> Yanl-develop mailing list
> Yan...@li...
> https://lists.sourceforge.net/lists/listinfo/yanl-develop
|
|
From: Markus A. <mar...@go...> - 2009-10-19 12:39:46
|
Should we try to present our stuff at http://www.iccs-meeting.org/ ? 2010 or 2011? |
|
From: André B. <and...@go...> - 2009-10-16 20:01:47
|
Nite every1,
> I wanted quickly to add that we came to the conclusion to drop the class
structure of the implementation and remain with generic template code only.
> That means we don't have dynamical_system and ode_step_base anymore.
Former abstract interfaces will be realized with concepts.
I think that is a good solution for the stepper.
Nevertheless we should consider to implement some dynamical system classes.
Maybe no basic one, as now, but some useful
wrappers for building dynamical systems of dynamical systems, as I
implemented it in my class (I don't know if you had a close look on it).
I find this very useful and use it a lot. I mean something like this:
coupled_chain< hopf_oscillator , complex_coupling<1,2> >
ginzburg_landau( 1000 );
sparse_network< roessler > net( 123 );
coupled_grid< lotka_volterra > rauber_beute_gebiet( 100,100
);
Something like this should exist in parallel to the steppers in order to
provide more reusable code.
tschüssikovsky,
André
-------- Original-Nachricht --------
> Datum: Fri, 16 Oct 2009 14:53:30 +0200
> Von: Karsten Ahnert <kar...@gm...>
> An: yan...@li...
> Betreff: Re: [Yanl-develop] my thoughts about current development state
> Hello everybody,
>
> First of all, it is nice that we started a very constructive discussion.
> In my eyes it goes in the right direction.
>
> I would suggest that we write and discuss here some minimal code which
> is then implemented. I would also suggest that we use the euler steper
> as the basis for discussion, because its the most simple one and we drop
> any discussion about names, const, ... to a later point, until main
> points have been clarified.
>
> My suggestion for a minimal stepper design is the following (avoiding
> any discussion about autonomous and non-autonomous systems)
>
> template<class ContainerType>
> class ode_step_euler
> {
>
> ContainerType dxdt;
>
>
> public:
>
> template<class CallMethod, class Iterator>
> void do_step(
> CallMethod derivative ,
> double dt ,
> Iterator start ,
> Iterater end )
> {
> ContainerType::iterator dxdtiter = dxdt.begin();
> derivative( start , dxdtiter );
> while( start != end )
> *start++ += dt * (*dxdtiter++);
> }
>
> template< class CallMethod , class StateContainer >
> void do_step(
> CallMethod derivative ,
> double dt ,
> StateContainer state )
> {
> do_step( derivative , dt , state.begin() , state.end() );
> }
> };
>
> I think this design has all we need and is very flexible:
> * no virtual functions are used anymode
> * One can use the iterator and the container version
> * CallMethod can be a function or a class, whatever one likes.
>
>
> What we have to do now is, define how dxdt is created, which is indeed
> not trivial.
>
> > Concerning the current discussion:
> > If the standard C-like usage (via functions) is not supported, as
> > currently discussed and which is also my position, I would recommend to
> > put the
> > system's state definition (the ContainerType) into the dynamical_system
> > class (or some derivation of it) as I did it in my
> > lib. This is less error prone, since the user must not care about what
> > kind of variable (s)he has to create for storing the state.
> > In Mario's example with the harmonic oscillator the user has to provide
> > the state-container-type twice, once to the stepper and to the system.
> > The latter seems to be kind of redundant and should be part of the
> > system and not the user's choice.
>
> You are right, with the above approach this is possible but not
> necessary...
>
> > In stepper:
> > The current time point 't' should, if needed (as for non-autonomous
> > systems), be part of the system's state and being integrated by the
> > system using dt.
>
> This is not possible, the time has to be a parameter. It will not work
> in RK4 or others for the intermediate points.
>
> Bye, Karsten
>
>
>
------------------------------------------------------------------------------
> Come build with us! The BlackBerry(R) Developer Conference in SF, CA
> is the only developer event you need to attend this year. Jumpstart your
> developing skills, take BlackBerry mobile applications to market and stay
> ahead of the curve. Join us from November 9 - 12, 2009. Register now!
> http://p.sf.net/sfu/devconference
> _______________________________________________
> Yanl-develop mailing list
> Yan...@li...
> https://lists.sourceforge.net/lists/listinfo/yanl-develop
--
Neu: GMX DSL bis 50.000 kBit/s und 200,- Euro Startguthaben!
http://portal.gmx.net/de/go/dsl02
------------------------------------------------------------------------------
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
_______________________________________________
Yanl-develop mailing list
Yan...@li...
https://lists.sourceforge.net/lists/listinfo/yanl-develop
|
|
From: <mar...@gm...> - 2009-10-16 12:55:38
|
Hi,
I wanted quickly to add that we came to the conclusion to drop the class structure of the implementation and remain with generic template code only. That means we don't have dynamical_system and ode_step_base anymore. Former abstract interfaces will be realized with concepts.
Mario
-------- Original-Nachricht --------
> Datum: Fri, 16 Oct 2009 14:53:30 +0200
> Von: Karsten Ahnert <kar...@gm...>
> An: yan...@li...
> Betreff: Re: [Yanl-develop] my thoughts about current development state
> Hello everybody,
>
> First of all, it is nice that we started a very constructive discussion.
> In my eyes it goes in the right direction.
>
> I would suggest that we write and discuss here some minimal code which
> is then implemented. I would also suggest that we use the euler steper
> as the basis for discussion, because its the most simple one and we drop
> any discussion about names, const, ... to a later point, until main
> points have been clarified.
>
> My suggestion for a minimal stepper design is the following (avoiding
> any discussion about autonomous and non-autonomous systems)
>
> template<class ContainerType>
> class ode_step_euler
> {
>
> ContainerType dxdt;
>
>
> public:
>
> template<class CallMethod, class Iterator>
> void do_step(
> CallMethod derivative ,
> double dt ,
> Iterator start ,
> Iterater end )
> {
> ContainerType::iterator dxdtiter = dxdt.begin();
> derivative( start , dxdtiter );
> while( start != end )
> *start++ += dt * (*dxdtiter++);
> }
>
> template< class CallMethod , class StateContainer >
> void do_step(
> CallMethod derivative ,
> double dt ,
> StateContainer state )
> {
> do_step( derivative , dt , state.begin() , state.end() );
> }
> };
>
> I think this design has all we need and is very flexible:
> * no virtual functions are used anymode
> * One can use the iterator and the container version
> * CallMethod can be a function or a class, whatever one likes.
>
>
> What we have to do now is, define how dxdt is created, which is indeed
> not trivial.
>
> > Concerning the current discussion:
> > If the standard C-like usage (via functions) is not supported, as
> > currently discussed and which is also my position, I would recommend to
> > put the
> > system's state definition (the ContainerType) into the dynamical_system
> > class (or some derivation of it) as I did it in my
> > lib. This is less error prone, since the user must not care about what
> > kind of variable (s)he has to create for storing the state.
> > In Mario's example with the harmonic oscillator the user has to provide
> > the state-container-type twice, once to the stepper and to the system.
> > The latter seems to be kind of redundant and should be part of the
> > system and not the user's choice.
>
> You are right, with the above approach this is possible but not
> necessary...
>
> > In stepper:
> > The current time point 't' should, if needed (as for non-autonomous
> > systems), be part of the system's state and being integrated by the
> > system using dt.
>
> This is not possible, the time has to be a parameter. It will not work
> in RK4 or others for the intermediate points.
>
> Bye, Karsten
>
>
> ------------------------------------------------------------------------------
> Come build with us! The BlackBerry(R) Developer Conference in SF, CA
> is the only developer event you need to attend this year. Jumpstart your
> developing skills, take BlackBerry mobile applications to market and stay
> ahead of the curve. Join us from November 9 - 12, 2009. Register now!
> http://p.sf.net/sfu/devconference
> _______________________________________________
> Yanl-develop mailing list
> Yan...@li...
> https://lists.sourceforge.net/lists/listinfo/yanl-develop
--
Neu: GMX DSL bis 50.000 kBit/s und 200,- Euro Startguthaben!
http://portal.gmx.net/de/go/dsl02
|
|
From: Karsten A. <kar...@gm...> - 2009-10-16 12:51:05
|
Hello everybody,
First of all, it is nice that we started a very constructive discussion.
In my eyes it goes in the right direction.
I would suggest that we write and discuss here some minimal code which
is then implemented. I would also suggest that we use the euler steper
as the basis for discussion, because its the most simple one and we drop
any discussion about names, const, ... to a later point, until main
points have been clarified.
My suggestion for a minimal stepper design is the following (avoiding
any discussion about autonomous and non-autonomous systems)
template<class ContainerType>
class ode_step_euler
{
ContainerType dxdt;
public:
template<class CallMethod, class Iterator>
void do_step(
CallMethod derivative ,
double dt ,
Iterator start ,
Iterater end )
{
ContainerType::iterator dxdtiter = dxdt.begin();
derivative( start , dxdtiter );
while( start != end )
*start++ += dt * (*dxdtiter++);
}
template< class CallMethod , class StateContainer >
void do_step(
CallMethod derivative ,
double dt ,
StateContainer state )
{
do_step( derivative , dt , state.begin() , state.end() );
}
};
I think this design has all we need and is very flexible:
* no virtual functions are used anymode
* One can use the iterator and the container version
* CallMethod can be a function or a class, whatever one likes.
What we have to do now is, define how dxdt is created, which is indeed
not trivial.
> Concerning the current discussion:
> If the standard C-like usage (via functions) is not supported, as
> currently discussed and which is also my position, I would recommend to
> put the
> system's state definition (the ContainerType) into the dynamical_system
> class (or some derivation of it) as I did it in my
> lib. This is less error prone, since the user must not care about what
> kind of variable (s)he has to create for storing the state.
> In Mario's example with the harmonic oscillator the user has to provide
> the state-container-type twice, once to the stepper and to the system.
> The latter seems to be kind of redundant and should be part of the
> system and not the user's choice.
You are right, with the above approach this is possible but not necessary...
> In stepper:
> The current time point 't' should, if needed (as for non-autonomous
> systems), be part of the system's state and being integrated by the
> system using dt.
This is not possible, the time has to be a parameter. It will not work
in RK4 or others for the intermediate points.
Bye, Karsten
|
3 messages has been excluded from this view by a project administrator.
