It's just this test setup. The derivatives g were chosen in order to be able to
know what the answer would be. In the true setup (part of my MSc thesis
project) the problem is to solve a multi-objective topology optimization
problem using an SLP algorithm [1]:
min lp(x) = ( sum( w[i]^p*((f[i] - fmin[i])/(fmax[i]-fmin[i]))^p )^(1/p)
s.t. 0 <= x <= 1
where f[i] are different non-linear objective functions (weight, compliance,
eigenvalue) and w[i] are weight factors. The p is a norm factor (p=1 ==> no
norm, p = infty == > max-norm).
Since lp(x) is computationally expensive, it is solved using sequential linear
programming. That's where the use of the SIMPLEX method comes in. Eventually,
the aim is to trace the Pareto-Optimal frontier of my problem.
The test case was set up with full weight on compliance, i.e. only minimization
of compliance was present. And my compliance is the biggest when all x takes
the value 1 as this corresponds to all elements being active with full
stiffness in my FE-domain.
Many thanks for all the help Thomas!
/Alexander
[1] F. A. Gomes and T. A. Senne. An slp algorithm and its application to
topology optimization. Computational & Applied Mathematics, 30(1):53–89, 2011.
9 apr 2013 kl. 11:46 skrev Thomas Neidhart <[email protected]>:
> btw. are you sure your problem is well-defined?
> All coefficients of the objective function are negative, and all variables
> are bounded by the interval [-1, 0].
> Thus when minimizing the function, the obvious solution is that all
> variables are set to 0, which is also the result.
>
> Maybe thats just a result of the testcase and your other code has different
> values?
>
> Thomas
>
>
> On Tue, Apr 9, 2013 at 11:37 AM, Thomas Neidhart
> <[email protected]>wrote:
>
>> Hi Alexander,
>>
>> great!
>>
>> You can keep the issue open, I think it makes sense (and other people had
>> the same questions before) and we should support the same features as other
>> solvers.
>> Maybe you could update the issue with the corrected code (as attachment
>> instead of pasting it into the description) and mention that this feature
>> is rather for convenience than for speed (although this has to be further
>> analyzed).
>>
>> Thanks,
>>
>> Thomas
>>
>>
>>
>> On Tue, Apr 9, 2013 at 11:20 AM, Alexander Sehlström <
>> [email protected]> wrote:
>>
>>> Thank's for seeing the mistake with the coef array. The same mistake was
>>> made with the s_l and s_u:
>>>
>>> double[] s_l = x;
>>> double[] s_u = x;
>>>
>>> It's now instead
>>>
>>> double[] s_l = new double[x.length];
>>> double[] s_u = new double[x.length];
>>>
>>> Changing this made the code run in 7.7 s and after adjusting the epsilon
>>> value it runs in 1 s. Having the same setup in my original SLP algorithm,
>>> with the SLP solver I am implementing running in it's own thread, the
>>> SimplexSolver takes only 0.15 s. A very pleasant computation time!
>>>
>>> So it seams there is no need to implement lower and upper bound support
>>> in SimplexSolver in order to gain speed, but perhaps in order to make it
>>> more user friendly. Do I close the issue and make a new one or do I edit
>>> the description of the one created?
>>>
>>> Alex
>>>
>>> 9 apr 2013 kl. 10:19 skrev Thomas Neidhart <[email protected]>:
>>>
>>>> To improve the speed in your example, you can also adjust the epsilon
>>>> value, e.g. setting it to 1e-3, which leads to the same result with all
>>>> constraints satisfied, takes on my machine 3.5s instead of 6s with the
>>>> default value of 1e-6. But you will have to experiment with this
>>> setting to
>>>> get optimal values for your problem.
>>>>
>>>> Thomas
>>>>
>>>>
>>>> On Tue, Apr 9, 2013 at 10:15 AM, Thomas Neidhart
>>>> <[email protected]>wrote:
>>>>
>>>>> Hi Alexander,
>>>>>
>>>>> thanks, but there is a small problem with your constraints:
>>>>>
>>>>> you assign the zeros array to coeff, but this does not copy the array,
>>> so
>>>>> the array will be filled with '1's instead of an array with only one
>>> '1' at
>>>>> position i.
>>>>>
>>>>> for ( int i = 0; i < s_l.length; i++ ) {
>>>>> double[] coef = zeros;
>>>>> coef[i] = 1;
>>>>> constraints.add( new LinearConstraint( coef, Relationship.GEQ,
>>>>> s_l[i] ) );
>>>>> constraints.add( new LinearConstraint( coef, Relationship.LEQ,
>>>>> s_u[i] ) );
>>>>> }
>>>>>
>>>>> change this to something like:
>>>>>
>>>>> double[] coef = Arrays.copyOf( zeros, zeros.length );
>>>>>
>>>>> Another thing: the lower/upper bounds in this test are for all variable
>>>>> 1/1.
>>>>>
>>>>> Thomas
>>>>>
>>>>>
>>>>>
>>>>> On Tue, Apr 9, 2013 at 9:52 AM, Alexander Sehlström <
>>>>> [email protected]> wrote:
>>>>>
>>>>>> Issue created!
>>>>>>
>>>>>> https://issues.apache.org/jira/browse/MATH-966
>>>>>>
>>>>>>
>>>>>> 9 apr 2013 kl. 08:36 skrev Thomas Neidhart <[email protected]
>>>> :
>>>>>>
>>>>>>> On 04/09/2013 08:23 AM, Alexander Sehlström wrote:
>>>>>>>> Thomas,
>>>>>>>>
>>>>>>>> After writing the pice of code you were asking for I found the
>>> error;
>>>>>> The max iteration exception was thrown, but swallowed by some part of
>>> my
>>>>>> code, hence not showing up. So by increasing from maximum 100 to 1000
>>>>>> iterations the SimplexSolver returns a result.
>>>>>>>>
>>>>>>>> It is quite slow however and do not come near the computation time I
>>>>>> need solving the same problem in Matlab with linprog. Suggestions of
>>> other
>>>>>> Apache Commons Math classes that are solving the same type of
>>> problems as
>>>>>> the SimplexSolver do are gratefully accepted.
>>>>>>>
>>>>>>> Hi Alexander,
>>>>>>>
>>>>>>> good that your example works. The reason its slow is most likely
>>> related
>>>>>>> to your problem setup.
>>>>>>>
>>>>>>> The SimplexSolver currently does not support lower/upper bounds for
>>> the
>>>>>>> variables, thus you had to create separate constraints for each
>>> variable
>>>>>>> as suggested before. This makes the calculation quite slow I guess,
>>> so
>>>>>>> we should add direct support for such bounds (similar to matlab or
>>>>>> octave).
>>>>>>>
>>>>>>> This can be done with the original tableau (see
>>>>>>> http://homepages.rpi.edu/~mitchj/handouts/upperbounds/).
>>>>>>>
>>>>>>> It would be nice to have your example as performance test, so you
>>> could
>>>>>>> add a feature request to the issue tracker yourself.
>>>>>>>
>>>>>>> Thomas
>>>>>>>
>>>>>>> ---------------------------------------------------------------------
>>>>>>> To unsubscribe, e-mail: [email protected]
>>>>>>> For additional commands, e-mail: [email protected]
>>>>>>>
>>>>>>
>>>>>>
>>>>>> ---------------------------------------------------------------------
>>>>>> To unsubscribe, e-mail: [email protected]
>>>>>> For additional commands, e-mail: [email protected]
>>>>>>
>>>>>>
>>>>>
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: [email protected]
>>> For additional commands, e-mail: [email protected]
>>>
>>>
>>
