dymos | Open Source Optimization of Dynamic Multidisciplinary
kandi X-RAY | dymos Summary
kandi X-RAY | dymos Summary
[Coverage Status] Dymos is a framework for the simulation and optimization of dynamical systems within the OpenMDAO Multidisciplinary Analysis and Optimization environment. Dymos leverages implicit and explicit simulation techniques to simulate generic dynamic systems of arbitary complexity. The software has two primary objectives: - Provide a generic ODE integration interface that allows for the analysis of dynamical systems. - Allow the user to solve optimal control problems involving dynamical multidisciplinary systems.
Support
Quality
Security
License
Reuse
Top functions reviewed by kandi - BETA
- Refine the model
- Evaluate ODE on the given grid
- Compute lagrange matrix
- Computes the interpolation matrix for interpolation
- Run balanced field length problem
- Classify a single variable
- Add a timeseries output
- Add a boundary constraint
- Configure the IO module
- Returns the source of a time series variable
- Build src documentation
- Get the source of the objective function
- Compute the parts of the transcription
- Get the source of a time series variable
- Add a control
- Configure the IO interface
- Adds a state
- Get the objective source for the given variable
- Configure inputs
- Configures the ODE model
- Configure the io output
- Run a racecar problem
- Propagates the ODE parameter
- Configure states for the solver
- Compute the derivative components
- Get the source for a time series
dymos Key Features
dymos Examples and Code Snippets
Community Discussions
Trending Discussions on dymos
QUESTION
I occasionally don't get convergence on my problem. My problem is setup as a Dymos problem. I am using IPOPT as my optimizer. If I am only running the problem once, I can check IPOPT.out for the converged string and that's ok.
I often want to run parameter sweeps, where I vary boundary conditions and problem options. I use Ray https://www.ray.io/, a python library for running parallel processes to do these. I turn off all file I/O that I can for this as otherwise the multiple processes interfere with each other writing to file.
However, it's then difficult to know if a particular process / case did not converge. For this reason actually having run_problem() return information on convergence would be useful. It doesn't seem to do that, so is there a way to get convergence info some other way, that does not involve reading a file?
I do realize there is the whole DOE driver system that is setup for OpenMDAO. However the learning curve looked rather steep. I got parallel processing working with Ray in a matter of hours, and it works quite well except for this one issue.
...ANSWER
Answered 2022-Mar-22 at 18:07prob.driver.fail
should be False
if the the optimization was successful, and doesn't need to be read from a file. However, given the various levels of success in optimizers this might not be completely accurate. For instance, solved to acceptable tolerance
vs. optimal solution found
is a little difficult to capture in a simple boolean output, and we should probably find a better way to report the optimizer's success.
QUESTION
For the Dymos problems I work with, I have code that adds states, controls, etc. in bulk and then use the set_XXX_options()
method to specify specific parameter values (e.g. opt=True
). This is easy for Dymos phases, because each phase has a add_XXX()
method and an associated set_XXX_options()
method. However, the trajectory.add_parameter()
method does an associated trajectory.set_parameter_options()
method.
Is there a reason the set_parameter_options()
method is not available for trajectory objects? Can it be added as a method?
ANSWER
Answered 2022-Feb-17 at 19:44This is a good point and there's no reason we can't add this method, and we should for API consistency.
In the mean time, you can access the parameter_options
dictionary after add_parameter to change settings. For instance,
QUESTION
I am implementing Bryson-Denham problem. The objective is:
$J=\frac{1}{2}\int_{0}^{1}u^2\left(t\right)dt$
and in the doc of Dymos, all explanation and examples state objective value as a scalar at loc=initial or loc=final. I could not find any example that use integral of some quantity over time as an objective function. Is this possible? How can I implement this?
FYI, Bryson-Denham problem is well-explained in this page: https://www.gpops2.com/Examples/Bryson-Denham.html
...ANSWER
Answered 2021-Dec-16 at 21:18Dymos will integrate any state you give it. In this case, you need to add a state for J and then also compute a state rate for it --- J_dot.
QUESTION
I have an ODE given in the form where x, u, and d are vectors (e.g. ) . I've formulated this system in OpenMDAO/Dymos using dimensioned inputs and outputs
...ANSWER
Answered 2021-Dec-08 at 17:43In general OpenMDAO You can have vector valued ref/ref0 for design variables. Dymos should, in theory, also support this. You can give a ref/ref0 the same size as your state and then Dymos will extend it out to the full
num_nodes
size for you. Unfortunately, as of Dymos V 1.30 it looks like this doesn't quite work. We've logged that bug here, and it should be fixed by V1.4.OpenMDAO does not allow mixed units within arrays. This was an intentional design choice related to details about how unit conversions are handled and how to keep them efficient (both in terms of memory and compute usage). Because OpenMDAO doesn't allow it, Dymos can't.
So you either need to split the state up into multiple variables, or work in nondimentional quantities.
- For parameters and controls this is fairly strait forward via OpenMDAO's APIs. If you want finer grained index control, just set opt=False for all of them. Dymos will expose them as inputs at the top of the phase/trajectory for you (you can use the N2 to find them). Then you can call the native OpenMDAO API
add_design_var
on those phase/trajectory level inputs with whatever indecies you want.
Doing this for states isn't a great idea. Without getting to far into the math... Dymos works really hard to keep a well defined (in the mathematical sense) optimization problem for you. For states that means carefully matching up the defect constraints with the design variables. You can't just turn off part of a state array without also addressing the corresponding defect constraints. Of course, if you mess with the defect constraints then you aren't getting valid physics any more. This is such a huge can of worms that you really just don't want to touch it.
QUESTION
I'd like to do some analysis downstream of my trajectory as described here
https://openmdao.github.io/dymos/faq/downstream_analysis.html
What I want to do is slightly different - I don't want to connect the end or beginning (or some fixed index) of a phase to some downstream component. What I want to do is find the node / time where a specific state is at its maximum value within a phase, and then connect various state variables for that time / node to my downstream analysis. The node / time where the max occurs will be change based on whatever the inputs to the problem are, so it can't really be known in advance
To be specific what I'm trying to do some analysis at point of maximum dynamic pressure (Max-Q) for the ascent of launch vehicle. I could probably just look at every single point in the phase where max-Q occurs, but maybe it's not necessary.
I could just use a "max" function on the array of dynamic pressure values of the phase, get the index and the other states of interest at that index. But then how do you differentiate that?
...ANSWER
Answered 2021-Nov-27 at 15:58You're correct that a max function is not differentiable. However, there is a similar function that we provide which is: the KS function
Its not a perfect replacement for a max, but in this context is it very good. You can pass in the entire time series and then it will output a close approximation of the maximum value from that array.
There is a rho
option which controls how close to a max function your approximation gets. A larger value is more max-like, but also has poorer numerical conditioning because the derivatives around the max start to get very larger. The default value of 50 is probably fine, but you can experiment with that value if you need to.
QUESTION
I was wondering if there are attempts to expand dymos to single shooting/multiple shooting problems. Essentially those ones which would solve the dynamic equations in every optimization query call (which would only use the controls as optimization variables). Currently there is the possibility to use solve_segments=True with an implicit numerical integrator (based on the transcription), and this would be similar but possibly also with explicit integrators (As forward Euler in its basic format, or variable step size ones)
This could be beneficial to explore for example global optimization techniques (and combinations) for trajectory optimization /mdo within the same platform and optimal control setup.
...ANSWER
Answered 2021-Aug-17 at 17:16As of Dymos 1.1.0, and August 2021, time-stepping integration is not included. As you pointed out solve_segments
provides very similar functionality. We are working on time-stepping, initially with fixed-step Euler integration. We plan to extend it to higher-order RK methods and adaptive-step. It will allow the same control transcriptions we already have (segment-by-segment interpolation of fully dynamic controls, and phase-wide interpolation of polynomial controls).
We not ready to announce a timeline for when this will be available though. It's still a bit early in development. A safe bet would be about 1 year before the feature is fully baked though.
QUESTION
Does openmdao or dymos have a vectroized matrix-matrix product component similar to MatrixVectorProductComp?
I would like to do a matrix multiplication of matrix A having a shape of (nn,3,3) times a matrix B having a shape of (nn,3,3), and the output being the result of shape (nn,3,3).
A 2D example of this with nn=2 could be:
...ANSWER
Answered 2021-Jul-17 at 12:33You didn't provide the code to your MatrixMatrixProductComp
, but I can make an educated guess as to whats going on because you referenced the MatrixVectorProductComp
in OpenMDAO's standard library.
For all components in OpenMDAO's standard library, the developers have already implemented and verified the derivatives. Thus, there is no need to have those components show up in the output of check_partials
for 99.9999% of the time. It would just clutter up the output that users need to see.
There is a hidden, undocumented, flag _no_check_partials
that gets turned on in these components so that check_partials
skips them. Now that I have blabbed about this hidden flag all over the internet :) ... here is where its assigned in the MatrixVectorProductComp
The Dymos library used this feature too, so that Dymos components didn't clutter up user check_partials outputs for their ODE components and groups.
Again, Dymos did this because those partials have already been carefully verified! Also there is special code in Dymos that flips that flag off so that internal tests can verify Dymos component partials.
Most likely you just need to set that attribute to False, and you'll get some check_partials output you can use in a test. I am being careful to emphasize that this flag should only be used with great caution. Bad partials will break an optimization, and if you have that flag turned on then you may simply never get a report of that component in check_partials.
In your case, you got burned by having no other components in your model, so you got the empty dictionary error. Generally, I do not recommend any user code use this flag at all.
QUESTION
We're searching a way to connect scalars (as an output) to vector entries (as an input).
In the "Nonlinear Circuit Analysis" example, there is a workaround in the class Node
which loops over the number of scalars and adds each scalar as a new input. In the class Circuit
, the added inputs are then accessed by their "indices" (e.g. 'I_in:0'
).
In our case, this loop must be integrated by a new Component, which solely loops the new inputs. This is why we'd like to avoid loops and directly use vector and matrix operations. In terms of the Circuit example, a way to achieve this would be to use some kind of target indices (see tgt_indices
), which are not implemented (yet 😊).
In this case both classes would look like this:
ANSWER
Answered 2021-May-27 at 12:36You are correct that there is currently no tgt_indices
like feature in OpenMDAO. Though it is technically feasible, it does present some API design and internal practical challenges. If you feel strongly about the need/value for this feature, you could consider submitting a POEM describing your proposed API for the dev-team to consider. You have a start on it with your provided example, but you'd need to think through details such as the following:
- what happens if a user gives both
src_indices
andtgt_indices
? - What do error msgs look like if there are overlapping
tgt_indices
- How does the api extend to the
promotes
function.
In the meantime you'll either need to use a MuxComponent, or write your own version of that component that would take in array inputs and push them into the combined matrix. Its slightly inefficient to add a component like this, but in the grand scheme of things it should not be too bad (as long as you take the time to define analytic derivatives for it. It would be expensive to CS/FD this component).
QUESTION
Traceback (most recent call last):
File "/home/rory/Documents/coloring_test/problemSolver.py", line 151, in
p.run_driver()
File "/home/rory/.local/lib/python3.6/site-packages/openmdao/core/problem.py", line 663, in run_driver
return self.driver.run()
File "/home/rory/.local/lib/python3.6/site-packages/openmdao/drivers/pyoptsparse_driver.py", line 493, in run
signal.signal(sigusr, self._signal_cache)
File "/usr/lib/python3.6/signal.py", line 47, in signal
handler = _signal.signal(_enum_to_int(signalnum), _enum_to_int(handler))
TypeError: signal handler must be signal.SIG_IGN, signal.SIG_DFL, or a callable object
...ANSWER
Answered 2021-Feb-16 at 16:11That error is caused by a feature that allows you to send a termination signal from the OS and get a clean exit from SNOPT. That feature seems to cause problems with some operating systems, and we should really turn it off by default.
You can work around the problem by setting:
QUESTION
Pretty nice feature. I am trying to figure out how to interpret the report to see if there are any glaring problems in my model that includes a trajectory with Dymos. My model usually converges fine, although sometimes I have to change the NLP scaling to gradient based. I have no idea what that really does but usually it will make IPOPT converge if the default setting doesn't work, and vice versa.
This the what the Jacobian looks like according to the tool
I am guessing that what is desired is that the order of magnitude of the partials in the Jacobian spans as few orders of magnitude as possible. The lower two diagonal bands have magnitudes from 0.1 to 10E5 and seem to be related to phase linkages. For example we have 'traj.linkages.phase_1:h_final|phase_2:h_initial wrt traj.phases.phase_1.indep_states.states:h' with a magnitude of 10E5. Should I be doing something about this?
In the design variables everything seems to be scaled ok, with driver values an order of magnitude of 1. In the constraints report the OOM span is wider from 10E-5 to 10E2. I am not setting defect_refs. Maybe I need to do something here?
...ANSWER
Answered 2021-Feb-10 at 22:19I tend to use the table that shows the norms from the driver and model perspectives.
In this case the driver values are all scaled on the order of 1 or so. If they're huge, then the scalers/refs may need to be adjusted. (Scaling to the order of around 1 isn't guaranteed to be a good strategy, but it's usually a pretty good going in position.
You may want to do this after limiting the driver iterations. For a converged case in dymos, the values of the defect constraints are going to be close to zero and this may not give you a good idea of their initial values.
For defect_refs, for instance, if I note that the value of the constraint were something like 5.5E4, then I might set that defect ref to 1.0E-4. Again, unit scaling isn't always correct, but it does frequently work.
Community Discussions, Code Snippets contain sources that include Stack Exchange Network
Vulnerabilities
No vulnerabilities reported
Install dymos
Support
Reuse Trending Solutions
Find, review, and download reusable Libraries, Code Snippets, Cloud APIs from over 650 million Knowledge Items
Find more librariesStay Updated
Subscribe to our newsletter for trending solutions and developer bootcamps
Share this Page