ericstoneking / 42

Simulation for spacecraft attitude control system analysis and design
252 stars 83 forks source link

Add support of YAML configs #56

Closed vladtcvs closed 2 years ago

vladtcvs commented 3 years ago

Reasons why I think YAML configs are good:

1) Plain text configs sometimes hard to read because different options are mixed together. For example

KEP                           !  Use Keplerian elements (KEP) or (RV) or FILE
PA                            !  Use Peri/Apoapsis (PA) or min alt/ecc (AE)
100.0     100.0               !  Periapsis & Apoapsis Altitude, km
400.0  2.0                    !  Min Altitude (km), Eccentricity
52.0                          !  Inclination (deg)
180.0                         !  Right Ascension of Ascending Node (deg)
0.0                           !  Argument of Periapsis (deg)
0.0                           !  True Anomaly (deg)
0.0  0.0  0.0                 !  RV Initial Position (km)
0.0  0.0  0.0                 !  RV Initial Velocity (km/sec)

Keplerian PA, Keplerian AE, RV, and file, all they don't separated. And you can not add line for separate them because of very strict file format

2) You can not comment-out lines. While in YAML you can do something like

        Position_Velocity_Orbit_Parameters:
#            Position:   [6000, 0, 0]    # km
            Position:   [7000, 0, 0]    # km
            Velocity:   [8, 0, 0]       # km/s

And it's easy to switch between 6000 and 7000 variants.

Now i'm gradually adding such support

ericstoneking commented 3 years ago

I can't promise I'll adopt what you come up with, but I'll be interested in seeing it. To fit in with 42's style, a scheme for reading input files should: 1) Minimize (ideally avoid) external dependencies. A "yamlkit.c" would be best. Linking to external libraries is sub-optimal. 2) Provide a template in the input file itself. I'll be interested to see how you sort out the Keplerian/RV/file options. 3) Fail in an obvious way if some inputs are not provided. Obnoxiousness is a feature. Chasing what appears to be a dynamics bug when it's actually a bad input is painful enough as it is. I fear that having a robust, typo-tolerant input scheme would only make that worse.

Regards, -Eric (he/him)

vladtcvs commented 3 years ago

Example for orbit: https://github.com/vladtcvs/42/blob/master/InOut/Orb_Ellipse.yaml

Example for SC: https://github.com/vladtcvs/42/blob/master/InOut/SC_Simple.yaml

Example simulation description: https://github.com/vladtcvs/42/blob/master/InOut/Inp_Sim.yaml

vladtcvs commented 3 years ago

I've used https://github.com/pantoniou/libfyaml for yaml because it provides much more useful interface than libyaml. I never heard about "yamlkit.c", and the only lib with name yamlkit is https://github.com/patrickt/yamlkit, but it's objective-c. Can you please give link to yamlkit.c?

ericstoneking commented 3 years ago

Sorry, "yamlkit.c" is shorthand for: Code up whatever yaml support you need in C, and put it in Kit/Source along with all the other *kit.c files, so we can build it along with the rest of 42, thus avoiding adding an external dependency.

ericstoneking commented 3 years ago

Looking at your examples, I think readability is in the eye of the beholder. I might suggest something that I've seen others do: make a front end that takes your yaml input files, and translates them into the format that 42 expects.