In an ExplicitComponent class, within the definition of the setup function is there a way to give the value of an output during its declaration based on the value of an input created just before in that setup function ?
For instance to do something like :
class Discipline_1(ExplicitComponent):
def setup(self):
self.add_input('Input_1', val=5.0)
self.add_output('Output_1',val = 0.07*inputs['Input_1'])
The idea is, as the 'NonlinearBlockGS' solver in a cycle use the 'val' information to initialize a fixed point method, I would like to give an appropriate initialization to minimize the number of 'NonlinearBlockGS' iterations.
If you really wanted to initialize the output based on the input value, just define the input value as a local variable:
class Discipline_1(ExplicitComponent):
def setup(self):
inp_val = 5.0
self.add_input('Input_1', val=inp_val)
self.add_output('Output_1',val = 0.07*inp_val)
That would only work if you had a fixed value known at setup time. You could pass that value into the class constructor via metadata to make it a little more general. However this may not be the most general approach.
Your group has a certain run sequence, which you could set manually if you liked. the GaussSeidel solver will execute the loop on that sequence, so you only need to initialize the value that is the the input to the first component in the loop. All the others will get their values passed to them by their upstream component source as the GS solver runs. This initial value could be set manually after setup is called by setting the value using the problem interface:
prob['Input_1'] = 5.0
As a side note in openmdao 2.0.2 we have a guess_nonlinear method defined on ImplicitComponents that you can use to initialize implicit output variables, but that is not applicable here
Related
I need to create Vector of Vector of predefined structure in Julia. As of now I am trying to do it via iterative concatenation:
struct Scenario
prob::Float64 # probability
time::Float64 # duration of visit
profit::Int64 # profit of visit
end
possible_times = [60, 90, 120, 150, 180]
scenarios = Scenario[]
for point in 1:num_points
profit = rand(1:4)
new_scenario = [Scenario(0.2, possible_times[i], profit) for i=1:5]
scenarios = vcat(scenarios, new_scenario)
end
display(scenarios)
But I got the following
Warning: Assignment to `scenarios` in soft scope is ambiguous because a global variable by the same name exists: `scenarios` will be treated as a new local. Disambiguate by using `local scenarios` to suppress this warning or `global scenarios` to assign to the existing global variable.
ERROR: LoadError: UndefVarError: scenarios not defined
So the first question is how to save the result of intermediate concatenation? And the second question is that way correct to achieve the goal? Or I do it wrong and there is another way?
Normally use append! instead of vcat:
for point in 1:num_points
profit = rand(1:4)
new_scenario = [Scenario(0.2, possible_times[i], profit) for i=1:5]
append!(scenarios, new_scenario)
end
If you want to use vcat use the global keyword:
for point in 1:num_points
profit = rand(1:4)
new_scenario = [Scenario(0.2, possible_times[i], profit) for i=1:5]
global scenarios = vcat(scenarios, new_scenario)
end
The point is that in scenarios = vcat(scenarios, new_scenario) you reassign the scenarios variable which is in global scope.
In general, the situation is a bit more complex (Julia behavior will depend on whether the code is run in interactive or non-interactive session), as you can read in this section of the Julia Manual (bullet 3 in this section on Soft scope). But if you do not want to dig into the details of scoping a simple and safe rule is: if you assign to a global variable then prefix the assignment operation with global.
I have my own function which I want to use via scifunc_block_m block. The function is defined in an .sci file, as suggested in this answer. Running the script from the scilab console before starting the simulation works fine. However, if I call exec() of this very .sci under xcos Simulation -> Set Context instead, the function seem to remain unknown in xcos. Am I missing something about the context setting?
It began with a function typed into scifunc_block_m or expression block. However,
I didn't want to make the block big and was unable to use .. to split the function definition over multiple lines to prevent the text spilling over the block boundaries.
The function will be used several times, I wanted a single definition vs copy&paste.
For the Set Context part:
I guess that you must specify the absolute path of fader_func.sci, either directly in the set Context box, or through a variable defined in the console:
--> fader_PATH = "C:\the\path\fader_func.sci"
// Then in the Context box;
exec(fader_PATH,-1);
Or directly in the Context box (far less portable solution):
exec("C:\the\path\fader_func.sci", -1);
about scifunc_block_m input
Continuation dots are unlikely supported. Instead, have you tried to explicitly split any long instruction in several shorter ones?
tmp = tanh((u3-u1+u2/2)/0.25/abs(u2))
y1 = 0.5 + sign(u2)*tmp/2
How do I retrieve outputs from objects in an array as described in the background?
I have a function in R that returns multiple variables. For eg. if my function is called function_ABC,then:
a<-function_ABC (input_var)
gives a such that a$var1, a$var2, and a$var3 exist.
I have multiple cases to run such that I have put then in an array:
input_var <- c(1, 2, ...15)
for storing the outputs, I declared var such that:
var <- c(v1, v2, v3, .... v15)
Then I run:
assign(v1[i],function(input_var(i)))
However, after that I am unable to access these variables as v1[1]$var1. I can access them as: v1$var1, or v3$var1, etc. But this means I need to write 15*3 commands to retrieve my output.
Is there an easier way to do this?
Push your whole input set into an array Arr[ ].
Open a multi threaded executor E of certain size N.
Using a for loop on the input array Arr[], submit your function calls as a Callable job to the executor E. While submitting each job, hold the reference to the FutureTask in another Array FTArr[ ].
When all the FutureTask jobs are executed, you may retrieve the output for each of them by running another for loop on FTArr[ ].
Note :
• make sure to add synchronized block in your func_ABC, where you are accessing shared resources to avoid deadlocks.
• Please refer to the below link, if you want to know more about the usage of a count-down-latch. A count-down-latch helps you to find out, when exactly, all the child threads have finished execution.
https://www.geeksforgeeks.org/countdownlatch-in-java/
I saw this example in the Julia language documentation. It uses something called Base. What is this Base?
immutable Squares
count::Int
end
Base.start(::Squares) = 1
Base.next(S::Squares, state) = (state*state, state+1)
Base.done(S::Squares, s) = s > S.count;
Base.eltype(::Type{Squares}) = Int # Note that this is defined for the type
Base.length(S::Squares) = S.count;
Base is a module which defines many of the functions, types and macros used in the Julia language. You can view the files for everything it contains here or call whos(Base) to print a list.
In fact, these functions and types (which include things like sum and Int) are so fundamental to the language that they are included in Julia's top-level scope by default.
This means that we can just use sum instead of Base.sum every time we want to use that particular function. Both names refer to the same thing:
Julia> sum === Base.sum
true
Julia> #which sum # show where the name is defined
Base
So why, you might ask, is it necessary is write things like Base.start instead of simply start?
The point is that start is just a name. We are free to rebind names in the top-level scope to anything we like. For instance start = 0 will rebind the name 'start' to the integer 0 (so that it no longer refers to Base.start).
Concentrating now on the specific example in docs, if we simply wrote start(::Squares) = 1, then we find that we have created a new function with 1 method:
Julia> start
start (generic function with 1 method)
But Julia's iterator interface (invoked using the for loop) requires us to add the new method to Base.start! We haven't done this and so we get an error if we try to iterate:
julia> for i in Squares(7)
println(i)
end
ERROR: MethodError: no method matching start(::Squares)
By updating the Base.start function instead by writing Base.start(::Squares) = 1, the iterator interface can use the method for the Squares type and iteration will work as we expect (as long as Base.done and Base.next are also extended for this type).
I'll grant that for something so fundamental, the explanation is buried a bit far down in the documentation, but http://docs.julialang.org/en/release-0.4/manual/modules/#standard-modules describes this:
There are three important standard modules: Main, Core, and Base.
Base is the standard library (the contents of base/). All modules
implicitly contain using Base, since this is needed in the vast
majority of cases.
Trying to initialize my seq2seq-model. I am using the GRU Cells, but cannot figure out Xavier-Initialization. The code in rnn_cell.py doesnt seem to allow that. Any ideas? Need to do this manually?
thx
The cell's weights are created using tf.get_variable() without specifying an initializer parameter. From https://www.tensorflow.org/versions/r0.10/api_docs/python/state_ops.html#get_variable:
If initializer is None (the default), the default initializer passed in the variable scope will be used.
Therefore, something like the following should work:
cell = tf.nn.rnn_cell.GRUCell(256)
with tf.variable_scope('RNN', initializer=tf.contrib.layers.xavier_initializer()):
outputs, state = tf.nn.dynamic_rnn(cell, ...)