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

First version of cut tuning with optuna #11

Merged
merged 1 commit into from
Jun 20, 2022

Conversation

benedikt-voelkel
Copy link
Collaborator

@benedikt-voelkel benedikt-voelkel commented Jun 20, 2022

  • introduce various functionality, such as utils, I/O etc
    the structure is not cast in stone of course, first attempt

  • wrap multiprocessing in one function

  • offer the user a user_config dictionary at each trial which can be
    used to extract some (global) use case-specific configuration

  • allow 2 different signatures for objective

  • start making possible the usage of different samplers

  • cut tuning example
    4 scripts provided to produce reference, optimisation, evaluation and
    closure (see README in respective directory src/o2tuner_run)

    NOTE The example is preliminary, might need improvements

    Most functionality was added according to the needs of this example.

  • set max-line for flake8 to 150 (same as pylint)

  • add psutil and matplotlib as requirements

Overall, everything preliminary and up to discussion.

@benedikt-voelkel
Copy link
Collaborator Author

benedikt-voelkel commented Jun 20, 2022

Something like this @mconcas ?

Let me know if I should do anything on my side.

Actually, I might need to check flake8. Also, I have some TODOs in some files which of course also pylint will complain about.

Should I deal with the CIs first and then we merge?

@mconcas
Copy link
Collaborator

mconcas commented Jun 20, 2022

Something like this @mconcas ?

Let me know if I should do anything on my side.

Actually, I might need to check flake8. Also, I have some TODOs in some files which of course also pylint will complain about.

Should I deal with the CIs first and then we merge?

Thanks @benedikt-voelkel, yes, exactly.
For the moment I'd merge every development, so that we reduce the cross-rebasing.
Then we can consider to release a new package version when we have something closer to whatever standard utilisation we envise for the tool.

Would be nice if we could have CI green, unless you find there are some dumbs blocks related to that.
Than I can interleave a fix for the CI itself and rebase this.

@benedikt-voelkel
Copy link
Collaborator Author

Ok, let me fix the CI related problems now

* introduce various functionality, such as utils, I/O etc
  the structure is not cast in stone of course, first attempt
* wrap multiprocessing in one function
* offer the user a user_config dictionary at each trial which can be
  used to extract some (global) use case-specific configuration
* allow 2 different signatures for objective
* start making possible the usage of different samplers

* cut tuning example
  4 scripts provided to produce reference, optimisation, evaluation and
  closure (see README in respective directory src/o2tuner_run)

  **NOTE** The example is preliminary, might need improvements

  Most functionality was added according to the needs of this example.

* set max-line for flake8 to 150 (same as pylint)

* add psutil and matplotlib as requirements

Overall, everything preliminary and up to discussion.
@mconcas mconcas merged commit 5baa45c into AliceO2Group:master Jun 20, 2022
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

Successfully merging this pull request may close these issues.

2 participants