If I am understanding your question correctly, you are interested in searching discontinuous spaces with rocketsled. If this is correct, you should not need any meetsConstraint function nor transformations into pretzel-space. Rocketsled has tools for handling these kinds of spaces.
The input constraints to all problems can be specified with the “dimensions” and (if needed) the “space_file” arguments to MissionControl.configure, regardless of MOO or single objective. The syntax for the dimensions argument is meant to be straightforward (can can be viewed in the comprehensive guide). It is a list of constraints in each dimension. Each constraint is either a tuple or list. Tuples of ints and floats indicate ranges (inclusive rectangular bounds). Lists of tuples, ints, or strings represent discrete, discontinuous points.
If you have a list of selected points in each dimension (i.e., x1 is only valid for values of [0.14, 0.13, 0.18, 0.99, 1000.0], x2 is only valid for [7.0, 19.5], etc.), rocketsled will handle this by generating the search space combinatorially. You can view some examples in the Doc’s Comprehensive Guide. One is reproduced below:
dimensions=[[1.332, 4.565, 19.030], [221.222, 221.0283, 221.099]]
This reductive example has 2 dimensions. Dim1 valid for [1.332, 4.565, 19.030] and Dim2 valid for [221.222, 221.0283, 221.099]. The entire search space is then 9 points.
2b. This isn’t in the docs, but you can also define each dimension individually using any of the allowed syntax. For example, the dimensions syntax
dimensions=[(1.0, 100.0), [221.222, 221.0283, 221.099], ["red", "blue", "green"]]
Defines the search space as x1 = all floats between 1 and 100, x2 = only 3 floats, and x3 = only 3 categories. The search space is then combinatorially generated - ranged dimensions are sampled uniformly.
- If you are interested in search spaces which are **not **combinatorially generated - i.e., only a few points in the space are actually valid - use the “space_file” argument (also detailed in the docs). This allows you to specify a python pickle file which rocketsled will read and use to define the space. This file is essentially a big list of allowed points which you can generate however you want. Thus you can define the space in whatever manner you desire without the limitations of the dimensions syntax.
For example, if your 2D space could be rectangularly outlined by x1 as floats between 0.1 and 0.9 and x2 as integers between 1 and 100, you could define your constrained search space to be only the points [0.75, 5], [0.1, 9] and [0.85, 99], and no other points. Just put those points in a list and save it as a pickle file, then tell rocketsled where to find it with space_file.
Note specifying space_file requires you to still define dimensions. These dimensions are used for some type-checking operations, not the actual search though.
If you have any problems using any of the above methods (outside of these issues), please let me know!
Also note that while using the builtin optimizers is the easiest method of optimization, they are not ideal for every (or any!) problem. They are general purpose by design. Thus you can specify the latest and greatest custom optimizer with the ‘predictor’ argument and use that instead. All the above arguments (1,2,3) should still work as long as your custom predictor can utilize the inputs rocketsled gives it (namely, a list of explored points, corresponding obj function outputs, and unexplored points). If your custom optimizer requires rectangular boundaries though, looks like you’ll need meetsConstraint or pretzel-space
On Friday, May 10, 2019 at 12:18:51 PM UTC-7, Dr. Andrew Strelzoff (USACE-DSRC) wrote:
We’re just getting started with Rocksled on DoD DSRC HPC. We have FireWorks running and both basic and complex RocketSled sample problems run. So far, so good.
Next step is to code up a few classic problems from wikipedia - https://en.wikipedia.org/wiki/Test_functions_for_optimization learning as we go and moving gradually towards actual motivating problems. My question is given a MOO problem what is the recommended way to add input constraints more complex than simple rectangular boundaries?
A simple way this might be achieved without a lot of heavy lifting would be in the objective task we could add a meetsConstraints() function prior to expensive function evaluation that returned a large penalty (distance from feasibility boundary?) - the underlying RL algorithm would learn to avoid out-of-constraint areas. Not sure if this would work.
Is there an example RocketSled problem with input constraints - both continuous and discrete would be nice. We have a lot of previous experience with non-RL MOO approaches which ususally involve taking a simple problem as described by a SME and twisting it up like a pretzel to try to get a convex problem description to work in SCIP… The idea of a RL-based optimizer that can solve arbitrarily posed mixed problems is incredibly interesting