Q. I noticed that in the lecture, when making a dependency graph for problem 1, that you didn't include the area A (you simply drew "L depends on V"). I was wondering if that was a mistake, or if it was left out on purpose. Does that bear any significance ?
A. That was a mistake. The "signal" A should indeed have been included.
Q. You said that by doing a Topological Sort of the Dependency Graph, we are able to get an ordering by which we should "solve"/"execute" the simulation. My question is : When doing this Topological Sort, FROM WHICH NODE do we start the DFS ? Because I noticed that depending on the vertex of the graph that I choose to be my starting point, I may get different output values for the Topological Sort (each of them "topologically correct"). OR is it the case that any ordering of vertices are correct, as long as they are topologically ordered ?
A. An answer in two parts:
Topological Sort does not yield a unique answer. Depending on the order in which "children" of a node are visited, a different node numbering (sorting) will result. This is to be expected as a topological sort orders nodes in a lattice (partial ordering, where not all nodes can be compared to one another). This is not a disadvantage as ANY "topologically correct" sorting result will yield correct simulation results. Note how when we choose one of the several sorting results, we are "sequentializing" the problem (introducing a total ordering). We could, on a parallel device, process a DAG in a parallel fashion, only synchronizing where necessary.
It would be reasonable to say "start topological sort from a node which does not have incoming edges". There are however cases where such a node does not exist (if the whole graph is one large strongly connected component, for example). Thus, a topological sort routine is "randomly" started from an unvisited node in the graph. This procedure is repeated until no more unvisited nodes remain.
Q. What are the different approaches for generating LaTeX and Simulink/Octave representations from a CBD model ?
A. For generating LaTeX, there are (at least) two approaches. The second one can also be used to generate input for Simulink/Octave.
In the first approach, you truly generate the denotational
semantics of your CBD model: a set of algebraic equations.
You loop over all blocks and for every block write the
appropriate equation which relates its input signals to its output
signal. Although not really necessary, you would probably write these
equations in "causal" form:
output = some function of inputs
Note how this does require every signal to have a unique name
(in your CBD model, the block_name attribute of the block producing that
signal at its output). Not only does this require checking that all the
block_name attributes given by the user are unique
(or the generated denotational semantics would not make sense),
but also that a non-empty block_name is given for every block to start with.
Obviously, testing for uniqueness would also find empty block_names.
As it is, we often leave block_name empty as we are not interested in
naming intermediate signals. If you use this first approach, you must check
whether all blocks have a non-empty block_name and are unique.
For empty block_names, you have to assign unique names to
generate the denotational semantics (LaTeX).
The above approach is useful for generating LaTeX, but will not work
for generating an M-file representation of the model. Conversely,
the second approach described below will also produce a meaningful
algebraic model (in LaTeX).
In this approach, we'll write all differential equations in ``explicit''
form (the way Simulink and Octave want them):
dx/dt = f(other integrator block vars), x(0) = g(constants only)
The actual form of f and g depends on the topology of the CBD model.
Note how you can either write constants' values or write their name
(if given) and add an equation:
constant_name = constant_value
Q. How does Plotting work for CausalBlockDiagram models ?
A.
When you click on a Plot block, a DataSet
object is created. It is attached at the global
level to the model (not the node)
as model.data. If the appropriate
plotWindow is set up, any change to
model.data will trigger an update of
all the views of that data. How to change
model.data ? By calling its method
append(). This method expects a list
of values such as [0.1, 2, 4.5]. In the example,
a Generator is used to produce such
values. This data production
must be replaced by your Time Slicing simulator.
Data generation (simulation) and plotting must
run in separate threads to allow "real-time"
updating of the plots.
Have a look at (and run)
Plotting/PlotTest.py for an example
independent of AToM3.
Q. Does an attribute I add on-the-fly to a model in AToM3 (to keep track of whether a node was already visited, for example) get saved when I save the model ?
A. No. AToM3 only saves the pre-defined (in the formalism's meta-model) attributes and their values which you enter through "Edit model attributes" for global attributes and through "Edit entity" for local attributes.
Q. How to interactively ask the user for a filename (to write LaTeX or Matlab/Octave output in, for example) ?
A. The tkFileDialog module provides a file browser dialog. For reading:
import tkFileDialog
filename = tkFileDialog.askopenfilename()
fd = open(filename, 'r')
fd.read(...)
fd.close
or, for writing:
filename = tkFileDialog.asksaveasfilename()
fd = open(filename, 'w')
fd.write(...)
fd.close
For more information, have a look at the information at the Tkinter tutorial
(thanks to Marc Lanctot)
The point of using UNIX tools under Windows (in particular, to unzip and untar .tgz files) came up in class. Both WinZip and WinRAR can handle tarballs.
In general, there are two simple ways a Windows user can become UNIX-compatible:
Make your computer dual-bootable and install Linux in addition to Windows.
Install Cygwin www.cygwin.com. Cygwin is a unix-like shell and tools suite for Windows (not a kernel emulator). It comes with many Windows ports of the common unix commands/shells/programs like grep, sh, vi, bash, csh, apache, python, gcc, gdb, lynx, perl, tar, gzip, ssh, sftp, and even XFree86 !