I am just playing around with the Paraboloid tutorial in OpenMDAO. I tried something simple, basically changing the input values to the Paraboloid component. See the following code. When I run it though, it will print the same result as if nothing happened. So what is going on? if I have a group, how would I modify the inputs?
from __future__ import print_function
from openmdao.api import IndepVarComp, Component, Problem, Group
class Paraboloid(Component):
""" Evaluates the equation f(x,y) = (x-3)^2 + xy + (y+4)^2 - 3 """
def __init__(self):
super(Paraboloid, self).__init__()
self.add_param('x', val=0.0)
self.add_param('y', val=0.0)
self.add_output('f_xy', val=0.0)
def solve_nonlinear(self, params, unknowns, resids):
"""f(x,y) = (x-3)^2 + xy + (y+4)^2 - 3
"""
x = params['x']
y = params['y']
unknowns['f_xy'] = (x-3.0)**2 + x*y + (y+4.0)**2 - 3.0
def linearize(self, params, unknowns, resids):
""" Jacobian for our paraboloid."""
x = params['x']
y = params['y']
J = {}
J['f_xy', 'x'] = 2.0*x - 6.0 + y
J['f_xy', 'y'] = 2.0*y + 8.0 + x
return J
if __name__ == "__main__":
top = Problem()
root = top.root = Group()
root.add('p1', IndepVarComp('x', 3.0))
root.add('p2', IndepVarComp('y', -4.0))
root.add('p', Paraboloid())
root.connect('p1.x', 'p.x')
root.connect('p2.y', 'p.y')
root.p1.x=3.0;
root.p2.y=-4.0;
top.setup()
top.run()
print(root.p.unknowns['f_xy'])
root.p1.x=5.0;
root.p2.y=5.0;
top.setup()
top.run()
print(root.p.unknowns['f_xy'])
You have to call setup() before you can set any values.
After that you set them via a dictionary like access from the problem instance. For your sample code it should look like:
top.setup()
top['p1.x'] = 3.
top['p2.y'] = 4.
top.run()
print(top['p.f_xy'])
top['p1.x'] = 10.
top['p2.y'] = 10.
top.run()
print(top['p.f_xy'])
When I run this model with the adjusted script I get:
##############################################
Setup: Checking for potential issues...
No recorders have been specified, so no data will be saved.
Setup: Check complete.
##############################################
73.0
342.0
Related
Is it possible to optimize a single list entry in OpenMDAO 1.X? In this example, I desire to add/optimize the first entry of z. In my real problem, it is impossible for me to add the entire vector as a design variable (I'm using NREL's DAKOTA driver). I thought I could make dummy variables connected to z, but looks like 1.X does not support connecting variables to list entries.
ppb.py:
from __future__ import print_function
import numpy as np
from dakota_driver.driver import pydakdriver
from openmdao.api import ScipyOptimizer
from openmdao.api import IndepVarComp, Component, Problem, Group
class Paraboloid(Component):
""" Evaluates the equation f(x,y) = (x-3)^2 + xy + (y+4)^2 - 3 """
def __init__(self):
super(Paraboloid, self).__init__()
self.add_param('x', val=6.0)
self.add_param('y', val=-7.0)
self.add_param('z', val=np.array([2., 2., 2.]))
self.add_output('f_xy', val=0.0)
def solve_nonlinear(self, params, unknowns, resids):
"""f(x,y) = (x-3)^2 + xy + (y+4)^2 - 3
"""
x = params['x']
y = params['y']
z = params['z']
unknowns['f_xy'] = z[0]*(x-3.0)**2 + x*y + (y+4.0)**2 - 3.0 + abs(z[0]-4)
def linearize(self, params, unknowns, resids):
""" Jacobian for our paraboloid."""
x = params['x']
y = params['y']
z = params['z']
J = {}
J['f_xy', 'x'] = 2.0*x - 6.0 + y
J['f_xy', 'y'] = 2.0*y + 8.0 + x
J['f_xy', 'z'] = (x-3.0)**2 + 1
return J
top = Problem()
root = top.root = Group()
root.add('p1', IndepVarComp('x', 13.0))
root.add('p2', IndepVarComp('y', -14.0))
root.add('p3', IndepVarComp('z', np.array([0.0, 0., 0.])))
root.add('p', Paraboloid())
root.connect('p1.x', 'p.x')
root.connect('p2.y', 'p.y')
root.connect('p3.z', 'p.z')
top.driver = ScipyOptimizer()
top.driver.options['optimizer'] = 'Powell'
top.driver.add_desvar('p3.z[0]', lower=-30., upper=30.) # <--- Is it possible to do this?
top.driver.add_objective('p.f_xy')
top.setup()
top['p1.x'] = 3.0
top['p2.y'] = -4.0
#top['p3.z'] = 2.0
top['p3.z'] = np.array([0., 0., 0.])
top.run()
Run Results:
$ python ppb.py
Traceback (most recent call last):
File "ppb.py", line 75, in <module>
top.setup()
File "/scratch/jquick/1.0/lib/python2.7/site-packages/openmdao/core/problem.py", line 586, in setup
raise NameError("Can't find param of interest '%s'." % v)
NameError: Can't find param of interest 'p3.z[0]'.
Specify the index to be optimized using the indices keyword:
top.driver.add_desvar('p3.z', lower=-30., upper=30., indices=[0])
I have a param that is a 2D array. It works fine with getting the correct output but when I try to do anything with the gradients such as optimization or check_total_derivatives I get a sizing error. I was wondering what the best way is to handle params that are of size 2D. Here is a sample code:
import numpy as np
from openmdao.api import Group, Problem, Component, IndepVarComp, ExecComp
class C1(Component):
def __init__(self, n):
super(C1, self).__init__()
self.add_param('grid', val=np.zeros((n, n)))
self.add_output('x', shape=1)
self.n = n
def solve_nonlinear(self, params, unknowns, resids):
x = 0
for i in range(self.n):
for j in range(self.n):
x += params['grid'][i][j]
unknowns['x'] = x
def linearize(self, params, unknowns, resids):
J = {}
J['x', 'grid'] = np.ones((self.n, self.n))
return J
class Group1(Group):
def __init__(self, n):
super(Group1, self).__init__()
self.add('grid', IndepVarComp('grid', np.zeros((n, n))), promotes=['*'])
self.add('c1', C1(n), promotes=['*'])
self.add('obj_cmp', ExecComp('obj = -x', x=1.0), promotes=['*'])
n = 3
p = Problem()
p.root = Group1(n)
p.setup(check=False)
p['grid'] = np.ones((n, n))
p.run()
p.check_total_derivatives()
print p['x']
I get the error:
ValueError: In component 'c1', the derivative of 'x' wrt 'grid' should have shape '(1, 3)' but has shape '(3, 3)' instead.
I feel like the derivative in this case should be of size (3, 3) because that is the size of the input param. How do you handle 2D params?
You have a small mistake in the Jacobian; it should look like this:
def linearize(self, params, unknowns, resids):
J = {}
J['x', 'grid'] = np.ones((1, self.n*self.n))
return J
The output x is length 1, while the param grid is n by n, so it is length n*n, so the resulting J should be 1 by 9. With that change, I get the right answer.
I did notice a mistake in the error message. It should say that the expected shape is (1, 9) instead of (1, 3). I will put in a fix for that.
When you have a 2D variable and need to construct the gradient, flatten it (in row-major order) and formulate the gradient based on the flattened version.
Is unit conversion with pass_by_obj supported in OpenMDAO 1.4? I have a small repro case:
from openmdao.api import Component, Problem, Group, IndepVarComp
pass_by_obj=True
class PassByObjParaboloid(Component):
def __init__(self):
super(PassByObjParaboloid, self).__init__()
self.fd_options['force_fd'] = True
self.add_param('x', val=1.0, pass_by_obj=pass_by_obj, units='mm')
self.add_output('f_xy', val=0.0)
def solve_nonlinear(self, params, unknowns, resids):
print params['x']
assert params['x'] == 1000.0
unknowns['f_xy'] = params['x']
def linearize(self, params, unknowns, resids):
raise Exception()
top = Problem()
root = top.root = Group()
root.add('p1', IndepVarComp('x', 1.0, pass_by_obj=pass_by_obj, units='m'))
root.add('p', PassByObjParaboloid())
root.connect('p1.x', 'p.x')
top.setup()
top.run()
With pass_by_obj=True, the assert fails. top.setup() reports:
Unit Conversions
p1.x -> p.x : m -> mm
So I'd expect the unit conversion to be done.
OpenMDAO currently does not support automatic unit conversions for pass_by_obj variables. When designing OpenMDAO, we didn't intend for floating point data to be transferred using pass_by_obj. We only added pass_by_obj to handle other kinds of variables. We should fix the diagnostic output of setup so that it doesn't list unit conversions that don't actually happen. I'll put a story in for that.
I have a situation where the gradient of one component is by necessity calculated in another component. What I have attempted to do is just have the gradient be an output from the first component and an input to the second component. I have set it to be pass_by_obj so that it doesn't affect other calculations. Any recommendations on whether or not this would be the best way to do it would be appreciated. Nevertheless, I am getting an error when using check_partial_derivatives(). It seems to be an error for any output that is specified as pass_by_obj. Here is a simple case:
import numpy as np
from openmdao.api import Group, Problem, Component, ScipyGMRES, ExecComp, IndepVarComp
class Comp1(Component):
def __init__(self):
super(Comp1, self).__init__()
self.add_param('x', shape=1)
self.add_output('y', shape=1)
self.add_output('dz_dy', shape=1, pass_by_obj=True)
def solve_nonlinear(self, params, unknowns, resids):
x = params['x']
unknowns['y'] = 4.0*x + 1.0
unknowns['dz_dy'] = 2.0*x
def linearize(self, params, unknowns, resids):
J = {}
J['y', 'x'] = 4.0
return J
class Comp2(Component):
def __init__(self):
super(Comp2, self).__init__()
self.add_param('y', shape=1)
self.add_param('dz_dy', shape=1, pass_by_obj=True)
self.add_output('z', shape=1)
def solve_nonlinear(self, params, unknowns, resids):
y = params['y']
unknowns['z'] = y*2.0
def linearize(self, params, unknowns, resids):
J = {}
J['z', 'y'] = params['dz_dy']
return J
class TestGroup(Group):
def __init__(self):
super(TestGroup, self).__init__()
self.add('x', IndepVarComp('x', 0.0), promotes=['*'])
self.add('c1', Comp1(), promotes=['*'])
self.add('c2', Comp2(), promotes=['*'])
p = Problem()
p.root = TestGroup()
p.setup(check=False)
p['x'] = 2.0
p.run()
print p['z']
print 'gradients'
test_grad = open('partial_gradients_test.txt', 'w')
partial = p.check_partial_derivatives(out_stream=test_grad)
I get the following error message:
partial = p.check_partial_derivatives(out_stream=test_grad)
File "/usr/local/lib/python2.7/site-packages/openmdao/core/problem.py", line 1699, in check_partial_derivatives
dresids._dat[u_name].val[idx] = 1.0
TypeError: '_ByObjWrapper' object does not support item assignment
I asked before about the params being checked for pass_by_obj in check_partial_derivatives() and it might be simply a matter of checking the unknowns for pass_by_obj as well.
the error you're getting is another bug related to check_partial_derivatives function. It should be easy enough to fix, but in the meantime you can just remove the pass_by_obj setting. Since you're computing a value in one component and passing it to another, there isn't a need to do pass_by_obj at all (and it will be more efficient if you don't).
You said that you did it so that it "doesn't affect other calculations", but I don't quite know what you mean by that. It won't affect anything unless you use it in the solve_nonlinear method.
I have a component that has an input that is an int so I am setting pass_by_obj = True. However, when I check derivatives with check_partial_derivatives(), it throws this error:
data = prob.check_partial_derivatives(out_stream=sys.stdout)
File "/usr/local/lib/python2.7/site-packages/openmdao/core/problem.py", line 1711, in check_partial_derivatives
jac_rev[(u_name, p_name)][idx, :] = dinputs._dat[p_name].val
TypeError: float() argument must be a string or a number
It appears to be trying to take the derivative even though it cannot. Here is a simple example:
import sys
from openmdao.api import IndepVarComp, Problem, Group, Component
class Comp(Component):
def __init__(self):
super(Comp, self).__init__()
self.add_param('x', val=0.0)
self.add_param('y', val=3, pass_by_obj=True)
self.add_output('z', val=0.0)
def solve_nonlinear(self, params, unknowns, resids):
unknowns['z'] = params['y']*params['x']
def linearize(self, params, unknowns, resids):
J = {}
J['z', 'x'] = params['y']
return J
prob = Problem()
prob.root = Group()
prob.root.add('comp', Comp(), promotes=['*'])
prob.root.add('p1', IndepVarComp('x', 0.0), promotes=['x'])
prob.root.add('p2', IndepVarComp('y', 3, pass_by_obj=True), promotes=['y'])
prob.setup(check=False)
prob['x'] = 2.0
prob['y'] = 3
prob.run()
print prob['z']
data = prob.check_partial_derivatives(out_stream=sys.stdout)
It is possible to use the check_partial_derivatives() method with components that have inputs that are specified as pass_by_obj? I don't care about the derivatives for the inputs that are specified as pass_by_obj, but I care about the other inputs.
Thanks for the report and test. This was a bug where we weren't excluding the design variables that were declared pass_by_obj. I've got a pull request up on the OpenMDAO repo with a fix. It'll probably be merged to master within a day.
EDIT -- The fix is merged. https://github.com/OpenMDAO/OpenMDAO/commit/b123b284e46aac7e15fa9bce3751f9ad9bb63b95