Why old nodes are visible even after deleting event files [Tensorflow]? - tensorflow

I have just started learning tensorflow, and wrote the following piece of code in Jupyter-Notebook :
a = tf.placeholder(tf.float32,shape=[3,3],name='X')
b = tf.constant([[5,5,5],[2,3,4],[4,5,6]],tf.float32,name='Y')
c = tf.matmul(a,b)
with tf.Session() as sess:
writer = tf.summary.FileWriter('./graphs',sess.graph)
print (sess.run(c,feed_dict={a:[[2,3,4],[4,5,6],[6,7,8]]}))
writer.close()
Running the tensorboard first time, gives a single X,Y and mult node as follows :
However, when I again compile my code (ctrl+enter), the tensorboard now makes a duplicate of the original graph.
I tried to resolve this( remove the older,dead nodes) by:
1. Deleting the event files.
2. Deleting the whole directory containing multiple event files of the same code.
3. Running fuser 6006/tcp -k before the tensorboard command line call.
But even after that, when I ran tensorboard, it would show the duplicate copies.
The only solution that worked was to reset the graph using tf.reset_default_graph() at the beginning of the code or to shut the notebook down and restart it.
My question is :
1. Why is it that even after deleting the event files, the older dead nodes keep showing up on the tensorboard ?. And yes I even restarted Tensorboard after each try, but duplicates were still there.
2. What are the ways if any, besides the two I listed above, to get rid of the dead nodes ?

The nodes you described are not dead. They are still exist and can be used.
When you run your code the first time, the nodes where created and added to the graph. When you execute the same cell for the second time, they are added one more time with the different names.
The same can be achieved if you will just copy twice the code in your .py file.
Your solution with tf.reset_default_graph() is the right one. Restarting the notebook works because all the information from the memory was removed. The same as rerunning .py file.
Your stuff with removing the even files does not work because nonetheless the files are removed, the nodes added to the graph in the memory are still there.

I was also having the same problem of tensorboard displaying duplicate graphs. I tried several measures like deleting the event files , deleting the log directory which contained the event files, but tensorboard would still remember the nodes and the graph from the previous run and show them as duplicate copies, one after another.
I noticed each time I ran the code tensorflow would create the same nodes but with different names, which means it was still keeping the old nodes in its memory. Looked something like this in the python execution window:
After first run:
After running the code 2nd and 3rd time:
This solved the problem
1) Restarting the kernel before each run solved the problem
2) As mentioned in above posts, adding tf.reset_default_graph() in the beginning of the code also solved the problem.

Related

GNURadio Companion and OFDM TX and RX in single Graph

I am following this github example for understanding OFDM on gnuradio-companion, I am able to execute ofdm_tx individually (64 and 512 FFT point) without any issues, but when I connect these two in single graph, I am able to get spectrum from ofdm_tx (no output from ofdm_rx or getting straight line).
My question here, each time I close my output spectrum, my tool get hanged and in background (inside gnu-companion) I observe the following message tarin (attached, printscreen). Similar thing also observed when I run ofdm_rx individually.
Error message in Console :
packet_headerparser_b :info: Detected an invalid packet at item 1448.
header_payload_demux :info :parser returned #f
Please guide me in this regard,
by selecting "NO" for vector source "Repeat" variable , issue sorted out (no hang), but not able to see spectrum anymore.

Pylint: same pylint and pandas version on 2 machines, 1 fails

I have 2 places running the same linting job:
Machine 1: Ubuntu over SSH
pandas==1.2.3
pylint==2.7.4
python 3.8.10
Machine 2: Gitlab CI Docker image, python:3.8.12-buster
pandas==1.2.3
pylint==2.7.4
Python 3.8.12
The Ubuntu machine is able to lint all the code fine, and it has for many months. Same for the CI job, except it had been running Python 3.7.8. Now that I upgraded the Docker image to Python 3.8.12, it throws several no-member linting errors on some Pandas objects. I've tried clearing CI caches etc.
I wish I could provide something more reproducible. But, to check my understanding of what a linter is doing, is it theoretically possible that a small version difference in python messes up pylint like this? For something like a no-member error on Pandas objects, I would think the dominant factor is the pandas version, but those are equal, so I'm confused!
Update:
I've looked at the Pandas code for pd.read_sql_query, which is what's causing the no-member error. It says:
def read_sql_query(
sql,
con,
index_col=None,
coerce_float=True,
params=None,
parse_dates=None,
chunksize: Optional[int] = None,
) -> Union[DataFrame, Iterator[DataFrame]]:
In Docker, I get E1101: Generator 'generator' has no 'query' member (no-member) (because I'm running .query on the returned dataframe). So it seems Pylint thinks that this function returns a generator. But it does not make this assumption in my other setup. (I've also verified the SHA sum of pandas/io/sql.py matches). This seems similar to this issue, but I am still baffled by the discrepancy in environments.
A fix that worked was to bump a limit like:
init-hook = "import astroid; astroid.context.InferenceContext.max_inferred = 500"
in my .pylintrc file, as explained here.
I'm unsure why/if this is connected to my change in Python version, but I'm happy to use this and move on for now. It's probably complex.
(Another hack was to write a function that returns the passed arg if the passed arg is a dataframe, and returns 1 dataframe if the passed arg is an iterable of dataframes. So the ambiguous-type object could be passed through this wrapper to clarify things for Pylint. While this was more intrusive on our codebase, we had dozens of calls to pd.read_csv and pd.real_sql_query, and only about 3 calls caused confusion for Pylint, so we almost used this solution)

Using Optaplanner for VRPPD

I am trying to run the example "optaplanner-mixedvrp-experiment" developed by Geoffrey De Smet and when I run it it throws me the following error:
Caused by: java.lang.IllegalStateException: The entity (MY) has a
variable (previousStandstill) with value (MUNO) which has a
sourceVariableName variable (nextVisit) with a value (WERBOMONT) which
is not null. Verify the consistency of your input problem for that
sourceVariableName variable.
I have not made any change, I have only cloned and executed it, I import and solve it and it throws me this error.
Do you know what could be happening?
I am applying it in the development of a variant of VRP with multiple deliveries and collections, but it throws me the same error. I have activated the FULL_ASSERT mode and nextVisit, previousStandstill, visitIndex are always null
It's been a long time since I looked at that code, so it's using an old version of optaplanner. Our goal is still to clean it up and offer an out of the box example for VRPPD (and probably remove some boilerplate along the way, using the upcoming #CollectionPlanningVariabe etc). That being said, we have multiple users&customers who used that optaplanner-mixedvrp-experiment to successfully build VRPPD implementations.
Which dataset did you try?
FWIW, that IllegalStateException says that when A.previous = B, the B.next is not A. So either the dataset importer didn't import it correctly - before calling solve() - especially if it fails before the first CH step in FULL_ASSERT. Or one of the custom moves corrupted the model.

Why are my flows not connecting?

Just starting with noflo, I'm baffled as why I'm not able to get a simple flow working. I started today, installing noflo and core components following the example pages, and the canonical "Hello World" example
Read(filesystem/ReadFile) OUT -> IN Display(core/Output)
'package.json' -> IN Read
works... so far fine, then I wanted to change it slightly adding "noflo-rss" to the mix, and then changing the example to
Read(rss/FetchFeed) OUT -> IN Display(core/Output)
'http://xkcd.com/rss.xml' -> IN Read
Running like this
$ /node_modules/.bin/noflo-nodejs --graph graphs/rss.fbp --batch --register=false --debug
... but no cigar -- there is no output, it just sits there with no output at all
If I stick a console.log into the sourcecode of FetchFeed.coffee
parser.on 'readable', ->
while item = #read()
console.log 'ITEM', item ## Hack the code here
out.send item
then I do see the output and the content of the RSS feed.
Question: Why does out.send in rss/FetchFeed not feed the data to the core/Output for it to print? What dark magic makes the first example work, but not the second?
When running with --batch the process will exit when the network has stopped, as determined by a non-zero number of open connections between nodes.
The problem is that rss/FetchFeed does not open a connection on its outport, so the connection count drops to zero and the process exists.
One workaround is to run without --batch. Another one I just submitted as a pull request (needs review).

AutoCAD script not reproducible

I wrote an AutoCAD script that is supposed to draw me two independent, spatially separated 3D polylines. After executing the script, however, I get connecions between the polylines. The funny thing is that two consecutive runs of the script may produce different connections.
AutoCAD scripts are very picky about blanks as they are sometimes interpreted as command termination indicators. There are no blanks at the end of the lines in the script below. There is, however a blank line at the end of the file.
3dpoly 396.958912852,30.8766759787,27.6970084442
392.314112161,78.0361288065,27.6970084442
383.307717991,107.726231443,27.6970084442
369.551813005,153.073372946,27.6970084442
354.926222488,180.435928247,27.6970084442
332.587844921,222.228093208,27.6970084442
312.905111301,246.211573517,27.6970084442
282.842712475,282.842712475,27.6970084442
258.859232165,302.525446095,27.6970084442
222.228093208,332.587844921,27.6970084442
194.865537907,347.213435437,27.6970084442
153.073372946,369.551813005,27.6970084442
123.383270309,378.558207175,27.6970084442
78.0361288065,392.314112161,27.6970084442
47.1594528278,395.355199309,27.6970084442
0.0,400.0,27.6970084442
-47.1594528278,395.355199309,27.6970084442
-78.0361288065,392.314112161,27.6970084442
-123.383270309,378.558207175,27.6970084442
-153.073372946,369.551813005,27.6970084442
-194.865537907,347.213435437,27.6970084442
-222.228093208,332.587844921,27.6970084442
-258.859232165,302.525446095,27.6970084442
-282.842712475,282.842712475,27.6970084442
-312.905111301,246.211573517,27.6970084442
-332.587844921,222.228093208,27.6970084442
-354.926222488,180.435928247,27.6970084442
-369.551813005,153.073372946,27.6970084442
-383.307717991,107.726231443,27.6970084442
-392.314112161,78.0361288065,27.6970084442
-396.958912852,30.8766759787,27.6970084442
-400.0,0.0,27.6970084442
-396.958912852,-30.8766759787,27.6970084442
-392.314112161,-78.0361288065,27.6970084442
-383.307717991,-107.726231443,27.6970084442
-369.551813005,-153.073372946,27.6970084442
-354.926222488,-180.435928247,27.6970084442
-332.587844921,-222.228093208,27.6970084442
-312.905111301,-246.211573517,27.6970084442
-282.842712475,-282.842712475,27.6970084442
-258.859232165,-302.525446095,27.6970084442
-222.228093208,-332.587844921,27.6970084442
-194.865537907,-347.213435437,27.6970084442
-153.073372946,-369.551813005,27.6970084442
-123.383270309,-378.558207175,27.6970084442
-78.0361288065,-392.314112161,27.6970084442
-47.1594528278,-395.355199309,27.6970084442
0.0,-400.0,27.6970084442
47.1594528278,-395.355199309,27.6970084442
78.0361288065,-392.314112161,27.6970084442
123.383270309,-378.558207175,27.6970084442
153.073372946,-369.551813005,27.6970084442
194.865537907,-347.213435437,27.6970084442
222.228093208,-332.587844921,27.6970084442
258.859232165,-302.525446095,27.6970084442
282.842712475,-282.842712475,27.6970084442
312.905111301,-246.211573517,27.6970084442
332.587844921,-222.228093208,27.6970084442
354.926222488,-180.435928247,27.6970084442
369.551813005,-153.073372946,27.6970084442
383.307717991,-107.726231443,27.6970084442
392.314112161,-78.0361288065,27.6970084442
396.958912852,-30.8766759787,27.6970084442
400.0,0.0,27.6970084442
396.958912852,30.8766759787,27.6970084442
3dpoly 392.314112161,78.0361288065,-27.6970084442
396.958912852,30.8766759787,-27.6970084442
400.0,0.0,-27.6970084442
396.958912852,-30.8766759787,-27.6970084442
392.314112161,-78.0361288065,-27.6970084442
383.307717991,-107.726231443,-27.6970084442
369.551813005,-153.073372946,-27.6970084442
354.926222488,-180.435928247,-27.6970084442
332.587844921,-222.228093208,-27.6970084442
312.905111301,-246.211573517,-27.6970084442
282.842712475,-282.842712475,-27.6970084442
258.859232165,-302.525446095,-27.6970084442
222.228093208,-332.587844921,-27.6970084442
194.865537907,-347.213435437,-27.6970084442
153.073372946,-369.551813005,-27.6970084442
123.383270309,-378.558207175,-27.6970084442
78.0361288065,-392.314112161,-27.6970084442
47.1594528278,-395.355199309,-27.6970084442
0.0,-400.0,-27.6970084442
-47.1594528278,-395.355199309,-27.6970084442
-78.0361288065,-392.314112161,-27.6970084442
-123.383270309,-378.558207175,-27.6970084442
-153.073372946,-369.551813005,-27.6970084442
-194.865537907,-347.213435437,-27.6970084442
-222.228093208,-332.587844921,-27.6970084442
-258.859232165,-302.525446095,-27.6970084442
-282.842712475,-282.842712475,-27.6970084442
-312.905111301,-246.211573517,-27.6970084442
-332.587844921,-222.228093208,-27.6970084442
-354.926222488,-180.435928247,-27.6970084442
-369.551813005,-153.073372946,-27.6970084442
-383.307717991,-107.726231443,-27.6970084442
-392.314112161,-78.0361288065,-27.6970084442
-396.958912852,-30.8766759787,-27.6970084442
-400.0,0.0,-27.6970084442
-396.958912852,30.8766759787,-27.6970084442
-392.314112161,78.0361288065,-27.6970084442
-383.307717991,107.726231443,-27.6970084442
-369.551813005,153.073372946,-27.6970084442
-354.926222488,180.435928247,-27.6970084442
-332.587844921,222.228093208,-27.6970084442
-312.905111301,246.211573517,-27.6970084442
-282.842712475,282.842712475,-27.6970084442
-258.859232165,302.525446095,-27.6970084442
-222.228093208,332.587844921,-27.6970084442
-194.865537907,347.213435437,-27.6970084442
-153.073372946,369.551813005,-27.6970084442
-123.383270309,378.558207175,-27.6970084442
-78.0361288065,392.314112161,-27.6970084442
-47.1594528278,395.355199309,-27.6970084442
0.0,400.0,-27.6970084442
47.1594528278,395.355199309,-27.6970084442
78.0361288065,392.314112161,-27.6970084442
123.383270309,378.558207175,-27.6970084442
153.073372946,369.551813005,-27.6970084442
194.865537907,347.213435437,-27.6970084442
222.228093208,332.587844921,-27.6970084442
258.859232165,302.525446095,-27.6970084442
282.842712475,282.842712475,-27.6970084442
312.905111301,246.211573517,-27.6970084442
332.587844921,222.228093208,-27.6970084442
354.926222488,180.435928247,-27.6970084442
369.551813005,153.073372946,-27.6970084442
383.307717991,107.726231443,-27.6970084442
392.314112161,78.0361288065,-27.6970084442
After some research I found out that if the object snap feature is on, AutoCAD apparently snaps during script execution. If the feature is turned off, everything's fine.