Rocketsled: Predictor seems to always be RandomForestRegressor

Hello!

I am just getting started using Rocketsled and I have been running the basic and complex examples. I’ve noticed that no matter what I change the predictor to (random, extratreesregressor, GaussianProcessRegressor, etc) the output always says that RandomForestRegressor is used and when I view the plots, it seems that RandomForestRegressor is being used.

The line that I have been editing in complex.py is mc.configure(wf_creator = wf_creator, dimensions=x_dim, acq=“maxmin”, predictor = “GaussianProcessRegressor”,get_z=get_z). So I have 3 questions:

  1. Am I changing the predictor in the wrong place?

  2. Is there just a bug in the code that will always print RandomForestRegressor no matter what predictor is used or

  3. is the program always using RandomForestRegressor no matter what I change the predictor to in that line?

Any advice on how to proceed is welcome.

Thanks in advance!

Haley Dozier

Hey Haley,

My first guess is that you are launching fireworks from previous “loops” and instead of running the “new” fireworks with other predictors, your are still running the “old” random forest regressor loop. At the end of each loop, rocketsled adds the next workflow to the launchpad, so even if you add another workflow after that, the wf that will be run is the first one added.

If you defuse the current rocketsled fireworks on the launchpad, then add the new ones and run, does the same thing happen?

Thanks,

Alex

···

On Fri, May 31, 2019 at 8:33 AM Haley Dozier [email protected] wrote:

Hello!

I am just getting started using Rocketsled and I have been running the basic and complex examples. I’ve noticed that no matter what I change the predictor to (random, extratreesregressor, GaussianProcessRegressor, etc) the output always says that RandomForestRegressor is used and when I view the plots, it seems that RandomForestRegressor is being used.

The line that I have been editing in complex.py is mc.configure(wf_creator = wf_creator, dimensions=x_dim, acq=“maxmin”, predictor = “GaussianProcessRegressor”,get_z=get_z). So I have 3 questions:

  1. Am I changing the predictor in the wrong place?
  1. Is there just a bug in the code that will always print RandomForestRegressor no matter what predictor is used or
  1. is the program always using RandomForestRegressor no matter what I change the predictor to in that line?

Any advice on how to proceed is welcome.

Thanks in advance!

Haley Dozier

You received this message because you are subscribed to the Google Groups “fireworkflows” group.

To unsubscribe from this group and stop receiving emails from it, send an email to [email protected].

To post to this group, send email to [email protected].

Visit this group at https://groups.google.com/group/fireworkflows.

To view this discussion on the web visit https://groups.google.com/d/msgid/fireworkflows/b3c9c094-a436-4b43-b732-e77a5dcfe523%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

Hi Alex,

I also had the same problem as Haley. To confirm, I deleted all the fireworks from the MongoDB manually, and still could not get it to run the GaussianProcessRegressor, even after configuring MissionControl as such:

mc.configure(wf_creator=wf_creator, dimensions=x_dim, predictor='GaussianProcessRegressor')

I had to modify the default predictor in my defaults.yaml file to get it to change to Gaussian instead of RandomForest.

Thanks,

Abe

···

On Saturday, June 1, 2019 at 9:25:34 AM UTC-7, Alex Dunn wrote:

Hey Haley,

My first guess is that you are launching fireworks from previous “loops” and instead of running the “new” fireworks with other predictors, your are still running the “old” random forest regressor loop. At the end of each loop, rocketsled adds the next workflow to the launchpad, so even if you add another workflow after that, the wf that will be run is the first one added.

If you defuse the current rocketsled fireworks on the launchpad, then add the new ones and run, does the same thing happen?

Thanks,

Alex

On Fri, May 31, 2019 at 8:33 AM Haley Dozier [email protected] wrote:

Hello!

I am just getting started using Rocketsled and I have been running the basic and complex examples. I’ve noticed that no matter what I change the predictor to (random, extratreesregressor, GaussianProcessRegressor, etc) the output always says that RandomForestRegressor is used and when I view the plots, it seems that RandomForestRegressor is being used.

The line that I have been editing in complex.py is mc.configure(wf_creator = wf_creator, dimensions=x_dim, acq=“maxmin”, predictor = “GaussianProcessRegressor”,get_z=get_z). So I have 3 questions:

  1. Am I changing the predictor in the wrong place?
  1. Is there just a bug in the code that will always print RandomForestRegressor no matter what predictor is used or
  1. is the program always using RandomForestRegressor no matter what I change the predictor to in that line?

Any advice on how to proceed is welcome.

Thanks in advance!

Haley Dozier

You received this message because you are subscribed to the Google Groups “fireworkflows” group.

To unsubscribe from this group and stop receiving emails from it, send an email to [email protected].

To post to this group, send email to [email protected].

Visit this group at https://groups.google.com/group/fireworkflows.

To view this discussion on the web visit https://groups.google.com/d/msgid/fireworkflows/b3c9c094-a436-4b43-b732-e77a5dcfe523%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

Hi all,

thanks for noting this. Special thanks to @Abe Wu’s pointing out the likely problem (over email not reproduced here), newest github code should resolve this issue. I released a new version 2019.6.5 on pypi as well reflecting this change. New tests also make sure this does not happen in the future.

Please let me know if you continue to have issues!

Thanks,

Alex

Glad to help! :slight_smile:

Thanks to you for providing Rocketsled. It is a great piece of software and very innovative. I’m enjoying working with it!

Abe

···

On Tuesday, June 4, 2019 at 9:29:30 PM UTC-7, Alexander Dunn wrote:

Hi all,

thanks for noting this. Special thanks to @Abe Wu’s pointing out the likely problem (over email not reproduced here), newest github code should resolve this issue. I released a new version 2019.6.5 on pypi as well reflecting this change. New tests also make sure this does not happen in the future.

Please let me know if you continue to have issues!

Thanks,

Alex