Assertion `node_item->indicator_contribution[i] > 0' failed

[fritsche]

Hi,

I am trying to integrate the COCO framework with a JMetal based algorithm (using Java). I was able to run the algorithm with a budget of 100. But I am having a problem when I increase the budget to 100000.

java: code-experiments/src/logger_biobj.c:380: logger_biobj_tree_update: 

Assertion `node_item->indicator_contribution[i] > 0' failed.

What this assertion means?

Thanks.

[nikohansen]

I can't comment on the specific error. I just wonder whether you also tried the budgets between, like 1000 and 10000? It seems always advisable to increase using smaller factors than 1000 = 1e5 / 1e2.

[fritsche]

I tried with 1000, without modifications, and it ran just fine. I tried with 10000 and it crashed:

COCO INFO: 04.10.16 10:49:52, d=2, running: 
f01..........f02..........f03..........f04..........f05..........f06..........f07..........f08..........f09..........f10.....
java: code-experiments/src/logger_biobj.c:400: logger_biobj_tree_update:
Assertion `node_item->indicator_contribution[i] > 0' failed.

[fritsche]

I am running another test with budget 100000. I have replaced the assertions in logger_biobj.c:361, logger_biobj.c:380 and logger_biobj.c:400 from >0 to >=0. Similar to the assertion from logger_biobj.c:411: assert(node_item->indicator_contribution[i] >= 0); It is running for d=2, and looks like it fixed.

COCO INFO: 04.10.16 10:38:05, d=2, running: 
f01..........f02..........f03..........f04..........f05..........f06..........f07..........f08..........f09..........f10..........f11..........f12.
.........f13..........f14..........f15..........f16..........f17..........f18..........f19..........f20..........f21..........f22..........f23.......
...f24.........

[nikohansen]

@ttusar does this look good to you? I assume we would like to have >, that means the problem is somewhere before during logging?

[ttusar]

I'll have a look tonight and let you know

[ttusar]

What this assertion means?

This assertion checks that the newly evaluated solution has a positive indicator contribution (the same holds for the other two mentioned assertions in the same function). Since some dominance checks are performed before that, only positive indicator contributions should be possible at that stage.

The problem most probably stems from comparing doubles. I thought we got rid of these precision issues by adopting discretization of the normalized values, but apparently not... However, before jumping to any conclusions, it would be good to check this more thoroughly. Is there any way I could recreate the problem? Or at least get some more information on what is going on?

[ttusar]

An additional note: It seems a bit suspicious that we never encountered this before. We did pre-process a lot of runs where the algorithm found solutions closer together than the adopted discretization and this error never came up...

[fritsche]

I was able to reproduce the problem using NSGA-II (from JMetal 4.5). I created a repository for this experiment: https://github.com/fritsche/jmetal-coco

To run I used:

make jmetaljar
make 
java -cp ".:jmetal.jar" -Djava.library.path=. Experiment -alg NSGAII -budget 100

[ttusar]

Many thanks! I will have a look and let you know (it will probably take me a few days though).

[ttusar]

I was able to recreate the problem with JMetal. @fritsche do you know how the random seed can be set?

[fritsche]

I think that in JMetal45 it is not possible to set the seed for the default random generator.

I have updated the repository to allow the random seed setting. I had to create a random generator and use it instead of the default JMetal45 random generator. Then the JMetal45 PseudoRandom class uses this new generator.

        RandomGenerator generator = new RandomGenerator(RANDOM_SEED);
        PseudoRandom.setRandomGenerator(generator);
        experiment("bbob-biobj", "bbob-biobj", algorithm);

[strickler]

Guys, it happens in different functions, or always in a particular set ? The same error appears for me today.

[ttusar]

Finally took some time to look into this. It was not a precision problem, but a simple bug - the code was disregarding the special case of extreme solutions in the ROI (their indicator contribution equals 0). It's fixed now in the development branch (see commit 8e846a9523157ff8569058324644437620ae3cb0) and will be included in the next release.

It's quite amazing this never appeared in the experiments we performed before the workshops...