# Best practice for hyperparameters sweep

**URL:** <https://discuss.dvc.org/t/best-practice-for-hyperparameters-sweep/244>\
**Category:** Questions\
**Created:** [October 7, 2019, 10:35am UTC](https://discuss.dvc.org/t/best-practice-for-hyperparameters-sweep/244 "2019-10-07T10:35:43Z")\
**Posts on this page:** 1\
**Showing post:** 3

<div class="post-metadata">

**Author:** ![alex](https://avatars.discourse-cdn.com/v4/letter/a/db5fbb/32.png) [@alex](https://discuss.dvc.org/u/alex)\
**Post date:** [October 7, 2019, 12:33pm UTC](https://discuss.dvc.org/t/best-practice-for-hyperparameters-sweep/244/3 "2019-10-07T12:33:18Z")

</div>

Thanks for the links, they address exactly the questions I had! Unfortunately, no solutions yet 🙂

I’ve used a number of ad-hoc solutions, and I was not satisfied with any of them.

For every output file I would like to be able to find exactly how the file was produced, i.e. version of code (git commit), hyperparameters (e.g. command-line parameters to the executables), and data (I have several “datasets” that go through identical pipelines). I experimented with long file- and directory-names (called “experiment-as-a-folder” in issue #2532), and included values of all parameters in a filename (e.g. summaryFigures/dataA\_numclusters5\_epochs10/). Much of this information is already in the DVC file, but the workflow is not “clicking” for me yet.

I think I’d like to separate a generic workflow/pipeline/DAG definition from each of its “instances” (with the hashes and all).

I will watch those two issues on GitHub.

Thanks again!  
Alex

---

_[View the full topic](https://discuss.dvc.org/t/best-practice-for-hyperparameters-sweep/244)._