basf / mopti Goto Github PK

The intent of the target value in ``MinimizeandMaximize` is for when the objective is used as an output constraint.
For example `Maximize("stability", target=0.5)` requires stability > 0.5. This should be clarified.

We could support transformations from inputs to specific objectives either in a general way or at least for some chemistry related quantities such as yield or selectivity.

The purpose of this would be to aid users by this consistency check when specifying constraints. Checking feasibility is only reasonably possible for linear constraints. To do this check we could try to solve a scipy.optimize.linprog problem.

See e.g. https://github.com/basf/mopti/runs/5549635953

where the first/last categorical level is dropped and make it the default.

Currently, it is not possible to randomly sample from problems that have n-choose-k-constraints and linear equality constraints on the same variables.

so that continous_parameters.round(X) can be always called.

problem jsons can always be made more readible by editors. For serialization they should be as compact as possible.

• remove formating
• omit empty domains
• option to omit data and optima

... to provide an interface for use in e.g. entmoot.

Instead of returning different fidelities at different call-frequencies we could implement separate columns for different fidelities.

It happens that one wants to do checks on the names of constraints of a problem (For example when we want to make sure that the constraints do not affect certain inputs). This is easily possible for linear constraints and nchoosek constraints, but not for nonlinear constraints, because nonlinear constraints do not have the names attribute. Would you accept a PR that adds an optional names attribute for nonlinear constraints? This way the user could provide information which variables are occuring in the nonlinear constraint's expression. This would allow for doing checks like the ones I mentioned above for all types of constraints.

Parameter names in the constraints need to be existent variables. See Problem.check_problem

Hi all,

I was looking in the documentation at the very nice Problem reduction page.

Can it be that you have an error in the first example?

For me the bounds for x3 should be the same before and after the transformation.

Best,

Johannes

Purpose: make graphs neater, remove possibilities for processing problems with names with special characters.
Can mimic some commercial solutions.
Store dictionary mapping to original column names.

Create functionality that sanitizes a problem.

• all continuous columns are normalized to [0, 1], if there are no non-linear constraints
• names of inputs and output are replaced by input_i or output_i.

opti.read_json() gives a

ValueError: Parameter x contains non-numeric values. Data for continuous / discrete parameters must be numeric. 

for the following json, containing a value in scientific notation.

{
  "inputs": [{"name": "x","type": "continuous"}],
  "outputs": [{"name": "y","type": "continuous"}],
  "data": {
    "data": [
      ["9E-01", 0.1],
      [2, 0.29]
    ],
    "index": [0, 1],
    "columns": ["x", "y"]
  }
}

AffineTransform.augment should readd columns at the original position.
This is just optics but it helps readibility.