yunshengtian / dgemo Goto Github PK

I get this error when running the code. I really appreciate it if you help me. Please note that I used to run this code about a year ago with the same setting without any errors.

Traceback (most recent call last):

File "/local/Navid/DGEMO2/DGEMO/main.py", line 57, in
main()
File "/local/Navid/DGEMO2/DGEMO/main.py", line 34, in main
exporter = DataExport(optimizer, X_init, Y_init, args)
File "/local/Navid/DGEMO2/DGEMO/visualization/data_export.py", line 69, in init
self.export_approx_pareto = pd.DataFrame(columns=column_names) # export pareto approximation data
File "/home/navid/.local/lib/python3.7/site-packages/pandas/core/frame.py", line 411, in init
mgr = init_dict(data, index, columns, dtype=dtype)
File "/home/navid/.local/lib/python3.7/site-packages/pandas/core/internals/construction.py", line 242, in init_dict
val = construct_1d_arraylike_from_scalar(np.nan, len(index), nan_dtype)
File "/home/navid/.local/lib/python3.7/site-packages/pandas/core/dtypes/cast.py", line 1221, in construct_1d_arraylike_from_scalar
dtype = dtype.dtype
AttributeError: type object 'object' has no attribute 'dtype'

Hi,

Thank you for sharing your interesting work!
I am wondering if it is possible for the algorithm to deal with categorical variables? Any recommendation on that? Thanks.

Hi,
I am having trouble interpreting the output of DGEMO algorithm (EvaluatedSamples/ParetoFrontEvaluated/ParetoFrontApproximation).csv
Where can I find more information about the meaning of these outputs? my guess is 'ParetoFrontApproximation' is the value that is returned by the surrogate model and 'ParetoFrontEvaluated' are the actual value of pareto set when evaluating the actual function, am I right?
But I have no idea about 'EvaluatedSamples'.
I would appreciate if you refer me to a source where I can find more information.

I'm not sure how to fix this error when I run the example: python main.py --problem dtlz1 --n-var 6 --n-obj 2 --n-iter 20

File "main.py", line 57, in
main()
File "main.py", line 45, in main
X_next, Y_next = next(solution)
File "C:\User\DGEMO-master\mobo\mobo.py", line 105, in solve
solution = self.solver.solve(surr_problem, X, Y)
File "C:\User\DGEMO-master\mobo\solver\solver.py", line 36, in solve
algo = self.algo_type(sampling=sampling, **self.algo_kwargs)
File "C:\User\DGEMO-master\mobo\solver\pareto_discovery\pareto_discovery.py", line 376, in init
self.initialization = Initialization(sampling,
TypeError: init() got an unexpected keyword argument 'individual'

ParetoDiscovery optimizing: generation 2Traceback (most recent call last):
File "/Users/zhengli/Desktop/Code/DGEMO-master/main.py", line 57, in
main()
File "/Users/zhengli/Desktop/Code/DGEMO-master/main.py", line 45, in main
X_next, Y_next = next(solution)
File "/Users/zhengli/Desktop/Code/DGEMO-master/mobo/mobo.py", line 105, in solve
solution = self.solver.solve(surr_problem, X, Y)
File "/Users/zhengli/Desktop/Code/DGEMO-master/mobo/solver/solver.py", line 39, in solve
res = minimize(problem, algo, ('n_gen', self.n_gen))
File "/Users/zhengli/anaconda3/lib/python3.10/site-packages/pymoo/optimize.py", line 65, in minimize
res = algorithm.solve()
File "/Users/zhengli/anaconda3/lib/python3.10/site-packages/pymoo/model/algorithm.py", line 183, in solve
self._solve(self.problem)
File "/Users/zhengli/anaconda3/lib/python3.10/site-packages/pymoo/model/algorithm.py", line 264, in _solve
self.next()
File "/Users/zhengli/anaconda3/lib/python3.10/site-packages/pymoo/model/algorithm.py", line 235, in next
self._next()
File "/Users/zhengli/Desktop/Code/DGEMO-master/mobo/solver/pareto_discovery/pareto_discovery.py", line 463, in _next
p.start()
File "/Users/zhengli/anaconda3/lib/python3.10/multiprocessing/process.py", line 121, in start
self._popen = self._Popen(self)
File "/Users/zhengli/anaconda3/lib/python3.10/multiprocessing/context.py", line 224, in _Popen
return _default_context.get_context().Process._Popen(process_obj)
File "/Users/zhengli/anaconda3/lib/python3.10/multiprocessing/context.py", line 288, in _Popen
return Popen(process_obj)
File "/Users/zhengli/anaconda3/lib/python3.10/multiprocessing/popen_spawn_posix.py", line 32, in init
super().init(process_obj)
File "/Users/zhengli/anaconda3/lib/python3.10/multiprocessing/popen_fork.py", line 19, in init
self._launch(process_obj)
File "/Users/zhengli/anaconda3/lib/python3.10/multiprocessing/popen_spawn_posix.py", line 47, in _launch
reduction.dump(process_obj, fp)
File "/Users/zhengli/anaconda3/lib/python3.10/multiprocessing/reduction.py", line 60, in dump
ForkingPickler(file, protocol).dump(obj)
AttributeError: Can't pickle local object 'GaussianProcess.init..constrained_optimization'

Hi Yunsheng, great code we've been using it for awhile now! When using the command line version of autooed to run a custom problem, how do we supply initial samples that we've already calculated at the start of the optimization? Right now it looks as if the only option is to let the code generate its own set of initial samples via LHS, but we would like to supply our own pre-computed set of design/perf. variables if possible. Our objective functions are fairly expensive, and so we would like to be use the samples we already have to jumpstart the optimization, while also avoiding duplicated calculations.

I've dug through almost every file I can find looking for some examples or reference on how to supply an initial dataset, but I haven't found anything. I've also gone through the pymoo documentation quite a bit and have not found much help there either, especially considering the version differences between the current pymoo and the version used in autooed. Looking at your code though, I think I could just modify it on my own, changing the 'generate_initial_samples' function but if there's an already built in solution I would rather go that route before modifying anything. Thanks in advance for any help

Hi Yunsheng, we've come across another issue. For this one, I'm not sure if its something in the code, or if its something that we're doing incorrectly (as a user) but I thought I'd throw it up here and see what you thought.

First this ONLY seems to be an issue when we use the dgemo algorithm. We do not see this when you e.g., tsemo, or usemo

It seems like the code is not actually applying the constraints to the design sets that are being selected. It definitely evaluates the constraints (we can see this by putting print commands inside the constraint function itself) but the design sets that get chosen and given to the objective functions do not seem to have to pass the constraint.

Below I've given an example dummy problem, where this constraint issue occurs. It mimics some of the real world problems we're trying to solve but with very simple objective functions. In the real problem, we have 4 design variables and 2 objectives. The design variables are constrained via an equality (i.e., x1 + x2 + x3 + x4 = 1). As this is difficult to solve, we rewrite it so that the fourth variable (x4) is found deterministically (i.e., x4 = 1 - (x1 + x2 + x3)), and so that the mobo algorithm only explicitly handles x1, x2, and x3. This lets us apply the equality constraint as an inequality constraint, where the CV bounds are set to match the real world bounds of x4. (I.e., if the bounds of x4 are (low=0.1, high=0.4) then (1 - (x1 + x2 +x3)) must be between 0.1 and 0.4. Below we do this with a parabolic function, such that passed constraints give negative values, and fails are positive, etc. We have also done this with two inequality constraints inside an IF statement, and gotten the same result (and still finding the CV issue).

DUMMY problem: DGEMO/problem/myproblem.py

`class MyProblem(Problem):

def __init__(self):
    super().__init__(n_var=3, n_obj=2, n_constr=1, xl=0.05, xu=0.6)

def _evaluate_F(self, x):
    print("Evaluating F")
    x1, x2, x3 = x[:, 0], x[:, 1], x[:, 2]
    f1 = -x1
    f2 = (x2 + x3)

    # Recalculate the constraint inside F just for easy reporting
    x4 = 1 - (x1 + x2 + x3)
    g1 = (x4 - 0.1)**2 + (-0.3)*(x4 - 0.1)
    nl = '\n'
    print(f"Design Set:{nl}{np.column_stack([x])}")
    print(f"Constraint:{nl}{np.column_stack([g1])}")

    return np.column_stack([f1, f2])


def _evaluate_G(self,x):
    x1, x2, x3 = x[:, 0], x[:, 1], x[:, 2]
    x4 = 1 - (x1 + x2 + x3)
    g1 = (x4 - 0.1)**2 + (-0.3)*(x4 - 0.1)

    return np.column_stack([g1])

`

We also supply some dummy initial sample files stored in /{run_directory}/init_samples
des.csv
0.125,0.291666666666667,0.291666666666667
0.166666666666667,0.277777777777778,0.277777777777778
0.208333333333333,0.263888888888889,0.263888888888889
0.25,0.25,0.25
perf.csv
-0.125,0.583333333333334
-0.166666666666667,0.555555555555556
-0.208333333333333,0.527777777777778
-0.25,0.5

And we modify the 'get initial samples segment' of the DGEMO/problems/common.py file to find them, with:
rd = os.getcwd()
is_loc = f"{rd}/init_samples"
X_init = np.loadtxt(f"{is_loc}/des.csv", delimiter=",", dtype=float)
Y_init = np.loadtxt(f"{is_loc}/perf.csv", delimiter=",", dtype=float)

To execute the script we run:
python DGEMO/main.py --problem myproblem --algo dgemo --n-iter 3 --n-init-sample 0 --batch-size 4 --subfolder $PWD

When I run this, here is the output for Iteration 0 (Note I have added print statements to the objective function to print out the design set and constraint evaluation for each sample passed through x -- if I did this in the actual constraint function, then you would get a huge list of design sets as the code predicts the Pareto front (I believe?)).:

========== Iteration 0 ==========
Surrogate model fitted: 0.06s
ParetoDiscovery optimizing: generation 10
Surrogate problem solved: 2.68s
Number of families is: 5
Next sample batch selected: 0.01s
Evaluating F
Design Set:
[[0.6 0.08482263 0.08482263]
[0.12038804 0.16957347 0.30348171]
[0.59997906 0.17677851 0.47452407]
[0.13688059 0.26926301 0.26736896]]
Constraint:
[[-0.02211406]
[ 0.00201003]
[ 0.22878328]
[-0.01664967]]
New samples evaluated: 0.00s
Total runtime: 2.75s
Total evaluations: 8, hypervolume: 0.1965

As you can see (highlighted in bold) four design sets are selected, however sets 2 and 3 do not pass the constraint evaluation, yet they were still passed to the objective function and evaluated. In this dummy example, this is not as serious as it does not break the objective calculation, but in our real world problem, it would be impossible to solve for our objectives using design sets that violate the constraint function.

I've been trying to dig through the code to find the root of this problem but I haven't been able to find anything yet. I wanted to engage you first as I have some ideas about things but I'm not totally sure.

• First, could this just be matter of the return format of our constraint function? I've tried playing around with different formats (i.e., like not column stacking them etc.) but I haven't had any success with that
• Could this be "feasibility" issue? I.e., is the degree to which the constraint is failed a factor? And is it meant that the code can pass a failed design set as long as the return of the constraint evaluation is close to zero? And could this be solved by just simply scaling the constraint function return value so that it becomes very very large if failed?
• The only place I can find a reference to the constraint in the mobo code is In DGEMO/mobo/mobo.py, in the #Update dataset segment, where the line if self.real_problem.n_constr > 0: Y_next = Y_next[0] is placed between Y_next = self.real_problem.evaluate(X_next) and the status update step self._update_status(X_next, Y_next). I haven't yet had the time to really dig all the way into this step yet, but I'm not immediately sure how to interpret whats happening in the Y_next = Y_next[0] bit.

I wanted to get your thoughts on this and see if there was something we could do to get around or solve this issue. Hopefully it's just something we're doing incorrectly on our end, but any assistance or guidance would be very greatly appreciated.