Last offspring kept after resetting the algorithm

[Thiago Garrett]

For tests involving successive runs until a time limit is reached, the algorithm/population is reset each time maxIterNonProd is reached. From my analysis of the code, the population is completely reset, but the next run starts with the last offspring of the previous run. Is that intended behavior? I'm asking this because it is very important for our current research to know if each run is completely independent from other runs during the same execution of the program.

In this piece of code the population and the iteration counter are reset, but not offspring:

HGS-CVRP/Program/Genetic.cpp

Lines 34 to 38 in 2d4d673

 if (params.ap.timeLimit != 0 && nbIterNonProd == params.ap.nbIter) 
 { 
 	population.restart(); 
 	nbIterNonProd = 1; 
 } 

And offspring is used in the beginning of the main loop:

HGS-CVRP/Program/Genetic.cpp

Lines 14 to 17 in 2d4d673

 crossoverOX(offspring, population.getBinaryTournament(),population.getBinaryTournament()); 
  
 /* LOCAL SEARCH */ 
 localSearch.run(offspring, params.penaltyCapacity, params.penaltyDuration); 

crossoverOX method does not seem to completely overwrite offspring: some of the not-overwritten values are used in localSearch.run (namely chromR).

Thanks!

[Thibaut Vidal]

Dear @tgarr, my apologies for the delay.
What members have you found unchanged in localSearch?
The expected behavior is that the offspring is completely rewritten by the crossoverOX function: chromT is inherited from the parents, and all other structures are updated in split.generalSplit.
It is true that it is not very apparent in the current code, and we could try to improve the code structure to make it clearer and perhaps permit some additional compiler optimizations.

[Thiago Garrett]

Hi, thanks for taking the time to answer! It's good to have a confirmation that the runs are independent, we were working under that assumption :)

I had the impression that Individual::chromR is not overwritten. But looking at the code again now, maybe Split::splitSimple is overwritting chromR? I may have missed that.

I'm closing the issue, since it seems I just misunderstood the code. Thanks again!