TensorFlow
tf.summary.scalar
collections argument
machine learning
data visualization

TensorFlow Understanding the collections argument in tf.summary.scalar

ML System Design practice on Codemia

Design recommenders, ranking systems and training pipelines the way ML interviews actually ask for them, with worked solutions.

Practice ML system design

Introduction

The collections argument in tf.summary.scalar belongs to the TensorFlow 1.x graph-building model, where operations can be grouped into named collections for later retrieval. If you are reading older TensorFlow code, understanding this argument helps explain how summary ops were organized before TensorFlow 2 switched to eager-style summary writing.

What a Collection Is in TensorFlow 1.x

In TensorFlow 1.x, a graph can store named groups of objects such as variables, update ops, or summary ops. These groups are called collections.

By default, tf.summary.scalar adds the created summary op to tf.GraphKeys.SUMMARIES. That means later code can gather all summary ops at once with tf.summary.merge_all().

A simple example using the compatibility API:

python
1import tensorflow as tf
2
3tf.compat.v1.disable_eager_execution()
4
5loss = tf.compat.v1.placeholder(tf.float32, name="loss")
6loss_summary = tf.compat.v1.summary.scalar("loss", loss)
7
8all_summaries = tf.compat.v1.summary.merge_all()
9print(loss_summary)
10print(all_summaries)

Because no custom collection was provided, the summary lands in the default summaries collection.

Why collections Exists

The collections argument lets you override or extend where the summary op is registered. This is useful when you want to keep different kinds of summaries separate.

For example, you might want one collection for training metrics and another for validation metrics:

python
1import tensorflow as tf
2
3tf.compat.v1.disable_eager_execution()
4
5train_loss = tf.compat.v1.placeholder(tf.float32, name="train_loss")
6val_loss = tf.compat.v1.placeholder(tf.float32, name="val_loss")
7
8tf.compat.v1.summary.scalar(
9    "train_loss",
10    train_loss,
11    collections=["train_summaries"]
12)
13
14tf.compat.v1.summary.scalar(
15    "val_loss",
16    val_loss,
17    collections=["val_summaries"]
18)
19
20train_merged = tf.compat.v1.summary.merge_all(key="train_summaries")
21val_merged = tf.compat.v1.summary.merge_all(key="val_summaries")

Now you can run only the training summaries or only the validation summaries instead of always merging everything together.

Default Collection vs Custom Collections

If you omit collections, the summary goes into the default summaries collection. If you pass a list, TensorFlow registers the summary in the named collections you specify instead.

That design gave TensorFlow 1.x users more control in large graphs where "all summaries" was too broad. It was especially handy in projects with multiple phases, multiple submodels, or separate training and evaluation graphs.

You could also add a summary op to more than one collection:

python
1tf.compat.v1.summary.scalar(
2    "accuracy",
3    train_loss,
4    collections=["train_summaries", "all_metrics"]
5)

That made selective merging possible without duplicating the summary definition.

Why This Matters Less in TensorFlow 2

In TensorFlow 2, the summary workflow is different. Instead of building graph collections and later merging summary ops in a session, you usually write summaries directly inside execution code with a summary writer.

So if you see collections in older code, the important context is that you are dealing with TensorFlow 1.x or tf.compat.v1 style graph construction, not modern eager-first TensorFlow 2 APIs.

In large TF1 training codebases, this separation was genuinely useful because one graph could accumulate many kinds of summaries that you did not always want to run together on every step.

Common Pitfalls

The biggest mistake is reading old tf.summary.scalar code as if it behaved like TensorFlow 2 summaries. The collections argument is part of the older graph-collection model.

Another common issue is creating custom collections and then forgetting to merge them with the matching key. If you call merge_all() without the right key, your custom summaries may never run.

It is also easy to assume collections changes the scalar value itself. It does not. It only changes how the resulting summary op is organized inside the graph.

Summary

  • In TensorFlow 1.x, collections controls which graph collections receive the summary op created by tf.summary.scalar.
  • Without a custom value, summary ops go to tf.GraphKeys.SUMMARIES.
  • Custom collections help separate training, validation, or subsystem summaries.
  • Use tf.summary.merge_all(key=...) to merge summaries from a specific collection.
  • This argument belongs to the TensorFlow 1.x graph model and is mostly legacy in TensorFlow 2 codebases.

Related reading
Free course
Beginner
7 lessons
2 hours
Tackling System Design Interview Problems

A short course that equips you with the skills to approach system design interviews methodically.

Start the free course
Track what you have practised

A free account saves your progress, solutions and study plan across every problem on Codemia.

ML System Design practice on Codemia

Design recommenders, ranking systems and training pipelines the way ML interviews actually ask for them, with worked solutions.

Practice ML system design

All Rights Reserved.