Fwd: [Coin-discuss] parameter parser

Carl Laird carl.d.laird at gmail.com
Thu Feb 15 13:08:07 EST 2007


Hello, let me join the discussion about these items.

Options list...
As far as overriding the values set in the options list, this is not a
problem. As Andreas mentioned, we have written the class to be a
little Ipopt specific in the order that we would like things
overridden. Currently, when we read from a file, we load that option
with a "no clobber" flag - this way, we can use the options file to
override options that may have been explicitly set by the executable.
This was a bit of a kludge, and it would be straightforward to add
some sort of priority mechanism to give complete flexibility. If there
is interest here, then we could make this class more general.

As far as the other items, things are pretty general with the
exception of the Journalist. A message is flagged with a category and
a level. If a Journal exists which is printing this category and
level, then the message is sent to that Journal. While this gives a
tremendous amount of flexibility, currently the list of categories and
levels are Ipopt  (Bonmin) specific enums. We could simply allow each
project to set their own categories and levels (which would have to be
defined outside the Journalist files) or make some modification of
this class to allow a general registry of categories and levels.


Hope this helps,

Carl.



On 2/12/07, Andreas Waechter <andreasw at watson.ibm.com > wrote:
> Hi
>
> > I looked at your OptionsList class. I think I see how to register options and
> > how to read options from a file. Is it possible to read from a file, but then
> > override an option at the command line?
> >
> > For example - how would I do something like:
> >
> > opts.txt:
> > optionA = 2
> > optionB= "ddd"
> >
> > ./myapp --param opts.txt --optionA 4
> >
> > which would read opts.txt, but then override option1 to 4 based on command
> > line?
>
> That the moment, the options stuff in Ipopt is somewhat tailored to the
> needs in Ipopt and Bonmin (which uses it too), but there is no reason why
> we couldn't add features like the one you just described.
>
> There a few things in the Ipopt/src/Common directory that might be of more
> general use (when we wrote it, we purposely tried to make it general), and
> of course I wouldn't mind if that would move to CoinUtils.
>
> Here are three funcitonalities that might be useful to others:
>
> - An implementation of smart pointers (IpSmartPtr.hpp):
>
>    A templated pointer class that does reference counting and automatically
>    deletes objects when they are no longer referenced.
>    Possible inconveniences here are that everything that is pointed to has
>    to inherit off of a "ReferencedObject", and that circular references
>    must be avoided.
>
> - The options list (as discussed above):
>
>    Here, the algorithm developer "registers" options at the beginning of
>    the program execution (at some point we had an automatic initialization
>    using the C++'s automatic initialization, but that didn't work on some
>    platforms when the main program was written in Fortran).  Those options
>    can then be "set" by the user in different forms and their value can be
>    recieved later by the algorithm (if the user didn't set the value, a
>    default value is returned).  When an option is registered, one also
>    provides a short and a detailed descrptions that can be printed later.
>    (Currently this is a little crued, but of course that could be
>    improved.)
>
> - A Journalist class (IpJournalist.hpp):
>
>    This allows to have a number of "journals", different output "channels"
>    to be opened and to be used to write different information in different
>    degree of details.  In the algorithm code, one then specifies a "level"
>    and a category, and the information is then written to all journals that
>    correspond to that.
>
> - A caching mechanism for computational results (IpCachedResults.hpp):
>
>    This mechanism allows to "cache" certain results, such as the outcome of
>    a (nonlinear) problem function evaluations.  For this, we define
>    quantities on which the results depend on (such as a vector).  The
>    vector has a unique tag, which is changed whenever the value of the
>    vector is changed.  All this is set up so that one usually doens't need
>    to worry about any of this when writing the regular code.
>
> Carl Laird had implemented those nice features when we started the
> reimplemetation of the Ipopt code in C++.  I'm copying him explicitly (not
> sure if he is subscribed to this mailing list), and he might want to add
> more information.
>
> I think that those are really useful tools, and they might be helpful to
> others.  Currently, they might not yet be as general so that they can be
> used by everybody, but of course we could improve that.  The only thing is
> to find time to do that... :)
>
> Cheers
>
> Andreas
>
>



More information about the Coin-discuss mailing list