As the title states, the get_val() function allows the user to retrieve the value of a input, output or residual. Is the anything like a get_partial(of=..., wrt=...) that allows a user to retrieve a derivative? Or what would be the best way to go about retrieving that from the problem or model?
For getting a general derivative in a system, the recommended practice is to use the compute_totals method.
Even if you just want to look at a partial derivative, you can use the of and wrt arguments to point to just the specific partial. You'll get a total, but it should be equal to the partial.
The general debugging practice for looking at partials is to use check_partials. This will give you full values of all the partials to look at. But if you need an algorithmic approach as part of a run script, then use compute_totals.
OpenMDAO stores outputs, so obtaining those is a matter of getting a value that's already there (hence get_val).
For derivatives, depending on the way in which OpenMDAO is used, there's no guarantee that the totals are present in memory, so they must be computed when needed.
Related
As per the title - say you have a fixed parameter like air density. Is it worth defining the partial w.r.t this fixed parameter?
If you know the value will be fixed forever (i.e. you'll never want to connect it to something else), the you don't need to declare derivatives for that combination of variables.
However I consider this to be a bad practice. In my experience, at some point in the future you will end up connecting something to that input, and then the total derivatives will be wrong. You could, of course, fix the derivatives at that point, but you might not remember and it will take you some time to debug the optimization and figure out the source of the bad derivatives. So as a best practice, I always differentiate all outputs with respect to all inputs.
Alternatively, you could declare density as an option instead of an input (see the docs on options) If you really want it to be a constant, this is the route I suggest.
For some of our components it would be useful to know whether it's being executed as part of a finite difference calculation or not. One example could be a meshing component where we'd want to maintain the same node count and distribution function during FD and allow for remeshing during major iteration steps. In the old OpenMDAO we could detect this from a component's itername. Would it be possible to reintroduce this or is that info already available to the Component class?
I can't think of any current way to figure out if you are inside an FD when solve_nonlinear is being called, but it's a good idea for the reasons that you mention.
We don't currently have that capability, but others have also asked to be informed when solve_nonlinear is being run for complex step as well.
One way to do this would be to introduce an optional_argument to solve_nonlinear such as call_mode="fd" or call_mode="cs" or call_mode="solve". The only problem with this approach is that its very backwards incompatible.
Another approach would be to add a regular python attribute to the component that you could check like self.call_mode="solve", etc. This one would be a pretty easy change and I think it would serve the purpose.
One last possible way would be to put a flag into the unknowns/params vector. So you would check params.call_mode to see what mode. This is somewhat sensible since its the param values that change when you're going to complex-step.
I think I like the last option the best. Both solve_nonlinear and apply_nonlinear need to know about this information. But none of the other methods do. So making it a component attribute seems a little out of place.
The Problem object in OpenMDAO is programmed to behave like a dictionary of all the Problem variables declared in the objects and what-not. Now I can iterate over normal dictionaries with for loops like:
for key,value in my_dict.iteritems():
do_something(key,value)
Could something like this be done with OpenMDAO problems?
I have a bunch of helpful utilities for working with dictionaries. I would like to use those to work with OpenMDAO problems as well.
Thanks!
I'm not exactly sure what you want to do, but it sounds like you want to iterate over all variables in the model? One way you could do that is to iterate over prob.root.unknowns, which is the vector that contains all the connected variables in the top System of your model. It is recursive in the sense that it includes connections that are specified in sub-systems. However, it doesn't include anything that isn't relevant for data-passing, so any Component inputs that aren't at least hooked up to an IndepVarComp won't show up in it.
The problem isn't really like a dictionary, we just define the __getitem__ and __setitem__ methods on it as a convenience for the user (see code). If you want to access the underlying dict-like object you can access prob.root.unknowns
instead. This is still not actually a dictionary, but a VecWrapper instance, but it is dict-like and has the the necessary methods to be used like one in a duck-typing sense.
I'm developing an major upgrade to the R package, and as part of the changes I want to start using the S3 methods so I can use the generic plot, summary and print functions. But I think I'm not totally sure I understand why and when to use generic functions in general.
For example, I currently have a function called logLikSSM, which computes the log-likelihood of a state space model. Instead of using this functions, I could make function logLik.SSM or something like that, as there is generic function logLik in R. The benefit of this would be that logLik is shorter to write than logLikSSM, but is there really any other point in this?
Similar case, there is a generic function called simulate in stats package, so in theory I could use that instead of simulateSSM. But now the description of the simulate function tells that function is used to "Simulate Responses", but my function actually simulates the hidden states, so it really doesn't fit into the description of the simulate function. So probably in this case I shouldn't use the generic function right?
I apologize if this question is too vague for here.
The advantages of creating methods for generics from the core of R include:
Ease of Use. Users of your package already familiar with those generics will have less to remember making it easier to use your package. They might even be able to do a certain amount without reading the documentation. If you come up with your own names then they must discover and remember new names which is an added cognitive burden.
Leverage Existing Functionality. Also any other functions that make use of generics you create methods for can then automatically use yours as well; otherwise, they would have to be changed. For example, AIC uses logLik.
A disadvantage is that the generic involves the extra level of dispatch and if logLik is in the inner loop of an optimization there could be an impact (although possibly not material). In that case you could check the performance of calling the generic vs. calling the method directly and use the latter if it makes a significant difference.
Regarding the case that your function has a completely different purpose than the generic in the core of R, then it might be more confusing than helpful so you might, in that case, not create a method but have your own function name.
You might want to read the zoo Design manual (see link to zoo Design under Vignettes near the bottom of that page) which discusses the design ideas that went into the zoo package. These include the idea being discussed here.
EDIT: Added disadvantates.
good question.
I'll split your Question into two parts; here's the first one:
i]s there really any other point in [making functions generic]?
Well, this pattern is usually invoked when the develper doesn't know the object class for every object he/she expects a user to pass in to the method under consideration.
And because of this uncertainty, this design pattern (which is called overloading in many other languages) is invokved, and which requires R to evaluate the object class, then dispatch that object to the appropriate method given the object type.
The second part of your Question: [i]n this case I shouldn't use [the generic function] right?
To try to give you an answer useful beyond the detail of your Question, consider what happens to the original method when you call setGeneric, passing that method in.
the original function body is replaced with code for performing a top-level dispatch based on type of object passed in. This replaces the original function body, which just slides down one level so that it becomes the default method that the top level (generic) function dispatches to.
showMethods() will let you see all of those methods which are called by the newly created dispatch function (generic function).
And now for one huge disadvantage:
Ease of MISUse:
Users of your package already familiar with those generics might do a certain amount without reading the documentation.
And therein lies the fallacy that components, reusable objects, services, etc are an easy panacea for all software challenges.
And why the overwhelming majority of software is buggy, bloated, and operates inconsistently with little hope of tech support being able to diagnose your problem.
There WAS a reason for static linking and small executables back in the day. But this generation of code now, get paid now, debug later if ever, before the layoffs/IPO come, has no memory of the days when code actually worked very reliably and installation/integration didn't require 200$/hr Big 4 consultants or hackers who spend a week trying to get some "simple" open source product installed and productively running.
But if you want to continue the tradition of writing ever shorter function/method names, be my guest.
When I try to refactor my functions, for new needs, I stumble from time to time about the crucial question:
Shall I add another variable with a default value? Or shall I use only one array, where I´m able to add an additional variable without breaking the API?
Unless you need to support a flexible number of variables, I think it's best to explicitly identify each parameter. In most cases you can add an overloaded method that has a different signature to support the extra parameter while still supporting the original method signature. If you use an array for passing variables it just makes it too confusing for users of your API. Obviously there are some inputs that lend themselves to an array (a list of points in a polygon, a list of account IDs you wish to perform an action on, etc.) but if it's not a variable that you would reasonably expect to be an array or list, you should pass it into the method as a separate parameter.
Just like many questions in programming, the right answer is "it depends".
To take Javascript/jQuery as an example, one good rule of thumb is whether the parameter will be required each time the function is called or whether it is optional. For example, the main jQuery function itself requires an expression to determine what element(s) the operation will affect:
jQuery(expresssion)
It makes no sense to try to pass this parameter as part of an array as it will be required every time this function is called.
On the other hand, many jQuery plugins require several miscellaneous parameters that may be optional. By convention, these are passed as parameters via an 'options' array. As you said, this provides a nice interface as new parameters can be added without affecting the existing API. This makes the API clean as well since the user can ignore those options that are not applicable.
In general, when several parameters are involved, passing them as an array is a nice convention as many of them are certainly going to be optional. This would have helped clean up many WIN32 API's, although it is more difficult to deal with arrays in C/C++ than in Javascript.
It depends on the programming language used.
If you have a run-of-the-mill OO language, you should use an object that you can easily extend, if you are really concerned about API consistency.
If that doesn't matter that much, there is the option of changing the method signature and overloading the method with more / different parameters.
If your language doesn't support either and you want the API to be binary stable, use an array.
There are several considerations that must be made.
Where is the function used? - Only in code you created? One place or hundreds of places? The amount of work that will need to be done to maintain existing code is important. Remember to include the amount of time it will take to communicate to other programmers that may currently be using your function.
How critical is the new parameter? - Do you want to require it to be used? If it has a default value, will that default value break existing use of the function in any subtle ways?
Ease of comprehension - How many parameters are already passed into the function? The larger the number, the more confusing and error prone it will be. Code Complete recommends that you restrict the number of parameters to 7 or less. If you need more than that, you should try to abstract some or all of the related parameters into one object.
Other special considerations - Do you want to optimize your efforts for any special conditions such as code speed or size? Are there any special considerations that must be taken into account for your execution environment? Keep in mind your goals for the project and make sure you aren't working against them with whatever design choice you make.
In his book Code Complete, Steve McConnell decrees that a function should never have more than 7 arguments, and rarely even that many. He presents compelling arguments - that I can't cite from memory, alas.
Clean Code, more recently, advocates even fewer arguments.
So unless the number of things to pass is really small, they should be passed in an enveloping structure. If they're homogenous, an array. If not, then a reasonably lightweight object should be built for the purpose.
You should do neither. Just add the parameter and change all callers to supply the proper default value. The reason is that parameters with default values can only be at the end, and will not be able to add any more required parameters anywhere in the parameters list, without having a risk of misinterpretation.
These are the critical steps to disaster:
1. add one or two parameters with defaults
2. some callers will supply it, and some will rely on defaults.
[half a year passed]
3. add a required parameter (before them)
4. change all callers to accept the required parameter
5. get a phone call, or other event which will make you forget to change one of the instances in part#2
6. now your program compiles perfectly, but is invalid.
Unfortunately, in function call semantics we usually don't have a chance to say, by name, which value goes where.
Array is also not a proper solution. Array should be used as a connection of similar objects, upon which there's a uniform activity performed. As they say here, if it's worth refactoring, it's worth refactoring now.