Optimal MGA and MGA-1DSM trajectories - PyKEP/PyGMO

[f1re]

Great. I knew that you couldn't resist
I can't comment the operation itself yet, because your binary suffers from this known issue.

Oh damn dynamic libraries. Of course MinGW had a lurking DLL in it's lib folder which was on my library path.

If I could already suggest something regarding packaging of your addon:
1) Could you please move the "MGAPlans" under "Config/MFD" directory? Less root tree pollution.

Sure thing.

2) I know your project is open to public via Web, but would it be possible if you script automatic fetching of the source and store it under "OrbiterSDK/GravityAssistMFD" before zipping and distributing?

Right, GPL. I think I can pack it up with the depdendencies bundled, so that it's possible to work with it without MinGW.
I'll see to it, it violates license like this.

[EDIT] Could you point me to the source, where you expose the variables via ModuleMessagingExt?

https://github.com/tuzcsaba/orbiter...FD/src/ModuleMessaging/MGAModuleMessenger.cpp

I feel that I'll also need to add the planets, but I found some troubles sharing out buffers. I might need to switch to sharing in-dll-reference to do that.

The things which should affect TransX:
- escape:
- n_flyby: each of these is a slingshot, velocity, outward, inclination specified.

Ok, I'll look into these, but have to do some not-so-fun coding for now, the fun coding have to wait till the evening... darn...

And yeah, I couldn't resist I tried, but it's futile.

 

[boogabooga]

I tried it, but it's complaining about missing GDIClient.dll.

GDIClient is sitting happily in my Modules/Server folder, so not sure what the problem is.

 

[f1re]

I tried it, but it's complaining about missing GDIClient.dll.

GDIClient is sitting happily in my Modules/Server folder, so not sure what the problem is.

I only tested this with D3D9Client, without Graphic client, Modules/Server is probably not on the library path.

I have the issue too if I start orbiter.exe. I probably have to check on the linkage for Modules which should run under both stock rendering and Graphic engines.

Also, please note Enjo's remark, we have another missing DLL too.

I'll get back with an update which fixes the DLL problems, once I get to it.

Sorry for the inconveniences, but one of the reasons I shared it a bit prematurely is to see how it behaves on virgin systems without all my dev stuff on it.

 

[Enjo]

Sorry for the inconveniences, but one of the reasons I shared it a bit prematurely is to see how it behaves on virgin systems without all my dev stuff on it.

No wonder, since it uses so many advanced libraries and is cross-compiled after all. Somebody has to test it and it's worth it.

 

[f1re]

GravityAssistMFD-0.11

So, as I promised, I fixed the few hiccups you came back with (Thank you for those).

GravityAssistMFD-0.11
https://github.com/tuzcsaba/orbiter-kep/blob/master/Install-Package/GravityAssistMFD-0.11.zip

Changelog:
- Added the missing MinGW dlls
- Removed unnecessary linkage to GDIClient.dll which allows module to work on stock rendering
- Took Enjo's advices on Directory structure
- Added source to installer package, but it's not an open-and-compile style, the CMAKE project is added, and it is not trivial (not hard if you know CMAKE, but there are a few things to set) to make it build. I'll work on that later.

Thanks for sticking with me, have fun (if it starts up)

 

[Enjo]

- Added source to installer package, but it's not an open-and-compile style, the CMAKE project is added, and it is not trivial (not hard if you know CMAKE, but there are a few things to set) to make it build. I'll work on that later.

The most important thing is that the source is there. It will only be used by people clever enough to set it all up by themselves anyway.

Test pending...

---------- Post added at 06:55 PM ---------- Previous post was at 06:47 PM ----------

libprotobuf-10.dll missing
[EDIT] You also doubled the MGAPlans under both "Config" and "Config/MFD"

 

[f1re]

The most important thing is that the source is there. It will only be used by people clever enough to set it all up by themselves anyway.

Test pending...

---------- Post added at 06:55 PM ---------- Previous post was at 06:47 PM ----------

libprotobuf-10.dll missing

Ok, this was the final. I took some extra precautions now, renaming folders where the DLLs are, and trying to run that way.

https://github.com/tuzcsaba/orbiter-kep/blob/master/Install-Package/GravityAssistMFD-0.13.zip

Upcoming rounds will be quicker.

[EDIT]

[EDIT] You also doubled the MGAPlans under both "Config" and "Config/MFD"

Probably leftover from previous state of the ZIP, I don't have that folder created anymore.

 

[Enjo]

No dependency errors, but although I enabled the module, it didn't show up in the custom functions list (Ctrl + F4)

 

[f1re]

No dependency errors, but although I enabled the module, it didn't show up in the custom functions list (Ctrl + F4)

Well, I'm in a bit of a trouble then now, since it shows up for me. Something crashes into itself during InitModule call.

crap... Not sure what to do at this point, so I suppose that's it for now . At least the packager now packages all necessary dlls.

 

[Enjo]

You could print some messages to a text file, or better - I could run a debug session. Give me some time for this, though. I'm in the middle of doing something else.

 

[boogabooga]

No dependency errors, but although I enabled the module, it didn't show up in the custom functions list (Ctrl + F4)

???

It works fine for me now, but I did have to install the Visual C++ Redistributable for Visual Studio 2015.

It just seems to be a bit of a resource hog.

 

[f1re]

???

It works fine for me now, but I did have to install the Visual C++ Redistributable for Visual Studio 2015.

It just seems to be a bit of a resource hog.

Interesting, did you get notified that VC Redist is needed, or just figured it out?

Well yes, it'll use your iron a lot when you are running optimisation, GlobOpt is resource intensive thing. You shouldn't feel it though when you are just using existing solution.

It's mainly the resource intensity of calculations why the caching of solutions were added. As you see, plans can be saved into files, the solutions are also saved, so it's possible to create and share repositories of plans, so that the calculations don't have to be repeated all the time.

You might want to decrease Generations and adjust Number of Islands to number of your cores - 1.

This is not something you use during flight, but rather before flight, and during flight just use the cached things to execute the plan.

I wonder why it doesn't work for Enjo. Can it be some interference with one of the other modules?

 

[boogabooga]

It complained about msvcp140.dll being missing from my computer, and I knew what that was.

But, it might be a good idea to document the dependency.

Err, my cores - 1 = 0. :uhh:

I'm going to try to narrow down the timeframe so there is less space to search....

 

[f1re]

It complained about msvcp140.dll being missing from my computer, and I knew what that was.

But, it might be a good idea to document the dependency.

Err, my cores - 1 = 0. :uhh:

I'm going to try to narrow down the timeframe so there is less space to search....

Ok, you should be fine with 1 islands in that case, but definitely decrease it to 1.
The number of islands is just to allow utilising your full computing power, it's for parallelism.

There will be a proper standalone tool as well which you can run outside of orbiter, but it's right now only partially useful for optimisation.

So yeah, shareability of plans is on the board, so that people without a nuclear power plant under the desk can have the fruits too. But that needs infrastructure to store the plans, but I don't plan to spend other than time on this thing, so not yet prepared to start an AWS for it.

 

[Keithth G]

Well yes, it'll use your iron a lot when you are running optimisation, GlobOpt is resource intensive thing. You shouldn't feel it though when you are just using existing solution.

Resource hogging was always going to be a problem with an MFD of this kind. Trajectory optimisation requires a lot of computing power - and the more complex the trajectory, the more computing power you need.

In Orbiter-Land (at least until very recently), the distinction between 'mission planning' and 'mission execution' have been decidedly blurred. But if one wishes to develop an optimised mission (using, say, global optimisation tools) computing requirement forces a greater emphasis on making a clear separation between planning the mission, and then execution of that mission. This will appeal to some users of Orbiter but not everyone.

 

[boogabooga]

I would suggest a GUI change in which you specify the starting planet in a separate box.

I didn't understand right away that to get to, say, Jupiter, (ex. Hohman transfer) the itinerary needs to be Earth, Jupiter, not just Jupiter.

 

[f1re]

I would suggest a GUI change in which you specify the starting planet in a separate box.

I didn't understand right away that to get to, say, Jupiter, (ex. Hohman transfer) the itinerary needs to be Earth, Jupiter, not just Jupiter.

Thanks for the feedback, it makes perfect sense, any comment of this kind is greatly appreciated.

 

[boogabooga]

Also, and this may not be practical, but- if you were able to add a DSM to the itinerary in the same way you were able to add a planet, that would be really useful.

I tried to plan an earth-earth-Jupiter slingshot, but it is putting a DSM on every leg instead of just the first.

 

[f1re]

Also, and this may not be practical, but- if you were able to add a DSM to the itinerary in the same way you were able to add a planet, that would be really useful.

I tried to plan an earth-earth-Jupiter slingshot, but it is putting a DSM on every leg instead of just the first.

Hmm, I'm not sure I understand. The time of DSMs is part of the decision vector, and subject to optimisation as well.

I also noticed, that very often, practically 0 deltaV DSMs are added, which are considered to be noise. But if you do MGA-1DSM optimisation, theoretically there is a DSM during every leg.

What I can do, is to skip display of the DSM, when it's delta-V is very near 0. And actually due to the fact that PyKEP uses slightly different ephimerides than Orbiter (something I am planning to do something about), in practice you will need mid-course correction even if you execute an MGA plan.

Not sure what you are thinking of, please elaborate.

 

[boogabooga]

But if you do MGA-1DSM optimisation, theoretically there is a DSM during every leg.

That is NOT necessarily desirable .

See this thread for example:
http://www.orbiter-forum.com/showthread.php?t=36986

You want the DSM on the first leg, but NOT the second. It's fine to optimise the time of the burn, etc., but you should (if possible) give the user a choice as to which legs will have one.

I understand that you are doing a global optimization, and thus should naturally arrive at a solution with a ~0 m/s burn on the second leg, but in my tests it was having trouble finding it.