Project Gmat integration

[potjoe]

Hi everyone,

I'm starting to think about creating an addon, or let say an intermediate piece of lua code to begin with, that would help to convert Orbiter datas to Gmat in real time. I know that there are some restrictions to such a conversion, (https://www.orbiter-forum.com/showthread.php?t=35243&page=2) but i still consider it relevant. I may be wrong on that one, but I need your help to determine if it is at least doable.

What's the aim ? We've seen some tools to convert trajectories from propagators such as Pykep to orbiter, but there is nothing concerning the other way. Indeed, it would be nice to be able to propragate the plan according to the real-time datas of the ship. Kind of a mission control telemetry that would allow to recalculate the flight plan with Gmat based on the actual parameters of the flight.


This is definitely a long term project, and i'll have to reopen my physics notes, as to drastically improve my programming skills. I don't know which form this project can take, but i'm really motivated. If you have some tips or ressources that might be useful, I would really appreciate the help.

Have a nice day,
Potjoe

 

[Wolf]

I am sorry I can’t help you but IMO this would be a very nice addon to have in Orbiter :thumbup:

 

[potjoe]

Hi Wolf, thanks for the support :thumbup: Right now i'm struggling with the coordinate systems, and the conversions from one way to another. I'm making some progress here and there, slowly but surely

 

[Ajaja]

Hi Wolf, thanks for the support :thumbup: Right now i'm struggling with the coordinate systems, and the conversions from one way to another. I'm making some progress here and there, slowly but surely

For coordinates : just divide/multiply by 1000 and swap Y and Z
For time epoch: TDBModJulian+29999.5= Orbiter MJD

 

[potjoe]

swap Y and Z

This is exactly what I needed. To be clear, that swap corresponds to the conversion from the left-handed system used in orbiter to the right-handed from GMAT if I'm right.


I'm a bit confused to perform the translation. What are the coordinate systems ?

For instance, if we consider the case of a sattelite orbiting earth, I can capture the value in orbiter and express them within the ecliptic frame, the center of earth being the reference. Can I just make the swap and set Gmat to the EarthMJ2000ec ?

Edit : It appears that your answer raised many more questions :lol:

Edit 2 : Ok, I found part of the solution in one of your previous posts, here

 

[Ajaja]

I'm a bit confused to perform the translation. What are the coordinate systems ?

For instance, if we consider the case of a sattelite orbiting earth, I can capture the value in orbiter and express them within the ecliptic frame, the center of earth being the reference. Can I just make the swap and set Gmat to the EarthMJ2000ec ?

Yes, Orbiter uses the ecliptic coordinate system and VSOP87 uses the J2000 epoch.

 

[potjoe]

I've begun to script in lua in order to make a gmat understandable file, which will allow, for the moment, to export current vessel coordinates at a fixed epoch. I'll add later the other vessels. The oapi.set_pause(false) seems a bit capricious, it does'nt work every time.

---------- Post added at 08:43 PM ---------- Previous post was at 05:03 PM ----------

So here is a really early version of code. For the moment, it generates a .script file readable by GMAT in orbiter directory, where are reported coordinates and velocity vectors, with the reference of the coordinate system being the main gravity source.

However, I'm not sure to tackle the problem the right way. Indeed, it generates a complete script file (and thus erasing every changes made by the user at each run). I've seen that there is a ressource in GMAT's tree under the "interfaces" folder called FileInterface, which is precisely made for this purpose : importe flight datas without overwriting the script file and the mission sequence.

So it might be more useful to generate these kind of Fileinterface, instead of a whole (and necessarily uncomplete) script file. What would be the more useful in your opinion ?

function get_handles()
-- get the handle for the focus spacecraft
	ves = vessel.get_focushandle()
-- get vessel class
	v = vessel.get_interface(ves)
-- get vessel name
	name_ves = oapi.get_objname(ves)
	name_ves_cl = name_ves:gsub('[%p%c%s]', '')
-- get main body gravity source
	hgravity = v:get_gravityref()
	gravity = oapi.get_objname(hgravity)
end

function get_ves_status()
-- get Orbiter MJD
	orbiter_mjd = oapi.get_simmjd()
-- get current coordinates of the Vessel
	q_ves = oapi.get_relativepos(ves,hgravity)
	p_ves = oapi.get_relativevel(ves,hgravity)
end

function conversion_to_gmat()
-- Convert Orbiter Mjd to UTC Modjulian
	UTCModjulian = orbiter_mjd - 29999,5
-- Convert Orbiter left-handed to gmat right-handed coordinate system
	x_ves = q_ves.x / 1000
	y_ves = q_ves.z / 1000
	z_ves = q_ves.y / 1000
	vx_ves = p_ves.x / 1000
	vy_ves = p_ves.z / 1000
	vz_ves = p_ves.y / 1000
end

function export_coordinates()	
-- Define output file
	filename = name_ves .. ".script"
	file = io.open(filename, "w")
	io.output(file)
	
-- 	Output flight parameters	
	io.write("%----------------------------------------", "\n")
	io.write("%---------- Spacecraft", "\n")
	io.write("%----------------------------------------", "\n")
	io.write("\n")
		io.write("Create Spacecraft ", name_ves_cl, ";", "\n");
		io.write("GMAT ", name_ves_cl, ".DateFormat = UTCModJulian;", "\n")
		io.write("GMAT ", name_ves_cl, ".Epoch = '", UTCModjulian, "';", "\n")
		io.write("GMAT ", name_ves_cl, ".CoordinateSystem = ", gravity, "MJ2000Ec;", "\n")
		io.write("GMAT ", name_ves_cl, ".DisplayStateType = Cartesian;", "\n")
		io.write("GMAT ", name_ves_cl, ".X = ", x_ves, ";", "\n")
		io.write("GMAT ", name_ves_cl, ".Y = ", y_ves, ";", "\n")
		io.write("GMAT ", name_ves_cl, ".Z = ", z_ves, ";", "\n")	
		io.write("GMAT ", name_ves_cl, ".VX = ", vx_ves, ";", "\n")
		io.write("GMAT ", name_ves_cl, ".VY = ", vy_ves, ";", "\n")
		io.write("GMAT ", name_ves_cl, ".VZ = ", vz_ves, ";", "\n")
	io.write("\n")
	io.write("\n")

-- Define default force model
	io.write("%----------------------------------------", "\n")
	io.write("%---------- Force Models", "\n")
	io.write("%----------------------------------------", "\n")
	io.write("\n")
		io.write("Create ForceModel DefaultProp_ForceModel;", "\n")
		io.write("GMAT DefaultProp_ForceModel.CentralBody = ", gravity, ";", "\n")
	io.write("\n")
	io.write("\n")

-- define default propagator
	io.write("%----------------------------------------", "\n")
	io.write("%---------- Propagators", "\n")
	io.write("%----------------------------------------", "\n")
	io.write("\n")
		io.write("Create Propagator DefaultProp;", "\n")
		io.write("GMAT DefaultProp.FM = DefaultProp_ForceModel;", "\n")
		io.write("GMAT DefaultProp.Type = RungeKutta89;", "\n")
	io.write("\n")
	io.write("\n")
		
	io.close(file)
end
get_handles()
get_ves_status()
conversion_to_gmat()
export_coordinates()

 

[Ajaja]

Yes, it might be more convenient than to do it manually.
Just one remark. It's better to use TDBModJulian instead of UTCModJulian for the maximum precision.

 

[potjoe]

Yes, it might be more convenient than to do it manually.

I changed the time format.

About the generation of a file interface, I have looked at it but the format used by GMAT (TVHF for TCOPS Vector Hold File) seems not to be documented very well as far as I can tell, and it is unfortunately the only format available. I'll try to have a look a bit further when I have some free time. If it's just a matter of putting values in fields, that's not a big deal. Here is one of the only sample I was able to found :

     TCOPS VECTOR HOLD FILE DUMP PROGRAM VERSION 95.01

     DATE OF DUMP: 12/234/17:42:25.000

     THERE ARE 609 RECORDS IN THE FILE

     THE LAST RECORD WRITTEN IS RECORD 506

     *****  NAMELIST INPUT  *****

      &HFIN                                                                          
       SID=0523401,                                                                  
       ELMSTR=506,                                                                   
       ELMEND=506,                                                                   
       FORM='LONG',                                                                  
      &END                                                                           
1           LONG REPORT OF THE TCOPS VECTOR HOLD FILE                      RUN  1


  SATELLITE ID:    523401                 SIC/VIC:   0234/01
  ELEMENT SET NUMBER:    506
                                          YY MM DD HH MM SS.SSS
  EPOCH TIME FOR ELEMENTS:                12 08 20 00 00 00.000
  START TIME OF FITTED DATA:              12 07 13 16 20 00.000
  END TIME OF FITTED DATA:                12 08 21 15 26 56.000
  RMS OF FIT:                               .128703D+01
  VECTOR TYPE:                            FREE FLIGHT(ON-ORBIT)       
  REFERENCE COORDINATE SYSTEM:            J2000
  CENTRAL BODY:                           SUN    
  SPACECRAFT MASS:                          .60352600000000D+03
  SPACECRAFT CROSS-SECTIONAL AREA:
    DRAG     .79796000000000D-05          SOLRAD(EPSRPA)   .79796000000000D-05
  AREA MODEL USED:                        BOX-AND-WING           
                                          BOX TOP (M**2)      =   .00000000D+00
                                          BOX SIDE (M**2)     =   .00000000D+00
                                          BOX END (M**2)      =   .00000000D+00
                                          PANEL FRONT (M**2)  =   .73469100D+01
                                          PANEL EDGE (M**2)   =   .00000000D+00
                                          PANEL OFFSET (DEG)  =   .00000000D+00
                                          CRIT. ANGLE 1 (DEG) =   .00000000D+00
                                          CRIT. ANGLE 2 (DEG) =   .00000000D+00
                                          FEATHERING          = OFF
  NUMBER OF ORBS TO GENERATE ELEMENT SET:   3095
  CONVERGING/DIVERGING INDICATOR:
    D.C. CONVERGED                                                  
  ORBIT THEORY USED:                      COWELL                 
  ATMOSPHERIC MODEL USED:                 JACCHIA-ROBERTS
  CARTESIAN COORDINATES:
    X       -.88326504300627D+06 KM       XDOT      -.30233214540761D+02 KM/S
    Y        .13271168708568D+09 KM       YDOT      -.56553329621318D-01 KM/S
    Z        .57249579310894D+08 KM       ZDOT      -.64776033315802D-01 KM/S
  KEPLERIAN ELEMENTS:
    SMA      .14388742893922D+09 KM       LAN        .35982261189888D+03 DEG
    ECC      .57349629980871D-02          PA         .30848812805186D+03 DEG
    INC      .23335080349738D+02 DEG      MA         .14161914063426D+03 DEG
  SOLAR RADIATION PRESSURE COEFFICIENTS:    MODELING IS ON         
    CSUBR    .13249742808893D+01
  DRAG COEFFICIENTS:                        MODELING IS ON         
    CSUBDZ   .20000000000000D+01          RHO2       .00000000000000D+00
    RHO1     .00000000000000D+00          RHO3       .00000000000000D+00
  THRUST MODEL COEFFICIENTS:                MODELING IS OFF        
      .000000D+00     .000000D+00     .000000D+00     .000000D+00     .000000D+00
  RIGHT ASCENSION:
      .000000D+00     .000000D+00     .000000D+00     .000000D+00     .000000D+00
  DECLINATION:
      .000000D+00     .000000D+00     .000000D+00     .000000D+00     .000000D+00
  JOB ID:   cramirez                      SYSTEM:   GTDS    
  MACHINE TIME:                           ** 08 21 13 26 22.000
  MACHINE ID:                             cr

One last thing about it : GMAT seems pretty limited regarding the data it can import from a TVHF file. According to the doc, it's limited to the cartesian coordinates, epoch, and the "coefficient of reflectivity". Not sure if the last one is applicable for Orbiter, but I don't thnik so. You may say that's enough for this purpose, and you would probably be right. :thumbup: But it also means that what you gain from a manual input, you loose it by the need to reconfigure the spacecrafts one by one in Gmat. You're the gmat expert, i'm not able to say if it worths it :hello:

 

[Ajaja]

Honestly, I don't think all this spaceship details are relevant in our case because anyway we get the significant mismatch between the Orbiter and GMAT integrations from using VSOP87 in Orbiter.
My usual approach is to use simplified models without the solar pressure radiation, the non-spherical gravitation, etc. We always can/have to use small mid-course corrections to compensate errors.

But if you need the maximum precision you can try my old SPICE module ( https://www.orbiter-forum.com/showthread.php?t=1387 ) , it replaces default Orbiter VSOP87 model and can drastically reduce mismatch between planet positions in GMAT and Orbiter (from kilometers to few meters).

 

[potjoe]

Ok I managed to do something, but it's not perfect and I think I messed up once again with the coordinate system, because i cannot define the reference frame in the TCOPS Vector hold file. If someone wants to test it and give me a feedback, that would be nice, i'm becoming blind in front of my own mistakes.

So here is the lua code :

-- Function to round numbers
function round(num, numDecimalPlaces)
  local mult = 10^(numDecimalPlaces or 0)
  return math.floor(num * mult + 0.5) / mult
end

function get_handles()
-- get the handle for the focus spacecraft
	ves = vessel.get_focushandle()
-- get vessel class
	v = vessel.get_interface(ves)
-- get vessel name
	name_ves = oapi.get_objname(ves)
	name_ves_cl = name_ves:gsub('[%p%c%s]', '')
-- get main body gravity source
	hgravity = v:get_gravityref()
	gravity = oapi.get_objname(hgravity)
	mass = oapi.get_mass(ves)
end

function get_ves_status()
-- get Orbiter MJD
	orbiter_mjd = oapi.get_simmjd()
-- get System MJD
	system_mjd = oapi.get_sysmjd()
-- get current coordinates of the Vessel
	q_ves = oapi.get_relativepos(ves,hgravity)
	p_ves = oapi.get_relativevel(ves,hgravity)
end

-- Function to convert from MJD to Gregorian
function time_conversion(mjd)
	jd = mjd + 2400000.5
	jd0 = jd + 0.5
	z = math.floor(jd0)
	f = jd0 - z
	a = 0.0
	alp = 0.0	
	if z<2299161 then
		a = z
	else
		alp = math.floor((z - 1867216.25) / 36254.25)
		a = z + 1.0 + alp - math.floor(alp / 4.0)
	end	
	b = a + 1524
	c = math.floor((b - 122.1) / 365.25)
	d = math.floor(365.25 * c)
	e = math.floor((b - d) / 30.6001)	
	dayt = b - d - math.floor(30.6001 * e) + f	
	mon = 0	
	if e<13.5 then
		mon = e - 1
	else
		mon = e - 13
	end	
	yr = 0	
	if mon>2.5 then
		yr = c - 4716
	else
		yr = c - 4715
	end	
	mfday = math.floor(dayt)
	hours = math.floor(24.0 * (dayt - mfday))
	minutes = math.floor(1440.0 * (dayt - mfday - (hours / 24)))
	sec = 86400.0 * (dayt - mfday - (hours / 24.0) - (minutes / 1440.0))
	sec = round(sec, 3)
end

function conversion_to_gmat()
-- Conversion from orbiter Mjd to TDBgregorian	
	time_conversion(orbiter_mjd)
	ty = yr
	tmon = mon
	td = mfday
	th = hours
	tmin = minutes
	ts = sec
-- Conversion from System Mjd to TDBgregorian	
	time_conversion(system_mjd)
	sy = yr
	smon = mon
	sd = mfday
	sh = hours
	smin = minutes
	ssec = sec	
-- Convert Orbiter left-handed to gmat right-handed coordinate system
	x_ves = q_ves.x / 1000
	y_ves = q_ves.z / 1000
	z_ves = q_ves.y / 1000
	vx_ves = p_ves.x / 1000
	vy_ves = p_ves.z / 1000
	vz_ves = p_ves.y / 1000
	gravity = string.upper(gravity) 
end

function export_coordinates()	
-- Define template file
	local template = "TVHF.sv"
	local file = assert(io.open(template, "r"))
	
-- Read template file	
	local content = file:read("*all")
	
-- Associate template variables to current value
	-- Epoch
	content = string.gsub(content, "$ty", ty)
	content = string.gsub(content, "$tmon", tmon)
	content = string.gsub(content, "$td", td)
	content = string.gsub(content, "$th", th)
	content = string.gsub(content, "$tmin", tmin)
	content = string.gsub(content, "$ts", ts)
	
	-- Main source of gravity and mass (not sure if the last parameter is taken into account by gmat)
	content = string.gsub(content, "$body", gravity)
	content = string.gsub(content, "$mass", mass)
	
	-- Coordinates and velocity vector
	content = string.gsub(content, "$x", x_ves)
	content = string.gsub(content, "$y", y_ves)
	content = string.gsub(content, "$z", z_ves)
	content = string.gsub(content, "$vx", vx_ves)
	content = string.gsub(content, "$vy", vy_ves)
	content = string.gsub(content, "$vz", vz_ves)
	
	-- Date of capture
	content = string.gsub(content, "$sy", sy)
	content = string.gsub(content, "$smon", smon)
	content = string.gsub(content, "$sd", sd)
	content = string.gsub(content, "$sh", sh)
	content = string.gsub(content, "$smin", smin)
	content = string.gsub(content, "$ssec", ssec)
		
	file:close()

-- Output data to name_of_vessel.sv file
	filename = name_ves .. ".sv"
	local output = io.open(filename, "w")
	output:write(content)
	output:close()

end
get_handles()
get_ves_status()
conversion_to_gmat()
export_coordinates()

And here is the TVHF.sv file template to put in your orbiter root directory.

What it does : it export data from Orbiter to a .sv file readable by GMAT through a fileinterface ressource. It is based on a template file (TVHF.sv) with variable fields that are swapped with actual values during the conversion.

How to use it : launch orbiter and open lua console, run the script, and it will generate a name_of_vessel.sv file in orbiter directory. To import it in gmat, add a fileinterface in the ressource tree, rename it, and select the generated file. Then, in the mission sequence, add in first position a "set" command and define it like this : set name_of_SC_in_GMAT name_of_file_interface_ressource;

You can also add this code to the GMAT script :

Create Spacecraft aSat
Create FileInterface tvhf
tvhf.Filename = 'statevec.txt'
tvhf.Format = 'TVHF_ASCII'
BeginMissionSequence
Set aSat tvhf

and replace the filename by the complete path to the .sv file in orbiter dircetory.

Thank you for reading this long post !

---------- Post added at 09:17 PM ---------- Previous post was at 09:14 PM ----------

Honestly, I don't think all this spaceship details are relevant in our case because anyway we get the significant mismatch between the Orbiter and GMAT integrations from using VSOP87 in Orbiter.
My usual approach is to use simplified models without the solar pressure radiation, the non-spherical gravitation, etc. We always can/have to use small mid-course corrections to compensate errors.

But if you need the maximum precision you can try my old SPICE module ( https://www.orbiter-forum.com/showthread.php?t=1387 ) , it replaces default Orbiter VSOP87 model and can drastically reduce mismatch between planet positions in GMAT and Orbiter (from kilometers to few meters).

I haven't seen your response before posting, i'll have a look ! Anyway, Gmat does not take these details into account, i kept them in the template file just to reproduce the TCOPS vector hold file standard from Nasa's directive, but they are not needed.

 

[Ajaja]

Anyway, Gmat does not take these details into account

It does. If you turn on the solar pressure radiation you need to set the mass of spacecraft, SRP area and coefficient of reflectivity. And it really makes a difference. I tried to integrate in GMAT trajectories of real spacecrafts and without including the solar pressure into calculation I had significant mismatch between the calculated and real trajectories (there are kernels for many missions on the NASA site, and it's easy to load them into GMAT for such comparison).

 

[potjoe]

It does. If you turn on the solar pressure radiation you need to set the mass of spacecraf.

I meant : whatever settings you choose in the TVHF file, the only values imported are coordinates, epoch, and coefficient of reflectivity.

 

[Ajaja]

Really? Sounds like there is a bug in GMAT. It doesn't matter, though. I suspect radiation pressure and atmospheric models in Orbiter and GMAT are very different to include these details into import/export.

 

[potjoe]

Really? Sounds like there is a bug in GMAT. It doesn't matter, though.

At least this is how I interpret Gmat's documentation..

The following file formats are currently supported:
• TVHF_ASCII: ASCII format of the TCOPS Vector Hold File (TVHF), defined by the
NASA Goddard Space Flight Center Flight Dynamics Facility. This file contains spacecraft
state and physical information that can be transferred to a Spacecraft resource.

TVHF_ASCII
Keyword Source field Description
CartesianState "CARTESIAN COORDINATES" Cartesian state elements (X, Y, Z, VX, VY, VZ)

Cr "CSUBR" Coefficient of reflectivity 

Epoch "EPOCH TIME FOR ELEMENTS" Epoch of state vector

Limitations
The following limitations apply to the TVHF_ASCII format:
• Only the J2000 coordinate system is supported.
• Only the first record in a multiple-record file is loaded.

pg. 372-373 of the help-letter.

This is why I first choose to generate a script file instead of a .sv file : because of the fileinterface limitation. :tiphat:

Edit : I just checked for the mass, I confirm that it does not take the value from the TVHF file but from the Spacecraft properties. At least you will have a file that list these details in case you need them. And another problem in perspective : coordinates are imported in the equatorial frame of reference, not the ecliptic. And since we cannot import the reference frame, it is an issue.

---------- Post added 05-01-19 at 09:27 AM ---------- Previous post was 04-30-19 at 10:57 PM ----------

Is there an api command to get the coordinates in the equatorial reference frame ? I could'nt find it. I mean I can code the conversion by hand using matrix and listing obliquity value but that would be much more convenient to get them already converted.

 

[Ajaja]

Is there an api command to get the coordinates in the equatorial reference frame ? I could'nt find it. I mean I can code the conversion by hand using matrix and listing obliquity value but that would be much more convenient to get them already converted.

In Orbiter? There is an example from ScnEditor plugin:

	oapiGetRelativePos (hV, hRef, &pos);
	oapiGetRelativeVel (hV, hRef, &vel);
	// map ecliptic -> equatorial frame
	if (frm) {
		MATRIX3 rot;
		if (frm == 1) oapiGetPlanetObliquityMatrix (hRef, &rot);
		else          oapiGetRotationMatrix (hRef, &rot);
		pos = tmul (rot, pos);
		vel = tmul (rot, vel);
	}

But I have no idea how to do this in LuaScript. Looks like oapiGetPlanetObliquityMatrix is not exported to LuaInterpreter.

 

[potjoe]

Hi! With everything going on the forum, it made me go back to my original idea for this little script, in order to easily export a vessel status to Gmat. I'm not a programmer, so it's definitely dirty code, but I finally ended up with a first result I'm happy to share. I finally changed my mind about the TVHF file which is usually used by GMAT to import realtime telemetry. To my knowledge, it is not possible to write in this file that the coordinates are in the ecliptic frame of reference, and it is not possible to do the conversion from Ecliptic coordinates to Equatorial coordinates in LUA since

oapiGetPlanetObliquityMatrix is not exported to LuaInterpreter.

I'm not familiar with C++, but it's an idea for the future if we want to use this feature. For reference, I kept my old broken script in the archive, along with the TVHF sample.
For now, you can run the script gmat_txt which is working. How does it work ?

• In Orbiter root directory, it creates a vessel_name.txt file
• It exports once in this file realtime parameters of your ship. For now, it only write your positions, velocities, epoch, and central reference body. We can add other parameters in the future, such as ship mass, drag, etc... Considering the variations between GMAT and Orbiter physics engines, it may not be relevant (If GMAT experts can lead me on what I should target first)
• This txt file is a 'Spacecraft' list of parameters that you can copy/paste into a GMAT script, replacing its "Spacecraft" part. Run the script in GMAT : the initial conditions of the spacecraft are the one from Orbiter! You can now plan a mission sequence based on your current situation in the sim.

In the future : I would like to add a GMAT script to generate a report with readable IMFD/TransX dV's, that you can copy/paste back into Orbiter to perform the mission.
Feel free to give any recommandations on the script core functions or code, I'm still learning! I hope someone will find it useful. You must activate the LuaConsole in the Modules Tab, then in the sim, open Functions and Lua Console. The command to execute is run('GMAT/gmat_txt')

Edit : I don't know if this should be moved to Lua scripting ?

 

[Ajaja]

In the future : I would like to add a GMAT script to generate a report with readable IMFD/TransX dV's, that you can copy/paste back into Orbiter to perform the mission.

It will be difficult to use TransX with GMAT. TransX uses conic sections but this approach doesn't work well with GMAT.
Few years ago I added GMAT support to Keithth G's trajectory optimization python script here https://www.orbiter-forum.com/threads/pykep-to-transx-conversion.33685/ and noticed what it's not an easy job to patch together in GMAT more than two such conic sections.

 

[potjoe]

It will be difficult to use TransX with GMAT. TransX uses conic sections but this approach doesn't work well with GMAT.
Few years ago I added GMAT support to Keithth G's trajectory optimization python script here https://www.orbiter-forum.com/threads/pykep-to-transx-conversion.33685/ and noticed what it's not an easy job to patch together in GMAT more than two such conic sections.

Thank you for the reading! At first glance, this is far more advanced than my own understanding of physics and programming. But I'll have a deeper look at your code, and pyKep, it's always instructive. In your opinion, would it be simpler with IMFD ?

 

[Ajaja]

In your opinion, would it be simpler with IMFD ?

Maybe.