Skip to content
GitLab
Menu
Projects
Groups
Snippets
Loading...
Help
Help
Support
Community forum
Keyboard shortcuts
?
Submit feedback
Contribute to GitLab
Sign in / Register
Toggle navigation
Menu
Open sidebar
OpenDAS
dgl
Commits
a6ec8480
Unverified
Commit
a6ec8480
authored
Jan 14, 2021
by
Mufei Li
Committed by
GitHub
Jan 14, 2021
Browse files
[Doc] Update FAQ (#2536)
parent
1db75887
Changes
1
Show whitespace changes
Inline
Side-by-side
Showing
1 changed file
with
3 additions
and
63 deletions
+3
-63
docs/source/faq.rst
docs/source/faq.rst
+3
-63
No files found.
docs/source/faq.rst
View file @
a6ec8480
FAQ
Frequently Asked Questions (
FAQ
)
===
===
=============================
Troubleshooting
For frequently asked questios, refer to `this post <https://discuss.dgl.ai/t/frequently-asked-questions-faq/1681>`__.
----------------
Deep Graph Library (DGL) is still in its alpha stage, so expect some trial and error. Keep in mind that
DGL is a framework atop other frameworks, e.g., PyTorch, MXNet, so it is important
to figure out whether a bug is due to DGL or the backend framework. For example,
DGL will usually complain and throw a ``DGLError`` if anything goes wrong. If you
are pretty confident that it is a bug, feel free to raise an issue.
Out-of-memory
-------------
Graph can be very large and training on graph may cause out of memory (OOM) errors. There are several
tips to check when you get an OOM error.
* Try to avoid propagating node features to edges. Number of edges are usually
much larger than number of nodes. Try to use out built-in functions whenever
it is possible.
* Look out for cyclic references due to user-defined functions. Usually we recommend
using global function or module class for the user-defined functions. Pay
attention to the variables in function closure. Also, it is usually better to
directly provide the UDFs in the message passing APIs rather than register them:
::
# define a message function
def mfunc(edges): return edges.data['x']
# better as the graph `mfunc` does not hold a reference to `mfunc`
g.send(some_edges, mfunc)
# the graph hold a reference to `mfunc` so as all the variables in its closure
g.register(mfunc)
g.send(some_edges)
* If your scenario does not require autograd, you can use ``inplace=True`` flag
in the message passing APIs. This will update features inplacely that might
save memory.
Reproducibility
---------------
Like PyTorch, we also do not guarantee completely reproducible results across multiple releases,
individual commits or different platforms.
However, we guarantee determinism on both CPU and GPU for most of the operators defined in ``dgl.ops`` (and
thus built-in message-passing functions) from DGL v0.5 on, this being said you will get exactly the same
output/gradients in multiple runs by fixing the random seed of Python, Numpy, and backend framework. You are
expected to get the same training loss/accuracy if your program only uses deterministic operators in backend
framework (for PyTorch, see https://pytorch.org/docs/stable/notes/randomness.html) and deterministic DGL
message-passing operators/functions.
For message-passing, we do not guarantee the determinism only in following cases:
1. The backward phase of Min/Max reduce function (we depend on ``scatter_add_`` operator in backend frameworks,
and it's not guaranteed to be deterministic).
2. Message Passing on ``DGLGraph``'s with restricted format ``COO`` (this will only happen when user specifies
``formats='coo'`` when creating the graph, normal users should not specify ``formats`` argument, which is
only designed for expert users to handle extremely large graph).
Note that though operators above are not deterministic, the difference across multiple runs is quite small.
Write
Preview
Markdown
is supported
0%
Try again
or
attach a new file
.
Attach a file
Cancel
You are about to add
0
people
to the discussion. Proceed with caution.
Finish editing this message first!
Cancel
Please
register
or
sign in
to comment