-
Notifications
You must be signed in to change notification settings - Fork 1.9k
Tensorflow.RuntimeError: 'Current graph is not default graph. Default Graph Key #4568
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
Comments
Bump - I'm seeing this issue again in a new project but it's somehow different. This time, I cannot load a 2nd model no matter what. I.e. in my above examples, both cases now cause estimator 2 to throw the "Current graph is not default graph" error. For now, we're having to load the model from disk on each inference pass. Works but slowing down a bit, would love to be able to load multiple models from disk 1x then infer whenever I want. |
I am able to repro this in my local environment, let me dig up little bit and get back to you |
@BillMcCrary This error message "Current graph is not default graph" is thrown directly from tf.net. you can set default graph to any graph you want using as_default, take a look below as reference: Below is an code sample that works in your case (note: we don't provide any public method or field to let you have access to tensorflow session so below code is a work around using reflection):
|
We would like to be able to load multiple models from disk on startup, then infer against them without having to reload from disk each pass.
If I try to keep 2 models in memory at the same time, I get an error if not calling against the last one initialized from disk.
i.e. this works - only including code needed to generate the error:
but this throws an error like "Tensorflow.RuntimeError: 'Current graph is not default graph":
I guess we could roll our own process to load from disk to stream 1x, then call context.Model.Load() but that still smells wrong - we're still initializing the model over and over just avoiding disk calls. Is this a bug or are we doing something wrong?
The text was updated successfully, but these errors were encountered: