You can check to confirm that the step runs for pipeline-rf-opt are linked as expected:
guild ls -o pipeline-rf-opt
You should see directories for prepare-data and random-forest:train. These are links to the step runs. Guild uses these to traverse to the TF summary (event) files where the scalars are saved. These should be rolled up so they appear when you run:
guild runs info -o pipeline-rf-opt
I’ve confirmed this is working as expected on a sample pipeline. If you’re seeing something different we can troubleshoot further.
@garrett, I have just discovered how the pipeline works. It saves scalars in separate folders (in my case prepare and random_forest_train). I thought it would save everything in the pipeline folder. I am not sure how can I know which parameters I used in the prepare step if I inspect result in random forest operation.
I see guild runs info is not helpful in this case. It should show step run IDs at least so you can further inspect them.
Your best bet for this I think is to use guild compare with a range selector to show the pipeline and its step runs. This assumes the pipeline and steps ran in isolation — i.e. there aren’t any other runs interleaved.
Something like this:
guild compare 1:4
Assuming your pipeline has three steps and was the last thing to run, this would show the flag values for each of the steps.
I think Guild compare could support a --show-steps option that implicitly selects the steps for a pipeline. That way you could run guild compare --show-steps <pipeline run>.
It’d also be good to show step info in guild runs info.
@mislav would you mind opening an issue for this problem? It’s a general problem that I’d describe as “Hard to view pipeline results as a whole”. If that doesn’t capture what you think the issues are, feel free to use whatever title you think is best. With an issue we can track progress on the solution.
I can’t recreate the behavior where Guild mistakenly states “the following runs match this operation” for different flag values. The matching runs are listed so it should be straight forward to verify the set of flag values. If Guild is stating that two runs with different flag values are the same, that’s a bug.
I assume you’re using --needed for some other reason. If not, just omit and this problem goes away. If you must use --needed then I think one approach is to use an additional flag to differentiate runs that are truly different, even though they have the same flag values. For example: