I need in my DirectShow graph 2 independent filter chains (1: microphone –> net and 2: net -> speakers). They must work simultaneously.
My filters (net) are implemented as usual C++ object (DLL is not used).
Is it possible to have independent chains in the graph ? Or should I create second graph for the 2nd chain ?
If I should create the 2nd graph, are there additional requirements to make it work in parallel ?
Related
I'm wondering if this is correct. Most of the Implicit and Explicit components I have created use the line:
self.declare_coloring(wrt='*', method='cs', tol=1.0E-12, show_sparsity=True)
Then when I get to the file that runs the driver I use:
p.driver.declare_coloring()
And in my /coloring_files directory I have a 'col' and a 'disc' for each component.
coloring_traj_phases_phase0_rhs_col_brakeThrottle.pkl coloring_traj_phases_phase0_rhs_disc_implicitOutputs.pkl
coloring_traj_phases_phase0_rhs_col_implicitOutputs.pkl coloring_traj_phases_phase0_rhs_disc_powerTrain.pkl
coloring_traj_phases_phase0_rhs_col_powerTrain.pkl coloring_traj_phases_phase0_rhs_disc_spin.pkl
coloring_traj_phases_phase0_rhs_col_spin.pkl coloring_traj_phases_phase0_rhs_disc_timeAdder.pkl
coloring_traj_phases_phase0_rhs_col_timeAdder.pkl coloring_traj_phases_phase0_rhs_disc_timeSpace.pkl
coloring_traj_phases_phase0_rhs_col_timeSpace.pkl coloring_traj_phases_phase0_rhs_disc_tracking.pkl
coloring_traj_phases_phase0_rhs_col_tracking.pkl coloring_traj_phases_phase0_rhs_disc_tyreConstraint.pkl
coloring_traj_phases_phase0_rhs_col_tyreConstraint.pkl coloring_traj_phases_phase0_rhs_disc_tyre.pkl
coloring_traj_phases_phase0_rhs_col_tyre.pkl total_coloring.pkl
coloring_traj_phases_phase0_rhs_disc_brakeThrottle.pkl
Are both sets of files needed or am I repeating an operation twice? Also I'm wondering if declaring coloring with the driver is using a method other than CS? I do intent on using the total_coloring.pkl for static coloring.
Dymos can use one of two methods for transcription: The Radau Pseudospectral Method or the high-order GaussLobatto method.
The GaussLobatto method is a two-step process:
The ODE is evaluated at the "discretization" nodes.
The values and rates at the discretization nodes are used to interpolate the state and state rates to the "collocation" nodes.
The ODE is evaluated a second time at the collocation nodes using the interpolated state values from step 2.
The interpolated rates are compared to the rates output by the ODE at the collocation nodes (these are called the defects) - if they're tiny, then the physics are assumed to be accurate.
The Radau transcription follows a similar process, except the collocation nodes are a subset of the discretization nodes, so interpolation isn't necessary, and the ODE only needs to be evaluated once.
If you change your transcription from dymos.GaussLobatto to dymos.Radau, then you'll only have one partial-coloring file for each of your ODE components. Otherwise, both need to have their coloring worked out separately.
Terminology note: "vertices"="nodes", "vertex/node labels" = "indices"
LightGraphs in Julia changes node indices when producing induced subgraphs.
For instance, if a graph has nodes [1, 2, 3, 4], its LightGraphs.induced_subgraph induced by nodes [3,4] will be a new graph with nodes [3,4] getting relabeled as [1,2].
In state-of-the-art graph algorithms, recursive subgraphing is used, with sets of nodes being modified and passed up and down the recursion layers. For these algorithms to properly keep track of node identities (labels), subgraphing must not change the indices.
Subgraphing in networkx in Python, for instance, preserves node labels.
One can use MetaGraphs by adding a node attribute :id, which is preserved by subgraphing, but then you have to write a lot of extra code to convert between node indices and node :id's.
Is there not a Julia package that "just works" when it comes to subgraphing and preserving node identities?
I'd first like to take the opportunity to clarify some terminology here: LightGraphs itself doesn't dictate a graph type. It's a collection of algorithms and an interface specification. The limitations you're seeing are for SimpleGraphs, which is a graph type that ships with the LightGraphs package and is the default type for Graph and DiGraph.
The reason this is significant is that it is (or at least should be) very easy to create a graph type that does exactly what you want and that can take advantage of the existing LightGraphs infrastructure. All you (theoretically) need to do is to implement the interface functions described in src/interface.jl. If you implement them correctly, all the LightGraphs algorithms should Just Work (tm) (though they might not be performant; that's up to the data structures you've chosen and interface decisions you've made).
So - my advice is to write the graph structure you want, and implement the dozen or so interface functions, and see what works and what doesn't. If there's an existing algorithm that breaks with your interface implementation, file a bug report and we'll see where the problem is.
I'm writing a bunch of recursive graph algorithms where graph nodes have parents, children, and a number of other properties. The algorithms can also create nodes dynamically, and make use of recursive functions.
What are the right data structures to use in this case? In C++ I would've implemented this via pointers (i.e. each node has a vector<Node*> parents, vector<Node*> children), but I'm not sure if Julia pointers are the right tool for that, or if there's something else ... ?
In Julia state-of-the-art with this regard is the LightGraphs.jl library.
It uses adjacency lists for graph representation and assumes that the data for nodes is being kept outside the graph (for example in Vectors indexed by node identifiers) rather than inside the graph.
This approach is generally most efficient and most convenient (operating Array indices rather than references).
LightGraphs.jl provides implementation for several typical graph algorithms and is usually the way to go when doing computation on graphs.
However, LightGraphs.jl,'s approach might be less convenient in scenarios where you are continuously at the same time adding and destroying many nodes within the graph.
Now, regarding an equivalent of the C++ approach you have proposed it can be accomplished as
struct MyNode{T}
data::T
children::Vector{MyNode}
parents::Vector{MyNode}
MyNode(data::T,children=MyNode[],parents=MyNode[]) where T= new{T}(data,children,parents)
end
And this API can be used as:
node1 = MyNode(nothing)
push!(node1.parents, MyNode("hello2"))
Finally, since LightGraphs.jl is a Julia standard it is usually worth to provide some bridging implementation so your API is able to use LightGraphs.jl functions.
For illustration how it can be done for an example have a look for SimpleHypergraphs.jl library.
EDIT:
Normally, for efficiency reasons you will want the data field to be be homogenous across the graph, in that case better is:
struct MyNode{T}
data::T
children::Vector{MyNode{T}}
parents::Vector{MyNode{T}}
MyNode(data::T,children=MyNode{T}[],parents=MyNode{T}[]) where T= new{T}(data,children,parents)
end
I'm trying to use NS-3 simulator to do some tests between random waypoint model and some other models. While during the simulation I found that when need to run the simulation we need to initiate the model by using a class called
MobilityHelper
Code below is the part of the code that I am using. During the initialization, there are some nodes need to be created beforehand such as
p2pNodes
csmaNodes
So what do these nodes mean, and in which situation need to use them? Are they specify to some specific mobility models? If so please give some details, many thanks!
NodeContainer p2pNodes;
p2pNodes.Create (3);
PointToPointHelper pointToPoint;
pointToPoint.SetDeviceAttribute ("DataRate", StringValue ("5Mbps"));
pointToPoint.SetChannelAttribute ("Delay", StringValue ("2ms"));
NetDeviceContainer p2pDevices;
p2pDevices = pointToPoint.Install (p2pNodes);
NodeContainer csmaNodes;
csmaNodes.Add (p2pNodes.Get (1));
csmaNodes.Create (nCsma);
CsmaHelper csma;
csma.SetChannelAttribute ("DataRate", StringValue ("100Mbps"));
csma.SetChannelAttribute ("Delay", TimeValue (NanoSeconds (6560)));
NetDeviceContainer csmaDevices;
csmaDevices = csma.Install (csmaNodes);
p2pNodes and csmaNodes are simply variable names for the NodeContainer used in this particular example in order to keep track of nodes for the two newtorks (a Point-to-Point and a CSMA). The fact that you name them p2pNodes or csmaNodes is only for your conveniency. What matters, is the types of NetDevices they get installed.
In any case, that has nothing to do with the MobilityModel that you install.
Both P2P and CSMA are wired networks and I wouldn't think of adding a random mobility on those. It wouldn't make sense to move around with a wire attached to you..!
Note that the above example code will crash, as you have created 3 p2pNodes, and a point-to-point link can only be instantiated between two nodes.
I would recommend to study the ns-3 tutorial to get an understanding of the consepts of Nodes, NodeContainers (ie. vectors of Nodes), NetDevices (ie. the network card/type), MobilityModel etc
It seems that when I use nngraph model, it is easy to do so.
If I use only normal conv, then how can I do it?
When you define a model, for example a convnet with nn.Sequential() and adding modules to it like
net = nn.Sequential()
net:add(nn.SpatialConvolution(3,3,1,1)
net:add(...) -- add other modules
you can access to a module with net.modules[n] (n is the index of the module, use print(net) to see your whole network and its modules). Then each module has to state variables output and gradInput (gradient of the module with respect to its input), then you can access the output of the nth intermediate layer with
net.modules[n].output