I checked nested optimization code in RevHack2020 repository. I want to implement nested optimization for a group. In the subproblem codes, I saw that we can implement run_driver() in compute method for an explicit component (here).
Can I implement run_driver() in group classes? (Since compute() method is for components, could not implement it in a group)
Note: I plan to use nested optimization in a pycyle "element" and it inherits from group class. It is the reason for me to implement in "group" class. Otherwise, I can change my model to explicitComponent.
No, you can't implement any custom run methods inside of groups. The only place users are supposed to implement execution is inside components.
In the case you described, you would place the pyCycle models into a problem of their own. Then you embed that problem into a containing component.
I don't follow why you feel the need to implement it in a group.
Related
In OpenMDAO 0.x there was a 'replace' method that let you swap components, not clear you can do that easily in 1.x. I have Problem that my outer loop algorithm has to run multiple times, and in some cases want to swap the computationally expensive custom MDA component out for a MetaModel Component which has the same i/o. Is there a quick and dirty way to do this at runtime?
I would just define a custom group class that takes an argument telling it which one to use. Rather than use a replace I suggest just re-instantiating the whole problem and calling setup again.
If, for some reason you don't want to call setup more than once (maybe its a big model and setup is slow), then I suggest you just create two problem instances. One will have the MMDA and the other will have the meta-model. In your outer loop you can just call whichever one is appropriate.
Sounds confusing to combine MetaModel and MDA problems. Having a MDA model suggests that the problem params and model are explicit, while the MetaModel suggests that the problem params and model are implicit which are two very different problems. Running two different problems conditionally seems contrary to the MDAO paradigm of a single system of non-linear equations and could get very messy to implement, IMHO.
If the intent of the MetaModel is to refine the initializing guess for the MDA, then perhaps the Component Implicit State concept in v1.7 is the built-in method to employ in the MDA problem and abandon the MetaModel thus reducing the problem to one set of equations? Beware that I have not tested the Component Implicit State method.
Otherwise, all OpenMDAO classes are just python classes and can have their solve_nonlinear methods modified to include conditional logic. Perhaps your project could create a parent problem and a parent group which control conditionally the execution of the solver and the data flows as needed between the MetaModel and the custom MDA?
Your thoughts?
I am trying to understand how one would choose whether to use a QAbstractListModel or a QObject with a QQmlListProperty.
Given that the QQmlListProperty handles the "roles" functionality that would have to be written using the QAbstractListModel, it seems like the less tedious route.
I can't tell if most people suggest using QAbstractListModel simply because it has been around longer or if it is the better choice for some reason.
Nor have I been able to find any discussion of the trade-offs between the two options. This question was brought up during a Qt Developer Days talk discussing QAbstractListModel, but the answer was along the lines of "that would also work".
A model implementation will generally be more efficient to work with a view. When you expose a "dumb list" to use a model, every time the model changes the whole view is reconstructed, whereas with a model only the changes are updated. If you have a lot of items there will be tangible performance overhead.
You could use a list for a model, and you could use a model for a list, but when you want optimal performance, you should use a list for a list, and a model for a model.
I want to implement in my program a tree with nested sub-levels, and I'm looking for which of those two kind(View/Widget) is best suited for my goal.
I have a list of days with task that are either done/missed/failed, each task has a count of how many times it was done/missed/failed and lastly a score for that day.
I want to display them like so:
I made this example in QtCreator using a QTreeWidget, but I'm worried that it would be hard to modify the elements since they are stored somewhere else.
Are my worries rational and should I go to the model/view structure, or can I easily get going with the QTreeWidget? The tree will be logging the task and thus will be constantly changing. Elements will only be added to it, not removed. And the days will be sorted from highest-lowest(day 2 is first, then day 1)
If your data is stored in a database model or if you want to have a single data model and show it in some views in different ways, then you are definitely better to go with QTreeView.
But QTreeWidget has it's internal model in some way along with the methods to deal with model in context of indexes. In general if you just want something that is simple to work, you can use the widget way.
But the Model/View approach is more general and flexible IMO. You can create your own subclasses of model and view which enables you to do whatever you like.
I'm reading up on the latest version of Qt, and it seems the Model/View/(Delegate) pattern is what's being pushed. It should be conceivable then to completely wire up the views without writing a single model, at least for the purpose of specing out how it looks. Is this the advised approach?
Also, where are the event wirings supposed to be placed? I assume that signals are coordinated by the MainWindow code?
You will need dummy models of course, made using existing Qt model classes. Looking at empty views is somewhat unhelpful, since you can't check out the primary delegates for the underlying model. Without any data, about the only delegates you can check out are the ones used in the headers, IIRC.
There are no event "wirings" on the view side of things, except for providing programmatic means of interacting with the view. The models may need a lot of interaction, depending on what's being modeled
Conceptually, you may have just one model that represents the data in your application, but it'd be a lot of spaghetti to expose various aspects of that model to the specialized views. You may then use view-models as adapters: they'd take the big model and expose a targeted slice of it, making it easier to consume by views. That's the pattern widely used in .net WPF.
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.