roboptim-user Mailing List for RobOptim
Status: Beta
Brought to you by:
flamiraux
Menu
▾
▴
roboptim-user — User discussion
You can subscribe to this list here.
| 2009 |
Jan
|
Feb
|
Mar
|
Apr
(1) |
May
|
Jun
|
Jul
|
Aug
(3) |
Sep
(10) |
Oct
|
Nov
(2) |
Dec
|
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2010 |
Jan
|
Feb
(2) |
Mar
(8) |
Apr
(5) |
May
(1) |
Jun
|
Jul
(2) |
Aug
|
Sep
|
Oct
|
Nov
|
Dec
(1) |
| 2011 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
(2) |
Oct
|
Nov
|
Dec
|
|
From: Thomas M. <tho...@gm...> - 2011-09-21 08:26:53
|
On Wed, Sep 21, 2011 at 10:12 AM, Florent Lamiraux <fl...@la...> wrote: > Hello roboptim users, > > does anyone know whether there is a verbose mode in roboptim and if so > how to activate it ? > > I have an optimization problem that never ends and I would like to > understand what is happening. Hello, there is two possibilties: - enable libcwd support (http://libcwd.sourceforge.net/) by passing -DCWDEBUG as CXXFLAGS (using ccmake for instance) This has not been thoroughly tested and minor compilation errors may occur. - use the plug-in specific logging features using solver.parameters () method. In this case, take a look to the plug-in documentation / code to see what parameters are available. For instance, using the CFSQP plug-in, "cfsqp.iprint" can be used to dump intermediate steps. BTW, other options are also available to fine tune the KKT condition evaluation which decides whether the optimization should stop or not. -- Thomas Moulard |
|
From: Florent L. <fl...@la...> - 2011-09-21 08:12:50
|
Hello roboptim users, does anyone know whether there is a verbose mode in roboptim and if so how to activate it ? I have an optimization problem that never ends and I would like to understand what is happening. Florent Lamiraux |
|
From: Thomas M. <tho...@gm...> - 2010-12-09 17:41:15
|
Hello everyone, the Git repositories of RobOptim have been moved to GitHub, see the following links for more information: https://github.com/laas/roboptim-core https://github.com/laas/roboptim-core-plugin-ipopt https://github.com/laas/roboptim-trajectory In practice, you can either re-clone your RobOptim setup or simpliy do a "git remote rm origin" and "git remote add origin <url>" where <url> is the repository URL as given on the GitHub page. I have also added an experimental CMake branch which may help Microsoft Windows user. Thank you, -- Thomas Moulard http://www.linkedin.com/in/moulard |
|
From: Karim B. <kar...@gm...> - 2010-07-14 07:15:36
|
I attached the patch file. I hope this helps. Karim 2010/7/12 Thomas Moulard <tho...@gm...>: > On Tue, Mar 30, 2010 at 2:42 PM, Karim Bouyarmane > <kar...@gm...> wrote: >> For me it's ok. For now I just did some temporary hard-coding to bypass the >> TwiceDerivable limitation and I have simply rewritten the >> current IpoptSolver to derive from Solver<DerivableFunction, >> boost::mpl::vector<DerivableFunction> >. I will try to do this the clean way >> as you propose and send you the patch ASAP. > > Hi Karim, any news concerning that patch. People here at LAAS would be > interested by > your patch. Can you send it to us or can we talk about it next week in Japan? > > Thanks, > -- > Thomas Moulard > http://www.linkedin.com/in/moulard > |
|
From: Thomas M. <tho...@gm...> - 2010-07-12 10:12:46
|
On Tue, Mar 30, 2010 at 2:42 PM, Karim Bouyarmane <kar...@gm...> wrote: > For me it's ok. For now I just did some temporary hard-coding to bypass the > TwiceDerivable limitation and I have simply rewritten the > current IpoptSolver to derive from Solver<DerivableFunction, > boost::mpl::vector<DerivableFunction> >. I will try to do this the clean way > as you propose and send you the patch ASAP. Hi Karim, any news concerning that patch. People here at LAAS would be interested by your patch. Can you send it to us or can we talk about it next week in Japan? Thanks, -- Thomas Moulard http://www.linkedin.com/in/moulard |
|
From: Karim B. <kar...@gm...> - 2010-05-09 07:14:14
|
Hello,
I have finally pulled.
For the console output, since Francois added this line at the constructor of
the IpoptSolver:
app_->Jnlst()->DeleteAllJournals();
Then to enable back the console output we have to add these two lines just
after:
SmartPtr<Journal> stdout_jrnl = app_->Jnlst()->AddFileJournal("console",
"stdout", J_ITERSUMMARY);
stdout_jrnl->SetPrintLevel(J_DBG, J_NONE);
And by the way I have also found a typo at the struct IpoptParametersUpdater
level,
we should replace:
void operator () (const int& val) const
{
app->Options ()->SeNumericValue (key, val);
}
with:
void operator () (const int& val) const
{
app->Options ()->SeIntegerValue (key, val);
}
That's it for now.
A bientot
Karim
2010/4/19 Karim Bouyarmane <kar...@gm...>
> For now i have not yet pulled, I am still working on my own branch.
> As soon as I pull I will confirm.
>
> 2010/4/15 Thomas Moulard <tho...@gm...>
>
> On Wed, Mar 31, 2010 at 2:02 PM, Thomas Moulard
>> <tho...@gm...> wrote:
>> > On Wed, Mar 31, 2010 at 9:53 AM, Karim Bouyarmane
>> > <kar...@gm...> wrote:
>> >> Hello Thomas,
>> >>
>> >> I have another question about the Ipopt plugin. In the current
>> >> implementation of the IpoptSolver, the attribute IpoptApplication app_
>> is
>> >> created with the following call to the constructor
>> >> app_ (new IpoptApplication (false, false))
>> >> which disables the console output of ipopt and makes the use of the
>> >> print_level option useless
>> >> I think it would be better to create the IpoptApplication with the
>> first
>> >> boolean parameter set to "true"
>> >> app_ (new IpoptApplication (true, false))
>> >> and let the user decide of the desired verbosity, for example to
>> disable the
>> >> output:
>> >> solver.getIpoptApplication()->Options ()->SetIntegerValue
>> ("print_level",0);
>> >>
>> >> what do you think?
>> >
>> > In fact, since now RobOptim support parameters for solvers, print_level
>> should
>> > be one, like in CFSQP plug-in.
>> > This one is trivial. I'll fix that ASAP.
>>
>> Due to Francois's patches and to the merge of Linux and Windows
>> constructors
>> (see commit ed8668d4c5760f83f07ecf8f4dd35f1592565fc4), this problem should
>> be solved. Can you confirm it, Karim, Francois?
>> --
>> Thomas Moulard
>> http://www.linkedin.com/in/moulard
>>
>
>
|
|
From: Karim B. <kar...@gm...> - 2010-04-19 01:39:09
|
For now i have not yet pulled, I am still working on my own branch.
As soon as I pull I will confirm.
2010/4/15 Thomas Moulard <tho...@gm...>
> On Wed, Mar 31, 2010 at 2:02 PM, Thomas Moulard
> <tho...@gm...> wrote:
> > On Wed, Mar 31, 2010 at 9:53 AM, Karim Bouyarmane
> > <kar...@gm...> wrote:
> >> Hello Thomas,
> >>
> >> I have another question about the Ipopt plugin. In the current
> >> implementation of the IpoptSolver, the attribute IpoptApplication app_
> is
> >> created with the following call to the constructor
> >> app_ (new IpoptApplication (false, false))
> >> which disables the console output of ipopt and makes the use of the
> >> print_level option useless
> >> I think it would be better to create the IpoptApplication with the first
> >> boolean parameter set to "true"
> >> app_ (new IpoptApplication (true, false))
> >> and let the user decide of the desired verbosity, for example to disable
> the
> >> output:
> >> solver.getIpoptApplication()->Options ()->SetIntegerValue
> ("print_level",0);
> >>
> >> what do you think?
> >
> > In fact, since now RobOptim support parameters for solvers, print_level
> should
> > be one, like in CFSQP plug-in.
> > This one is trivial. I'll fix that ASAP.
>
> Due to Francois's patches and to the merge of Linux and Windows
> constructors
> (see commit ed8668d4c5760f83f07ecf8f4dd35f1592565fc4), this problem should
> be solved. Can you confirm it, Karim, Francois?
> --
> Thomas Moulard
> http://www.linkedin.com/in/moulard
>
|
|
From: Thomas M. <tho...@gm...> - 2010-04-14 16:51:58
|
On Mon, Apr 12, 2010 at 10:19 AM, Thomas Moulard <tho...@gm...> wrote: > On Tue, Apr 6, 2010 at 6:00 PM, Keith François <fra...@gm...> wrote: >> Hello Thomas > > Hi Francois, sorry I have been busy last week. I forgot to answer your mail. > >> As I have explained to you earlier, we encoutered some issues during the >> installation of roboptim-ipopt-plugin on windows >> For now, I have tested two solutions (both of them work): >> >> The first one is based on the pre-compiled version of ipopt that can be >> downloaded from the ipopt repository on the Internet. >> Using it, compiling the plugin is not straightforward and requires two >> modifications: >> >> Since the symbol corresponding to the constructor of IpoptApplication that >> is used in the constructor of IpoptSolver is not exported, the linkage >> fails. >> The alternative consists in using the IpoptApplicationFactory instead. >> Although it modifies the arguments passed to the constructor : (true, false) >> instead of (false, false), this can be corrected afterwards by destroying >> the journal created. >> >> Using the macro "HAVE_CONFIG_H" for the project and for all the project >> depending on roboptim (in order to avoid the inclusion of a config file that >> does not exist in the pre-compiled version of the library). >> >> The second solution is based on a ad-hoc compilation of the ipopt sources >> and is more burdensome. >> I won't go to much into details, but basically it consists in converting the >> libraries blas, lapack and hm in static libraries (without using the f2c >> compiler but instead the g77 compiler of mingw), and compiling ipopt as a >> static library as much. >> Then these four libraries can be linked by roboptim-core-ipopt-plugin, but >> also by all the programs that use roboptim-core-ipopt-plugin. >> >> >> As a result, and if you are ok with it, I propose to use the first solution, >> so as to be more user friendly. > > Yes, installing Ipopt is already quite difficult so first solution seems more > acceptable. > >> Besides, I'd like to make the inheritance of compilation flags (as the macro >> HAVE_CONFIG_H) of roboptim easier by installing the corresponding property >> sheet in the folder $(ROBOPTIM_INSTALL_DIR)/share/msvc >> Does it suit you? > > Ok for me. > > By the way, the problems you are reporting seems to be real Ipopt bugs. > Did you report them to the Ipopt mailing-list? Patches set sent by Francois has been successfully pushed to master yesterday. Problem solved. Thanks Francois! -- Thomas Moulard http://www.linkedin.com/in/moulard |
|
From: Thomas M. <tho...@gm...> - 2010-04-14 16:50:58
|
On Wed, Mar 31, 2010 at 2:02 PM, Thomas Moulard
<tho...@gm...> wrote:
> On Wed, Mar 31, 2010 at 9:53 AM, Karim Bouyarmane
> <kar...@gm...> wrote:
>> Hello Thomas,
>>
>> I have another question about the Ipopt plugin. In the current
>> implementation of the IpoptSolver, the attribute IpoptApplication app_ is
>> created with the following call to the constructor
>> app_ (new IpoptApplication (false, false))
>> which disables the console output of ipopt and makes the use of the
>> print_level option useless
>> I think it would be better to create the IpoptApplication with the first
>> boolean parameter set to "true"
>> app_ (new IpoptApplication (true, false))
>> and let the user decide of the desired verbosity, for example to disable the
>> output:
>> solver.getIpoptApplication()->Options ()->SetIntegerValue ("print_level",0);
>>
>> what do you think?
>
> In fact, since now RobOptim support parameters for solvers, print_level should
> be one, like in CFSQP plug-in.
> This one is trivial. I'll fix that ASAP.
Due to Francois's patches and to the merge of Linux and Windows constructors
(see commit ed8668d4c5760f83f07ecf8f4dd35f1592565fc4), this problem should
be solved. Can you confirm it, Karim, Francois?
--
Thomas Moulard
http://www.linkedin.com/in/moulard
|
|
From: Thomas M. <tho...@gm...> - 2010-04-12 08:19:59
|
On Tue, Apr 6, 2010 at 6:00 PM, Keith François <fra...@gm...> wrote: > Hello Thomas Hi Francois, sorry I have been busy last week. I forgot to answer your mail. > As I have explained to you earlier, we encoutered some issues during the > installation of roboptim-ipopt-plugin on windows > For now, I have tested two solutions (both of them work): > > The first one is based on the pre-compiled version of ipopt that can be > downloaded from the ipopt repository on the Internet. > Using it, compiling the plugin is not straightforward and requires two > modifications: > > Since the symbol corresponding to the constructor of IpoptApplication that > is used in the constructor of IpoptSolver is not exported, the linkage > fails. > The alternative consists in using the IpoptApplicationFactory instead. > Although it modifies the arguments passed to the constructor : (true, false) > instead of (false, false), this can be corrected afterwards by destroying > the journal created. > > Using the macro "HAVE_CONFIG_H" for the project and for all the project > depending on roboptim (in order to avoid the inclusion of a config file that > does not exist in the pre-compiled version of the library). > > The second solution is based on a ad-hoc compilation of the ipopt sources > and is more burdensome. > I won't go to much into details, but basically it consists in converting the > libraries blas, lapack and hm in static libraries (without using the f2c > compiler but instead the g77 compiler of mingw), and compiling ipopt as a > static library as much. > Then these four libraries can be linked by roboptim-core-ipopt-plugin, but > also by all the programs that use roboptim-core-ipopt-plugin. > > > As a result, and if you are ok with it, I propose to use the first solution, > so as to be more user friendly. Yes, installing Ipopt is already quite difficult so first solution seems more acceptable. > Besides, I'd like to make the inheritance of compilation flags (as the macro > HAVE_CONFIG_H) of roboptim easier by installing the corresponding property > sheet in the folder $(ROBOPTIM_INSTALL_DIR)/share/msvc > Does it suit you? Ok for me. By the way, the problems you are reporting seems to be real Ipopt bugs. Did you report them to the Ipopt mailing-list? -- Thomas Moulard http://www.linkedin.com/in/moulard |
|
From: Keith F. <fra...@gm...> - 2010-04-06 16:01:06
|
Hello Thomas As I have explained to you earlier, we encoutered some issues during the installation of roboptim-ipopt-plugin on windows For now, I have tested two solutions (both of them work): The first one is based on the pre-compiled version of ipopt that can be downloaded from the ipopt repository on the Internet. Using it, compiling the plugin is not straightforward and requires two modifications: 1. Since the symbol corresponding to the constructor of IpoptApplication that is used in the constructor of IpoptSolver is not exported, the linkage fails. The alternative consists in using the IpoptApplicationFactory instead. Although it modifies the arguments passed to the constructor : (true, false) instead of (false, false), this can be corrected afterwards by destroying the journal created. 2. Using the macro "HAVE_CONFIG_H" for the project and for all the project depending on roboptim (in order to avoid the inclusion of a config file that does not exist in the pre-compiled version of the library). The second solution is based on a ad-hoc compilation of the ipopt sources and is more burdensome. I won't go to much into details, but basically it consists in converting the libraries blas, lapack and hm in static libraries (*without* using the f2c compiler but instead the g77 compiler of mingw), and compiling ipopt as a static library as much. Then these four libraries can be linked by roboptim-core-ipopt-plugin, but also by all the programs that use roboptim-core-ipopt-plugin. As a result, and if you are ok with it, I propose to use the first solution, so as to be more user friendly. Besides, I'd like to make the inheritance of compilation flags (as the macro HAVE_CONFIG_H) of roboptim easier by installing the corresponding property sheet in the folder $(ROBOPTIM_INSTALL_DIR)/share/msvc Does it suit you? François |
|
From: Thomas M. <tho...@gm...> - 2010-03-31 12:02:14
|
On Wed, Mar 31, 2010 at 9:53 AM, Karim Bouyarmane
<kar...@gm...> wrote:
> Hello Thomas,
>
> I have another question about the Ipopt plugin. In the current
> implementation of the IpoptSolver, the attribute IpoptApplication app_ is
> created with the following call to the constructor
> app_ (new IpoptApplication (false, false))
> which disables the console output of ipopt and makes the use of the
> print_level option useless
> I think it would be better to create the IpoptApplication with the first
> boolean parameter set to "true"
> app_ (new IpoptApplication (true, false))
> and let the user decide of the desired verbosity, for example to disable the
> output:
> solver.getIpoptApplication()->Options ()->SetIntegerValue ("print_level",0);
>
> what do you think?
In fact, since now RobOptim support parameters for solvers, print_level should
be one, like in CFSQP plug-in.
This one is trivial. I'll fix that ASAP.
--
Thomas Moulard
http://www.linkedin.com/in/moulard
|
|
From: Karim B. <kar...@gm...> - 2010-03-31 07:54:12
|
Hello Thomas,
I have another question about the Ipopt plugin. In the current
implementation of the IpoptSolver, the attribute IpoptApplication app_ is
created with the following call to the constructor
app_ (new IpoptApplication (false, false))
which disables the console output of ipopt and makes the use of the
print_level option useless
I think it would be better to create the IpoptApplication with the first
boolean parameter set to "true"
app_ (new IpoptApplication (true, false))
and let the user decide of the desired verbosity, for example to disable the
output:
solver.getIpoptApplication()->Options ()->SetIntegerValue ("print_level",0);
what do you think?
Karim
|
|
From: Karim B. <kar...@gm...> - 2010-03-30 12:42:59
|
For me it's ok. For now I just did some temporary hard-coding to bypass the
TwiceDerivable limitation and I have simply rewritten the
current IpoptSolver to derive from Solver<DerivableFunction,
boost::mpl::vector<DerivableFunction> >. I will try to do this the clean way
as you propose and send you the patch ASAP.
Karim
2010/3/30 Thomas Moulard <tho...@gm...>
> On Tue, Mar 30, 2010 at 2:58 AM, Pierre-Brice Wieber
> <pie...@in...> wrote:
> > From a theoretical point of view, IPOPT requires a twice
> > differentiable function (and not derivable, in english, this is a
> mistake).
> > One possibility would be to define your twice differentiable function
> with a
> > dummy second derivative together with one way to indicate to IPOPT to
> > override your dummy second derivative with its own approximation. Don't
> know
> > exactly how to do it best from a software design point of view: any idea,
> > Thomas on indicating that one method is "undefined" and should be
> overriden
> > by the calling class?
> > PB.
> >
> >
> > Le 30 mars 2010 à 09:47, Karim Bouyarmane a écrit :
> >
> > Hello Thomas,
> >
> > I am trying to use IPOPT as a core plugin solver, to compare results with
> > CFSQP. To instanciate the IpoptSolver we have to define a problem with
> twice
> > derivable functions. However IPOPT provides the possibiliity of
> > approximating the Hessians of the functions, as stated in this quotation
> > from p 35 of IPOPT manual :
> > "Ipopt has an option to approximate the Hessian of the Lagrangian by a
> > limited-memory quasi-Newton method (L-BFGS). You can use this feature
> using
> > the hessian_approximation and limited_memory options. In this case, it is
> > not necessary to implement the Hessian computation method eval_h in
> TNLP."
> > It should be useful if we could use this feature and not have to provide
> > necessarily TwiceDerivableFunction to the IpoptSolver.
> > What do you think?
>
> Hello Karim, Pierre-Brice,
> it would definitively be a nice add for the current Ipopt plug-in.
>
> IMHO, to preserve strong static typing, the best solution would be to
> implement
> two solver classes for Ipopt. One using the default behavior and one
> using the quasi-Newton
> method. Two plug-ins would be packaged and the would choose directly
> what algorithm will be used.
>
> The advantages would be:
> - the choice of the algorithm (and its associated complexity) would
> remain explicit for the user,
> - RobOptim core functions remains ``pure'' (i.e. no numerical
> optimization related features).
> - implementation is quite straight-forward :)
>
> The required work would be to move from 1 source file in src to three:
> - the Ipopt generic sovler which factorize code
> - the two RobOptim solvers (with/wihout quasi-Newton)
>
> We would have something like this:
>
> class IpoptGenericSolver {};
> class IpoptSolver : public IpoptGenericSolver,
> Solver<TwiceDerivableFunction,
>
> boost::mpl::vector<TwiceDerivableFunction> > {};
> class IpoptSolverQuasiNewton : public IpoptGenericSolver,
>
> Solver<DerivableFunction,
>
> boost::mpl::vector<DerivableFunction> > {};
>
> What do you think?
>
> @Pierre-Brice: at some point, I will replace all the TwiceDeriable by
> TwiceDifferentiable and provide
> a typedef for backward-compatibility.
>
> @Karim: would you have time to propose a patch for this?
>
> I can do it but I'm lacking time this week and I'm taking some
> holidays the week after so
> it may take some time before I add this feature.
> --
> Thomas Moulard
> http://www.linkedin.com/in/moulard
>
|
|
From: Thomas M. <tho...@gm...> - 2010-03-30 09:47:31
|
On Tue, Mar 30, 2010 at 2:58 AM, Pierre-Brice Wieber
<pie...@in...> wrote:
> From a theoretical point of view, IPOPT requires a twice
> differentiable function (and not derivable, in english, this is a mistake).
> One possibility would be to define your twice differentiable function with a
> dummy second derivative together with one way to indicate to IPOPT to
> override your dummy second derivative with its own approximation. Don't know
> exactly how to do it best from a software design point of view: any idea,
> Thomas on indicating that one method is "undefined" and should be overriden
> by the calling class?
> PB.
>
>
> Le 30 mars 2010 à 09:47, Karim Bouyarmane a écrit :
>
> Hello Thomas,
>
> I am trying to use IPOPT as a core plugin solver, to compare results with
> CFSQP. To instanciate the IpoptSolver we have to define a problem with twice
> derivable functions. However IPOPT provides the possibiliity of
> approximating the Hessians of the functions, as stated in this quotation
> from p 35 of IPOPT manual :
> "Ipopt has an option to approximate the Hessian of the Lagrangian by a
> limited-memory quasi-Newton method (L-BFGS). You can use this feature using
> the hessian_approximation and limited_memory options. In this case, it is
> not necessary to implement the Hessian computation method eval_h in TNLP."
> It should be useful if we could use this feature and not have to provide
> necessarily TwiceDerivableFunction to the IpoptSolver.
> What do you think?
Hello Karim, Pierre-Brice,
it would definitively be a nice add for the current Ipopt plug-in.
IMHO, to preserve strong static typing, the best solution would be to implement
two solver classes for Ipopt. One using the default behavior and one
using the quasi-Newton
method. Two plug-ins would be packaged and the would choose directly
what algorithm will be used.
The advantages would be:
- the choice of the algorithm (and its associated complexity) would
remain explicit for the user,
- RobOptim core functions remains ``pure'' (i.e. no numerical
optimization related features).
- implementation is quite straight-forward :)
The required work would be to move from 1 source file in src to three:
- the Ipopt generic sovler which factorize code
- the two RobOptim solvers (with/wihout quasi-Newton)
We would have something like this:
class IpoptGenericSolver {};
class IpoptSolver : public IpoptGenericSolver,
Solver<TwiceDerivableFunction,
boost::mpl::vector<TwiceDerivableFunction> > {};
class IpoptSolverQuasiNewton : public IpoptGenericSolver,
Solver<DerivableFunction,
boost::mpl::vector<DerivableFunction> > {};
What do you think?
@Pierre-Brice: at some point, I will replace all the TwiceDeriable by
TwiceDifferentiable and provide
a typedef for backward-compatibility.
@Karim: would you have time to propose a patch for this?
I can do it but I'm lacking time this week and I'm taking some
holidays the week after so
it may take some time before I add this feature.
--
Thomas Moulard
http://www.linkedin.com/in/moulard
|
|
From: Pierre-Brice W. <pie...@in...> - 2010-03-30 00:58:58
|
From a theoretical point of view, IPOPT requires a twice differentiable function (and not derivable, in english, this is a mistake). One possibility would be to define your twice differentiable function with a dummy second derivative together with one way to indicate to IPOPT to override your dummy second derivative with its own approximation. Don't know exactly how to do it best from a software design point of view: any idea, Thomas on indicating that one method is "undefined" and should be overriden by the calling class? PB. Le 30 mars 2010 à 09:47, Karim Bouyarmane a écrit : > Hello Thomas, > > I am trying to use IPOPT as a core plugin solver, to compare results with CFSQP. To instanciate the IpoptSolver we have to define a problem with twice derivable functions. However IPOPT provides the possibiliity of approximating the Hessians of the functions, as stated in this quotation from p 35 of IPOPT manual : > "Ipopt has an option to approximate the Hessian of the Lagrangian by a limited-memory quasi-Newton method (L-BFGS). You can use this feature using the hessian_approximation and limited_memory options. In this case, it is not necessary to implement the Hessian computation method eval_h in TNLP." > It should be useful if we could use this feature and not have to provide necessarily TwiceDerivableFunction to the IpoptSolver. > What do you think? > > Karim > ------------------------------------------------------------------------------ > Download Intel® Parallel Studio Eval > Try the new software tools for yourself. Speed compiling, find bugs > proactively, and fine-tune applications for parallel performance. > See why Intel Parallel Studio got high marks during beta. > http://p.sf.net/sfu/intel-sw-dev_______________________________________________ > roboptim-user mailing list > rob...@li... > https://lists.sourceforge.net/lists/listinfo/roboptim-user |
|
From: Karim B. <kar...@gm...> - 2010-03-30 00:47:26
|
Hello Thomas, I am trying to use IPOPT as a core plugin solver, to compare results with CFSQP. To instanciate the IpoptSolver we have to define a problem with twice derivable functions. However IPOPT provides the possibiliity of approximating the Hessians of the functions, as stated in this quotation from p 35 of IPOPT manual : "Ipopt has an option to approximate the Hessian of the Lagrangian by a limited-memory quasi-Newton method (L-BFGS). You can use this feature using the hessian_approximation and limited_memory options. In this case, it is not necessary to implement the Hessian computation method eval_h in TNLP." It should be useful if we could use this feature and not have to provide necessarily TwiceDerivableFunction to the IpoptSolver. What do you think? Karim |
|
From: Thomas M. <tho...@gm...> - 2010-03-10 18:11:50
|
On Tue, Mar 9, 2010 at 12:59 PM, Karim Bouyarmane <kar...@ai...> wrote: > Hello Thomas, > > I am using CFSQP as a core solver and I would like to change the value of > the input variable gLgeps which is used as a stopping criterion on the norm > of the KKT vector, as described in page 23 of the CFSQP Manual. The variable > is defined in the file cfsqpusr.h, is there a way to change it using a > function like solver.gLgeps() like other input variables (for example for > the input variable epseqn I can use solver.epseqn()=myValue), or do I have > to bypass the RobOptim layer and act directly on the CFSQP core solver? > > Thank you in advance, Hi Karim, I have integrated this change in the last commit of CFSQP plug-in (today, commit 584d592). Starting from roboptim-core-0.5.6, parameters have been unified and cleaned in RobOptim. Now, you can do: solver.parameters ()["cfsqp.gLgeps"].value = 0.5; ...to change a parameter. In previous versions, there is no way to modify directly this value. I strongly encourage you to upgrade to get bug fixes and new features such as parameters management. BTW, I also have added a ``split'' filter which allows to easily use non-scalar functions[1] as a constraint. The overhead due to multiple gradient computation can be avoided by associating it with the cache filter[2]. [1] http://roboptim.git.sourceforge.net/git/gitweb.cgi?p=roboptim/core.git;a=blob_plain;f=tests/split.cc;hb=HEAD [2] http://roboptim.git.sourceforge.net/git/gitweb.cgi?p=roboptim/core.git;a=blob_plain;f=tests/cached-function.cc;hb=HEAD -- Thomas Moulard |
|
From: Karim B. <kar...@ai...> - 2010-03-09 11:59:52
|
Hello Thomas, I am using CFSQP as a core solver and I would like to change the value of the input variable gLgeps which is used as a stopping criterion on the norm of the KKT vector, as described in page 23 of the CFSQP Manual. The variable is defined in the file cfsqpusr.h, is there a way to change it using a function like solver.gLgeps() like other input variables (for example for the input variable epseqn I can use solver.epseqn()=myValue), or do I have to bypass the RobOptim layer and act directly on the CFSQP core solver? Thank you in advance, Karim |
|
From: Thomas M. <tho...@gm...> - 2010-02-27 13:07:01
|
On Sat, Feb 27, 2010 at 12:45 PM, Florent Lamiraux <fl...@la...> wrote: > Hello Thomas, > > When installing roboptim-core-0.5 from source, the installed > roboptim-core.pc file is not correct. > PACKAGE_TARNAME in line docdir= shoud be either defined or substituted. > Please find attached the file produced. Unfortunately, this problem has been fixed after the release. I propose that either: - I release 0.6 (so that we can have new parameters management too) but it may take a couple of days as parameters management has not yet been fully tested. - you set docdir manually (./configure --docdir=/path/to/doc) when building, when doing that there will be no variable in the path. - you synchronize with a fixed build-aux submodule either by running cd build-aux && git reset --hard 14aa3be6d78cc04a7f009f2799edbdb1b8b76e05 14aa3be6d78cc04a7f009f2799edbdb1b8b76e05 is the build-aux commit fixing this issue. You can also extract a patch from this commit and patch locally. Sorry for the troubles, -- Thomas Moulard |
|
From: Florent L. <fl...@la...> - 2010-02-27 12:00:42
|
Hello Thomas, When installing roboptim-core-0.5 from source, the installed roboptim-core.pc file is not correct. PACKAGE_TARNAME in line docdir= shoud be either defined or substituted. Please find attached the file produced. Florent |
|
From: <tho...@gm...> - 2009-11-16 18:19:35
|
We are pleased to announce the release of RobOptim trajectory 0.4. RobOptim provide C++ numerical optimization libraries for robotics. RobOptim trajectory focuses on providing trajectory computation classes and tools to define trajectory optimization problems. Here are the compressed sources: http://dl.sourceforge.net/roboptim/roboptim-trajectory-0.4.tar.gz (520KB) http://dl.sourceforge.net/roboptim/roboptim-trajectory-0.4.tar.bz2 (404KB) Here are the GPG detached signatures[*]: http://dl.sourceforge.net/roboptim/roboptim-trajectory-0.4.tar.gz.sig http://dl.sourceforge.net/roboptim/roboptim-trajectory-0.4.tar.bz2.sig Here are the MD5 and SHA1 checksums: 6d0778c7c81395bc44b5f9042bfc6ead roboptim-trajectory-0.4.tar.gz 14d18a480c1631b7c0896885907e0c5e roboptim-trajectory-0.4.tar.bz2 570da1cbe1967740302ac6561479a2381320dcc5 roboptim-trajectory-0.4.tar.gz 9d28095b22365ba35a64733871b9e56f852eec78 roboptim-trajectory-0.4.tar.bz2 [*] You can use either of the above signature files to verify that the corresponding file (without the .sig suffix) is intact. First, be sure to download both the .sig file and the corresponding tarball. Then, run a command like this: gpg --verify roboptim-trajectory-0.4.tar.gz.sig If that command fails because you don't have the required public key, then run this command to import it: gpg --keyserver keys.gnupg.net --recv-keys B140BA9E and rerun the `gpg --verify' command. announce-gen: ../NEWS: no matching lines for `0.4' This release was bootstrapped with the following tools: Autoconf 2.63 Automake 1.11 Libtool 2.2.6 You can fetch the unbootstrapped source code with git by using the following commands: $ git clone git://roboptim.git.sourceforge.net/gitroot/roboptim/trajectory.git $ cd roboptim-trajectory $ git checkout v0.4 NEWS: New in 0.4, 2009-11-16: * Fixed /severe/ computation bugs. * Clean interface. * Document. * Misc. bug fix. -- Thomas Moulard |
|
From: <tho...@gm...> - 2009-11-16 18:14:44
|
We are pleased to announce the release of RobOptim core 0.4. RobOptim provide C++ numerical optimization libraries for robotics. RobOptim core focuses on providing abstractions for optimization problem definition and infrastructure to allow the use of existing solvers as a back-end. Here are the compressed sources: http://dl.sourceforge.net/roboptim/roboptim-core-0.4.tar.gz (488KB) http://dl.sourceforge.net/roboptim/roboptim-core-0.4.tar.bz2 (396KB) Here are the GPG detached signatures[*]: http://dl.sourceforge.net/roboptim/roboptim-core-0.4.tar.gz.sig http://dl.sourceforge.net/roboptim/roboptim-core-0.4.tar.bz2.sig Here are the MD5 and SHA1 checksums: 9c028dbf51fc446392a86de7e826a50c roboptim-core-0.4.tar.gz 76803e842f30cf60536e5ba232f142d2 roboptim-core-0.4.tar.bz2 0942a5f59a031e7f8fa9bb95d9def81e014b7e5a roboptim-core-0.4.tar.gz 9a3a44a5f3c43421c0c87ecbedfa698dbe8eae9d roboptim-core-0.4.tar.bz2 [*] You can use either of the above signature files to verify that the corresponding file (without the .sig suffix) is intact. First, be sure to download both the .sig file and the corresponding tarball. Then, run a command like this: gpg --verify roboptim-core-0.4.tar.gz.sig If that command fails because you don't have the required public key, then run this command to import it: gpg --keyserver keys.gnupg.net --recv-keys FIXME and rerun the `gpg --verify' command. This release was bootstrapped with the following tools: Autoconf 2.63 Automake 1.11 Libtool 2.2.6 You can fetch the unbootstrapped source code with git by using the following commands: $ git clone git://roboptim.git.sourceforge.net/gitroot/roboptim/core.git $ cd roboptim-core $ git checkout v0.4 NEWS: New in 0.4, 2009-11-16: * Make plug-in loading more robust. * Enhanced gradient checks. * Handle symbol visibility under Linux properly. * Uniformized floating point number display. * Bug fix -- Thomas Moulard |
|
From: Thomas M. <tho...@gm...> - 2009-09-25 21:23:44
|
The RobOptim team is pleased to announce the stable release of roboptim-core 0.3. RobOptim is a generic C++ non-linear optimization library which focuses on humanoid robotics' optimization problems. The "core" level is generic and solve generic non-linear optimization problems. This version of roboptim-core is distributed under LGPLv3 license. This is the third public release of this software which should be much more stable than the previous ones. As the last release was done about six months ago, many changes have been made to the library and it is recommended to update your code to this new version. Please report any problems to the rob...@li... mailing list. In particular, if 'make check' fails, attaching the resulting ``tests/testsuite.log'' file is an integral part of a good bug report. Homepage: http://roboptim.sourceforge.net/ On-line documentation: http://roboptim.sourceforge.net/doc/core/0.3/ Here are the compressed sources: http://sourceforge.net/projects/roboptim/files/roboptim-core/0.3/roboptim-core-0.3.tar.gz/download (472KB) http://sourceforge.net/projects/roboptim/files/roboptim-core/0.3/roboptim-core-0.3.tar.bz2/download (380KB) Here are the GPG detached signatures[*]: http://sourceforge.net/projects/roboptim/files/roboptim-core/0.3/roboptim-core-0.3.tar.gz.sig/download http://sourceforge.net/projects/roboptim/files/roboptim-core/0.3/roboptim-core-0.3.tar.bz2.sig/download Here are the MD5 and SHA1 checksums: 26a3fb1850e1619655674b180f212845 roboptim-core-0.3.tar.gz 2e46f0bd4d5dfe1e7b767ebabce56670 roboptim-core-0.3.tar.bz2 28152754e99dee0a3d2466ae9fb0b91968cbeb04 roboptim-core-0.3.tar.gz 694525b0c7b72ebe77285c30fac29950f3b5c384 roboptim-core-0.3.tar.bz2 [*] You can use either of the above signature files to verify that the corresponding file (without the .sig suffix) is intact. First, be sure to download both the .sig file and the corresponding tarball. Then, run a command like this: gpg --verify roboptim-core-0.3.tar.gz.sig If that command fails because you don't have the required public key, then run this command to import it: gpg --keyserver keys.gnupg.net --recv-keys B140BA9E and rerun the `gpg --verify' command. This release was bootstrapped with the following tools: Autoconf 2.63 Automake 1.11 Libtool 2.2.6 ../NEWS New in 0.3, 2009-09-25: * Finite difference gradients * New kinds of functions: constant, identity function. * Enhance display of problem, solver, functions. * Experimental support for parametrized functions. * Numerous bug fixes. -- Thomas Moulard |
|
From: Thomas M. <tho...@gm...> - 2009-09-25 08:18:39
|
On Fri, Sep 25, 2009 at 9:42 AM, Florent Lamiraux <fl...@la...> wrote: > Hello Thomas, > > I just clone and compiled roboptim/core-plugin/cfsqp. A few warnings prevent > compilation of src/ofsqp.cc (mainly uninitialized variables). > > I suggest either to remove -Werror in configure.ac or to apply the attached > patch to cfsqp source code. > > You decide. Patch applied in commit aade7f8973b2c81dfb5c982144e010a50e1b8c69. Thanks for reporting! -- Thomas Moulard http://www.linkedin.com/in/moulard |
