Skip to content

NSGA-II parallel Error in { : task 2 failed - "only 0's may be mixed with negative subscripts" #16

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
HaobinZhou opened this issue Jan 21, 2025 · 2 comments

Comments

@HaobinZhou
Copy link

Description:
I am using the rmoo package (version 0.3.0) to run the NSGA-II optimization with parallelization (using function rmoo). The error occurs during the execution when the iteration reaches 503:

Error in { :
task 2 failed - "only 0's may be mixed with negative subscripts"

I have checked my fitness function, and it does not seem to cause the issue. I suspect that the problem might be related to illegal indexing during the selection of offspring, such as when negative indices are mixed with positive ones. For example, I get the same error when running the following in R:

c(1, 2, 3)[c(-1, 2)]
This results in the error:

Error in c(1, 2, 3)[c(-1, 2)] :
only 0's may be mixed with negative subscripts

It appears that somewhere in the process, an illegal index like c(5, -1, -2) is being generated, which could be causing the issue.

Additional Information:
rmoo version: 0.3.0
OS: Windows 11

@benitezfj
Copy link
Collaborator

Ok, I understand that it could be due to the genetic operator of selection. Could you provide more information to replicate the problem? Depending on the type of chromosome used (binary, real-valued, permutation, discrete), the genetic operators follow different configurations. Below are the configurations established in rmooControl for the different chromosomes supported by rmoo:

 list(binary = list(population = "rmoobin_Population",
                                    selection = "rmoobin_tourSelection",
                                    crossover = "rmoobin_spCrossover",
                                    mutation = "rmoobin_raMutation"),
                     `real-valued` = list(population = "rmooreal_Population",
                                          selection = "rmooreal_tourSelection",
                                          crossover = "rmooreal_sbxCrossover",
                                          mutation = "rmooreal_polMutation"),
                     permutation = list(population = "rmooperm_Population",
                                        selection = "rmooperm_tourSelection",
                                        crossover = "rmooperm_oxCrossover",
                                        mutation = "rmooperm_simMutation"),
                     discrete = list(population = "rmooint_Population",
                                        selection = "rmooint_tourSelection",
                                        crossover = "rmooint_uxCrossover",
                                        mutation = "rmooint_uxMutation")

As another solution, you could modify the genetic operator causing the problem and pass it as a parameter to the population, selection, crossover, or mutation argument in the calling function.

@HaobinZhou
Copy link
Author

Thank you for your response. I’m running with type="real-valued". Unfortunately, it’s difficult to provide reproducible code, as it seems the parallelization is not applying the seed I set. The results vary each time I run it, and the iteration at which the error occurs also changes. I’ve encountered the same error around iterations 200, 500, and 800, which is quite strange. What’s even more odd is that only one CPU core reports the error. I’m not familiar with using debug mode to trace back to the corresponding core and pinpoint the environment variables at the time, so I’m unable to locate exactly which number is causing the issue. If you have any suggestions or advice on how to approach this, it would be greatly appreciated.

I also ran the non-parallelized NSGA-II with the same data and settings. I ran it nearly 20 times, and not once did it result in an error—it ran successfully every time. Therefore, I can’t provide the environment variables from the error scenario.

I’ve forked the rmoo package, and I’ll try to investigate the cause of the issue and modify the source code. If I manage to find a solution, I will definitely report it back to you, as I believe it could be valuable for the package. I truly enjoy using rmoo—it’s a very interesting R package.

If you have already solved this issue, I’m looking forward to your update!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants