Python parsing failure: networkx

[FlorianDeconinck]

Describe the bug
Previously generating (0.14) code is now failing to parse triggering a

networkx.exception.NetworkXError: nbunch is not a node or a sequence of nodes.

This is with dace:gpu backend.

To Reproduce
I couldn't recreate the error in a pure DaCe setting, so the above uses a regression test from the Pace respository. It is the smallest test that triggers the above bug

# Repo is to run the FiniteVolumeTransport regression test
# Original code: fv3core/pace/fv3core/stencils/fvtp2d.py
# DaCe is applied on the __call__ function

# Get Pace repository
git clone -b update/gt4py_dace git@github.com:GEOS-ESM/pace
cd pace
git submodule init
git submodule update

# Setup the venv, including Cupy for GPU
python -m venv .venv
source .venv/bin/activate
pip install --upgrade pip
pip install external/gt4py/
pip install -r requirements_dev.txt -c constraints.txt
pip install cupy-cuda12x # REPLACED with relevant CUDA


# Download data
mkdir -p test_data/8.1.3/c12_6ranks_standard/dycore
cd test_data/8.1.3/c12_6ranks_standard/dycore
pip install gdown
gdown https://drive.google.com/uc?id=1Fz2KSWwmy4cpIjYzXKJbkdzsVwHgZuok
gdown https://drive.google.com/uc?id=1GJRYQxRAkQcHbBPvF5KVngrYjrTt1Pdw
gdown https://drive.google.com/uc?id=1SOO97ncz-fCGVoPD7pUuYY9uYowUjato
gdown https://drive.google.com/uc?id=1Wcb1l7GXE5C_82oItGo7RkKloWlJCKR4
cd -

# Run test of FvTp2d
export FV3_DACEMODE=BuildAndRun 
export PACE_CONSTANTS=GFS
pytest -v -s --data_path=./test_data/8.1.3/c12_6ranks_standard/dycore \
       --backend=dace:gpu --which_modules=FvTp2d --which_rank=0 \
       --threshold_overrides_file=./fv3core/tests/savepoint/translate/overrides/standard.yaml \
       ./fv3core/tests/savepoint

tested with python 3.8.10

Expected behavior
The above code runs a full regression test, expected to pass.

[alexnick83]

#1314 has a fix for this, although another underlying issue might exist. The problem can be seen in SDFG subgraph below. In state assign_1059_4, q_x_flux writes to another array, which is implied to be "return" data (name ends in __ret_N) and, therefore, should not be transient. Could you verify if this is OK (the test seems to pass with the fix), i.e., the actual return data is q_x_flux?

[FlorianDeconinck]

All 75 smaller regressions tests pass with #1314, that's a coverage of all non-mpi elements of the model. Previously ~10% where seeing this bugs - looks like it's fixed nicely!

Tested with commit 866e38