Some questions

[Mazalg]

Sorry, I am new in Git, how can I contact authors to ask several questions? I am trying to adopt the examples to 3dof model with rotating earth.

[ina111]

hi, I'm author. Questions here are welcome. I am aware that there is some problems with the convergence of solutions in 3dof.

[Mazalg]

Thank you for your response!

I have tried to adopt your two stage to polar orbit example to my launch vehicle parametrs. Everything seems OK, beside the one strange thing. Sometimes SLSQP-solver failed with «Inequality constraints incompatible» and sometimes everything is OK and convergence is fine. The problem is that happens on the same code, without any changes in its structures or parametrs. Did you face with such problem?

Am I right that all the «unit» are using for scaling the problem to near [-1, +1] domain? And is it possible to fix final time of the problem? For example, I want that SECO was at t+624, no less, no more. Or in some boundaries. I have read docs but don't understand.

About 3dof problem. I have been trying to work with PSOPT optimization software about this problem and have failed with convergence of the model with my parametrs, while model with Deltha III launch vehicle was succesfully run. After conversation with people from aerospace industry, I suppose that convergence problem could be caused by a solution procedure of NLP. They said, for aerospace problems the method of sequential quadratic programming is much better than IPOPT. That is why I am here, your method use SLSQP :) So it is hoped there will be good convegence.

Now I am triyng to adopt the example form PSOPT for two stage rocket to your software. https://github.com/PSOPT/psopt/blob/master/PSOPT/examples/launch/launch.cxx But I failed :) Even the SLSQP procedure does not launch.

---- iteration : 1 ---- Traceback (most recent call last): File "two_stage_win.py", line 455, in <module> prob.solve(obj, display_func, ftol=1e-3) File "C:\Users\Mizarate\AppData\Local\Programs\Python\Python35-32\lib\site-packages\OpenGoddard\optimize.py", line 681, in solve "ftol": ftol}) File "C:\Users\Mizarate\AppData\Local\Programs\Python\Python35-32\lib\site-packages\scipy\optimize\_minimize.py", line 458, in minimize constraints, callback=callback, **options) File "C:\Users\Mizarate\AppData\Local\Programs\Python\Python35-32\lib\site-packages\scipy\optimize\slsqp.py", line 311, in _minimize_slsqp meq = sum(map(len, [atleast_1d(c['fun'](x, *c['args'])) for c in cons['eq']])) File "C:\Users\Mizarate\AppData\Local\Programs\Python\Python35-32\lib\site-packages\scipy\optimize\slsqp.py", line 311, in <listcomp> meq = sum(map(len, [atleast_1d(c['fun'](x, *c['args'])) for c in cons['eq']])) File "C:\Users\Mizarate\AppData\Local\Programs\Python\Python35-32\lib\site-packages\OpenGoddard\optimize.py", line 647, in for_solver return func(arg0, arg1) File "C:\Users\Mizarate\AppData\Local\Programs\Python\Python35-32\lib\site-packages\OpenGoddard\optimize.py", line 619, in equality_add result = np.hstack((result, derivative - (tfx - tix) / 2.0 * dx)) ValueError: operands could not be broadcast together with shapes (147,) (127,)

two_stage_win.txt

If you have time, could you look through it?

Thank you!

[Mazalg]

two_stage_win.txt I simplyfied all the dynamics, rechecked boundary condition and anyway failed to start solution with the same error.

«line 619, in equality_add result = np.hstack((result, derivative - (tfx - tix) / 2.0 * dx)) ValueError: operands could not be broadcast together with shapes (147,) (127,)»

Everything looks like X and Y in «shapes (x.) (y.)» go from n = [n1, n2] num_states = [ns1, ns2]

X = n1 ns1, Y = n1 ns1-n1.

Moreover, it does not let me to define n1 != n2, while I saw it is possible in example 11_polar_TSTO_Taiki.

[Mazalg]

Hi!

I am still trying to run my example. I find some black magic related to problem I told you in last post. This problem was eliminated by using state variables in ALL the derivates.

dx[0] = Vx 
dx[1] = Vy
dx[2] = Vz
dx[3] = vdot[0]
dx[4] = vdot[1]
dx[5] = vdot[2]
dx[6] = -mdot+1+m-m

As you can see, there are some dummy using of «m» in the last equlation. You can use any state variable there. I don't understand why it's so and what to do with it. Hope it will be useful information for you. Problem with definition n1 != n2 and is still there.

It's becoming to look like something good, while there a lot of work here to recheck everything and after all make sure about convergence to some real solution. two_stage_win.txt

[ina111]

Hi, I saw your last post. dx[6] = -mdot+1+m-m mdot is scalar( type is "flaot") and m is vector(type is "numpy.array". As you know, dx[6] must be vector. The problem is that the type is different. I recommend the following modifications. mdot = T_tot/(obj.g0*obj.Isp[section]) * np.ones(m.size)

[ina111]

I see your script and tell you some of my experiences. In the example of OpenGoddard 's rocket problem, I use a polar coordinate system. There is a reason for this. I tried it in the Cartesian coordinate system, but there were problems with the convergence of the solution or violated the constraint condition. This was solved by correcting to the polar coordinate system even with the same equations of motion and constraints. Unfortunately the detailed reason is unknown, but probably it is likely to influence the convergence of the solution by rotating operation in the dynamics and the nonlinearity of this operation.

[Mazalg]

Hi! Thank you for the explanations!

But did you face with problem when the solution changes every time you run application? Even if you don't change anything in the code. It's seems very strange and doesn't allow me to control the process.

[ina111]

I have not experienced the problem that the result changes with each execution. As an elementary thing, I can only think about checking whether the initial value in the code is using the previous result.

[athulpg007]

Hi there!

@Mazalg, what exactly was the problem you faced with the Delta III problem? Please see this issue and let me know if you have any comments.

Thanks