Task #708

Refactor options module to support adjusting option settings after creation

Added by Teemu Murtola almost 10 years ago. Updated almost 7 years ago.

core library
Target version:


In analysis tools, the number of selections (or the flags for the required selections) required may in some cases be known only after other options have been parsed. To make interactive selection input work well in such cases, these changed settings should be updated in the request for interactive input. Implementing all this access to go through SelectionOptionStorage would make it cleanest: all user input checking could be done there, both when the selections have already been provided on the command line, or when the selections will be provided interactively later. However, the storage objects are not designed to be exposed to the callers; the mutable parts should either be refactored to a separate class, or a wrapper class implemented.

This feature could either be implemented just for selection options (keeps the core options module a bit simpler), or it could be made more general by making a similar refactoring in AbstractOptionStorage. Even in the first case, AbstractOptionStorage still needs to be adapted to support changing the limits for the number of values at any point.

Related issues

Related to GROMACS - Task #839: Improve OptionsIterator/OptionsGlobalProperties interfaceClosed11/14/2011
Blocks GROMACS - Task #665: Port existing trajectory analysis tools to use the new frameworkNew03/27/2012

Associated revisions

Revision a37cc2e5 (diff)
Added by Teemu Murtola almost 10 years ago

Combined and renamed options-related files.

Merged *optionstorage.cpp files into corresponding *option.cpp files,
because there was no real reason to have them separate, and this will
make it easier to find all code related a certain option. In particular
with issue #708, which will introduce classes whose definition should go
to the *option.h header file, but whose implementation would be more
natural in *optionstorage.cpp.

Refactoring in preparation for IssueID #708.

Revision 9aa9d065 (diff)
Added by Teemu Murtola almost 10 years ago

Allow selection option adjustment after creation.

Added functionality that allows one to adjust selection options (e.g.,
the number of selections required) based on values of other options.

IssueID #708

Revision 6207afb9 (diff)
Added by Teemu Murtola almost 10 years ago

Bug fixes to previous commit.

The angle tool did not work properly due to a few bugs in the previous
commit. Changed the analysis module interface slightly to provide an
error reporter to where it's needed. Also fixed some error messages.

IssueID #708


#1 Updated by Teemu Murtola almost 10 years ago

  • Status changed from New to In Progress
  • Assignee set to Teemu Murtola

#2 Updated by Teemu Murtola almost 10 years ago

  • Status changed from In Progress to Closed

Took the simplest way, and implemented a wrapper class that provides an interface that allows adjusting options after creation. The wrapper simply passes the calls to the storage object for actual processing to keep the logic in one place. This design keeps the core options module as simple as possible, and keeps the storage object well isolated from users.

Only implemented this for SelectionOption, but the more general parts of the implemented SelectionOptionAdjuster should be easy to refactor out to allow them to be reused for other options if the need ever arises.

#3 Updated by Teemu Murtola almost 7 years ago

  • Related to Task #839: Improve OptionsIterator/OptionsGlobalProperties interface added

#4 Updated by Teemu Murtola almost 7 years ago

  • Project changed from Next-generation analysis tools to GROMACS
  • Category set to core library
  • Target version set to 5.0

Also available in: Atom PDF