Turbulent boundary layer calculations break down at the point of flow separation when solved with a prescribed boundary layer edge velocity, ue, in what is called the direct method.
This can be alleviated by solving the system in a fully-simultaneous or quasi-simultaneous manner. Details about both methods are available here (https://www.rug.nl/research/portal/files/14407586/root.pdf), pages 38 onwards. Essentially, the fully-simultaneous method combines the inviscid and viscous equations into a single large system of equations, and solves them with Newton iteration.
I have currently implemented an inviscid panel solver entirely in ExplicitComponents. I intend to implement the boundary layer solver also entirely with ExplicitComponents. I am unsure whether coupling these two groups would then result in an execution procedure like the direct method, or whether it would work like the fully-simultaneous method. I note that in the OpenMDAO paper, it is stated that the components are solved "as a single nonlinear system of equations", and that the reformulation from explicit components to the implicit system is handled automatically by OpenMDAO.
Does this mean that if I couple my two analyses (again, consisting purely of ExplicitComponents) and set the group to solve with the Newton solver, I'll get a fully-simultaneous solution 'for free'? This seems too good to be true, as ultimately the component that integrates the boundary layer equations will have to take some prescribed ue as an input, and then will run into the singularity in the execution of its compute() method.
If doing the above would instead make it execute like the direct method and lead to the singularity, (briefly) what changes would I need to make to avoid it? Would it require defining the boundary layer components implicitly?
despite seeming too good to be true, you can in fact change the structure of your system by changing out the top level solver.
If you used a NonlinearBlockGS solver at the tope, it would solve in the weak form. If you used a NewtonSolver at the top, it would solve as one large monolithic system. This property does indeed derive from the unique structure of how OpenMDAO stores things.
There are some caveats. I would guess that your panel code is implemented as a set of intermediate calculations broken up across several components. If thats the case, then the NewtonSolver will be treating each intermediate variable as it it was its own state variable. In other words, you would have more than just delta and u_e as states, but also all the intermediate calculations too.
This is might be somewhat unstable (though it might work just fine, so try it!). You might need a hybrid between the weak and strong forms, that can be achieved via the solve_subsystems option on the NewtonSolver. This approach, is called the Hierarchical Newton Method in section 5.1.2 of the OpenMDAO paper. It will do a sub-iteration of NLBGS for every top level Newton iteration. This acts as a form of nonlinear preconditioner which can help stabilize the strong form. You can limit ho many sub-iterations are done, and in your case you may want to use just 2 or 3 because of the risk of singularity.
Related
I'm pretty new to OpenMDAO. If would like to setup my problem such that there is a subdiscipline that is driven by its own optimizer, and it hands off the results to the top level problem, where a separate optimizer will use those results.
For a bit more context, the sub-problem is trajectory optimization of a vehicle. I successfully got that problem to converge in a few iterations, without varying the vehicle parameters (mass, thrust, fuel etc.). So far so good. However, if I let the optimizer also vary some vehicle parameters, it can't seem to get it to go to the global optimum.
So my thought was to let trajectory optimization subproblem do what it does succesfully, and incorporate that as subproblem to the overall problem, and see if that works better.
So my question is:
Can an OpenMDAO problem have multiple drivers?
What's the right way to set that up? Do I wrap my subproblem into its own ExplicitComponent?
While this is possible, solving a problem in this way will not pass accurate analytic derivatives between the system design and the trajectory design.
We've developed another tool specifically for the purpose of doing multidisciplinary optimization which involves trajectory optimization. Dymos
It supports pseudospectral methods (like those in GPOPS, PSOPT, and OTIS) as well as shooting methods, and it allows a trajectory to be optimized as part of a larger system optimization problem.
Take a look at some of the example problems and see if it might work for you.
Looking into the class, I'm seeing that by default it looks like they're complex stepped. Is there a way to specify an analytical partial?
I've got some code that has a lot of essentially one liner explicit comps with analytical partials specified. Is there any real performance benefit to that over an ExecComp? Or with simple functions does work out to roughly the same?
There's currently no way to specify analytic partials for ExecComps and you're right that they're complex-stepped.
The short answer to your next question is that for simple functions there's no meaningful performance benefit using explicit components over ExecComp. This is because complex-step computes derivatives within machine precision when using an adequately small step size, which OpenMDAO does. The actual computational cost of performing the complex-step, for one-liners, is generally trivial.
The longer answer involves a few considerations, such as the sizes of the component's input and output arrays, the sparsity pattern of the Jacobian, and the cost of the actual compute function. If you want, I can go into more detail about these considerations and suggest which method to use for your problems.
[Edit: I've updated the figure with results for this compute: y=sum(log(x)/x**2+3*log(x)]
I've added a figure below showing the cost for computing derivatives of a component as we change the size of the input array to that component. The analytic component is slightly faster across the board, but requires more lines of code.
Basically, whichever method is easier to implement is probably advantageous as there's not a huge cost difference. For this extremely simple compute function, because it's so inexpensive, the framework overhead probably has a larger impact on cost than the actual derivative computation. Of course these trends are also problem dependent.
I implemented a system that is composed of few groups and multiple components. It is relatively intricate and has component inputs/outputs, which some partials are dependent/non dependent etc.
Gradient based optimizers seem to get stuck at the initial values and never go further than iteration 0 (not stuck at local optimum). I have encountered this error before as I was missing declare_partials for some variables. Is there a way to automatically check which component input/output is missing partials similar to missing connection in N^2 diagram.
There are two tools that you need to use to check for bad derivatives. The first is check_partials. That will go component by component and use either finite-difference or complex-step to verify the partial derivatives for every component (regardless of whether or not your declared them in the setup of that component). That will catch the problem if you are missing any partials, because the check-fd will see them as non-zero and will show you that there is an error.
Check_partials should be your first stop, always. If you can, use complex-step to verify your derivatives. That way you know they are totally accurate. Also, check_partials will do the check around whatever point is currently initialized. So sometimes you might have a degenerate case (e.g. you have some input that is 0) and so your check_passes, but your derivatives are still wrong. For example, if your component represented y=2*x, and you forgot to define derivatives, but you ran check_partials at x=0, then the check would pass. But if you ran it at x=1, then the check would show an error.
If all of your partial derivatives are correct, but you're still getting bad results then you can try check_totals. Depending on the structure of your model, and if you have any coupling in it (i.e. you need to use some kind of nonlinear solver) then its possible that you don't have a correctly configured linear solver setup to solve for total derivatives correctly. In a lot of cases, if you have coupling you can just put a DirectSolver right at the same level as the nonlinear solver you put in the model.
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?
The case I am solving is two discipline aerospace problem. The architecture is IDF. I am using recorders to record the data at each iteration. I am using finite difference. I am using SLSQP optimizer from SciPy.
If after few major iteration, the optimization crashes during line search. How to start the line search from the same point?
Apart from that, I want to check whether the call to solver_nonlinear() of Component is called for purpose of derivative calculation or for line search, from inside the component. Is there a way to do it?
SLSQP doesn't offer any built in restart capability, so there isn't a whole lot you can do there. Pyopt-sparse does have some restart capability that OpenMDAO can use. Its called "hot-start" in their code.
As for knowing if a solve_nonlinear is for derivative calculations or not, I assume you mean that you want to know if the call is for an FD step or not. We don't currently have that feature.