Called after a new session is created.
Called after a new session is created. This is called to signal the hooks that a new session has been created.
This callback has two essential differences with the situation in which begin()
is called:
The session that has been created.
Called after each call to Session.run()
.
Called after each call to Session.run()
.
The runContext
argument is the same one passed to beforeSessionRun()
. runContext.requestStop()
can be called
to stop the iteration.
The runResult
argument contains fetched values for the tensors requested by beforeSessionRun()
.
If Session.run()
throws any exception, then afterSessionRun()
will not be called. Note the difference between
the end()
and the afterSessionRun()
behavior when Session.run()
throws an OutOfRangeException. In
that case, end()
is called but afterSessionRun()
is not called.
Provides information about the run call (i.e., the originally requested ops/tensors, the
session, etc.). Same value as that passed to beforeSessionRun
.
Result of the Session.run()
call that includes the fetched values for the tensors requested
by beforeSessionRun()
.
Called before each call to Session.run()
.
Called before each call to Session.run()
. You can return from this call a Hook.SessionRunArgs object
indicating ops or tensors to add to the upcoming run call. These ops/tensors will be run together with the
ops/tensors originally passed to the original run call. The run arguments you return can also contain feeds to be
added to the run call.
The runContext
argument is a Hook.SessionRunContext that provides information about the upcoming run call
(i.e., the originally requested ops/tensors, the session, etc.).
At this point the graph is finalized and you should not add any new ops.
Provides information about the upcoming run call (i.e., the originally requested ops/tensors, the session, etc.).
Called once before creating the session.
Called once before creating the session. When called, the default graph is the one that will be launched in the
session. The hook can modify the graph by adding new operations to it. After the begin
call the graph will be
finalized and the other callbacks will not be able to modify the graph anymore. A second begin
call on the same
graph, should not change that graph.
Called at the end of the session usage (i.e., Session.run()
will not be invoked again after this call).
Called at the end of the session usage (i.e., Session.run()
will not be invoked again after this call).
The session
argument can be used in case the hook wants to execute any final ops, such as saving a last
checkpoint.
If Session.run()
throws any exception other than OutOfRangeException then end()
will not be called.
Note the difference between the end()
and the afterSessionRun()
behavior when Session.run()
throws an
OutOfRangeException. In that case, end()
is called but afterSessionRun()
is not called.
Session that will not be used again after this call.
Hook to extend calls to
MonitoredSession.run()
.Hooks are useful to track training, report progress, request early stopping and more. They use the observer pattern and notify at the following points:
A Hook encapsulates a piece of reusable/composable computation that can piggyback a call to
MonitoredSession.run()
. A hook can add any feeds/fetches/targets to the run call, and when the run call finishes executing with success, the hook gets the fetches it requested. Hooks are allowed to add ops to the graph in thebegin()
method. The graph is finalized after thebegin()
method is called.There are a few pre-defined hooks that can be used without modification:
StopHook
: Requests to stop iterating based on the provided stopping criteria.StepRateHook
: Logs and/or saves summaries with the number of steps executed per second.TensorLoggingHook
: Logs the values of one or more tensors.SummarySaverHook
: Saves summaries to the provided summary writer.CheckpointSaverHook
: Saves checkpoints (i.e., copy of the graph along with the trained variable values).TensorNaNHook
: Requests to stop iterating if the provided tensor containsNaN
values.For more specific needs you can create custom hooks. For example:
To understand how hooks interact with calls to
MonitoredSession.run()
, look at following code:The above user code loosely leads to the following execution:
Note that if
session.run()
throws an OutOfRangeException thensomeHook.afterSessionRun()
will not be called, butsomeHook.end()
will still be called. On the other hand, ifsession.run()
throws any other exception, then neithersomeHook.afterSessionRun()
norsomeHook.end()
will be called.