Skip to content
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

Hyperparameter Optimization Module #164

Open
wants to merge 135 commits into
base: main
Choose a base branch
from
Open

Conversation

middleyuan
Copy link
Contributor

@middleyuan middleyuan commented Sep 23, 2024

This PR is created for two primary purposes:

  1. Include the state-of-the-art package Google-Vizier as a hyperparameter optimization solver.
  2. Change the database to SQLite for easier usage.

…ve unnecessary config in cartpole_stab.yaml 2. add hpo module in test_build.py
…ckpoint in ppo.py. 4. Boolean var in ppo_sampler.
@middleyuan middleyuan added the enhancement New feature or request label Sep 23, 2024
Copy link
Contributor

@adamhall adamhall left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks pretty good! I have a couple thoughts though:

  1. It seems like there is a lot of controller-specific code. For example, there is a separate sampler for each controller, and in the HPO code, there are if statements depending on the algorithm being optimized. I'm wondering if there is a way to make this more generic by making an HPO yaml more complex and then having the underlying code make classes from the arguments in these yamls? For example, I think that hpo_sampler.py could almost entirely be defined in a yaml and then having a generic class for sampler that parses the yaml appropriately? It feels like there is a lot of repeated code that could be simplified and the addition of future algos simpler?

  2. the HPO class is defined in both hpo_optuna.py and hpo_vizier.py which seem to share a lot of code. I think there should really be a parent HPO class, and then child sublcasses for the different use cases?

  3. I'm not totally sure why the files are being removed from the examples. Is it because you are replacing them with better hyper parameters?


class HPO(object):

def __init__(self, algo, task, load_study, output_dir, task_config, hpo_config, algo_config, safety_filter=None, sf_config=None):
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Put each argument on a separate line and provide types and defaults for all if possible.

safe_control_gym/hyperparameters/hpo_optuna.py Outdated Show resolved Hide resolved
safe_control_gym/hyperparameters/hpo_optuna.py Outdated Show resolved Hide resolved
Gs = np.inf
for i in range(self.hpo_config.repetitions):
# np.random.seed()
seed = np.random.randint(0, 10000)
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We should be careful about this for reproducibility. In the envs, we usually create a random seeding object that is used for all randomness. Can we incorporate this somehow to ensure everything is exactly reproducible?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, see hpo_experiment.py.

seed = np.random.randint(0, 10000)
# update the agent config with sample candidate hyperparameters
# new agent with the new hps
for hp in sampled_hyperparams:
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

To make this more generic, is there a way to make the keys part of the sampled_hyperparams dictionary? Could hp object also include the name like 'q_mpc', 'r_mpc'? Otherwise, this logic has to be updated whenever a new controller is added.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Done

from safe_control_gym.utils.registration import make
from safe_control_gym.utils.utils import mkdirs

class HPO(object):
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This class is defined in both hpo_optuna and hpo_vizier, naming should be more precise instead of having the same class defined in two places.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Done

Copy link
Collaborator

@Federico-PizarroBejarano Federico-PizarroBejarano left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I agree with Adam's comments and believe they should be addressed before the next round of reviews. The changes are too broad to do only one review. In general I think there is too much code, both repeated and non-repeated. I think the gym needs to generally simple and concise for people (other than us) to use it. There is also a lot of commented out code which I don't think should be there in completed code. Also, two stylistic comments: the precommit hooks need to be run to format everything consistently, and the docstrings and comments should follow our standard style, as Adam pointed out.

device: cpu
restore: null
device: cuda
restore: null
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

there should be a newline at the end of the file. I think the pre-commit hooks handle that. If not, you can configure vs code to always add one when a file is saved, which is what I do

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah the pre-commit hook should fix this, which means you haven't yet run the hook. This should be done ASAP as it may change a lot

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Done

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think the hooks have still not been run, since there are double quotes here and there.

examples/hpo/hpo_experiment.py Outdated Show resolved Hide resolved
@middleyuan middleyuan self-assigned this Sep 26, 2024
@adamhall
Copy link
Contributor

adamhall commented Sep 27, 2024

Looks much cleaner! Nice! I think the samplers could still be made a little more flexible? Let me know if you think this is feasible.

@middleyuan
Copy link
Contributor Author

middleyuan commented Sep 30, 2024

Looks pretty good! I have a couple thoughts though:

  1. It seems like there is a lot of controller-specific code. For example, there is a separate sampler for each controller, and in the HPO code, there are if statements depending on the algorithm being optimized. I'm wondering if there is a way to make this more generic by making an HPO yaml more complex and then having the underlying code make classes from the arguments in these yamls? For example, I think that hpo_sampler.py could almost entirely be defined in a yaml and then having a generic class for sampler that parses the yaml appropriately? It feels like there is a lot of repeated code that could be simplified and the addition of future algos simpler?
  2. the HPO class is defined in both hpo_optuna.py and hpo_vizier.py which seem to share a lot of code. I think there should really be a parent HPO class, and then child sublcasses for the different use cases?
  3. I'm not totally sure why the files are being removed from the examples. Is it because you are replacing them with better hyper parameters?
  1. I have made the HPO code more generic. The reason I don't define hyperparameter search space in yaml is that I don't want to add burdens on users as it usually requires some knowledge for code and algorithms.
  2. Yes, corresponding changes are made.
  3. Changes include re-factoring to make the folder structure consistent with other examples.

General comments: to get HPO module fully tested, I am waiting for another PR (quadrotor interface) to be approved. After that I will run unit-test for HPO on new env interface and also run pre-commits hook.

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

Successfully merging this pull request may close these issues.

3 participants