Orbit colouring

[maindlt]

Here's the first PR related to orbit coloring :-)

The following has been implemented:

• Config reader reads population data if present in config file. Pops are designed to only work with Python NNLS (validated by config reader).
• hist_width, hist_center, hist_bins are handled by Kinematics / Populations classes anyway, taken out of config reader.
• Skeleton Populations class defined.
• Changes to LegacyOrbitLibrary:
  • If population data is there, it will be copied to the model's infil/ folder.
  • In the orbit integration's input files (orblib.in, orblibbox.in), the pops' apertures are appended to the kins', so the Fortran code will write results in kins and pops apertures.
  • Reading the orblib LOSVDs and 3D orbit density (read_orbit_base) will always read the data for the kins and the pops apertures. For weight solving, the kins /and/or pops data can be selected when calling read_losvd_histograms (new parameter of read_losvd_histograms which defaults to kins only).
• When solving with the NNLS weight solver, the projected masses (from MGE) are read from the kins and/or pops apertures (new parameter of get_observed_mass_constraints which defaults to kins only).

So far tested with two goals (to begin with...):

1. Stay compatible with the master branch when there are no pops: successful. Tested with test_nnls.py and the population data in user_test_config_ml.yaml commented out. The resulting chi2, kinchi2, and kinmapchi2 values are exactly the same as those obtained running the master branch code. So if desired, this branch does not have negative side effects on 'no pops' data and could be merged if desired.
2. Produce no errors and resemble master branch results when there are pops (currently, population data in aperture_for_pops.dat, bins_for_pops.dat, and stellar_pops.ecsv is read, but not used in calculations): while there are no errors and the number of read apertures, etc. look good in the code, the resulting chi2-values differ from the 'no pops in config file' case by up to 0.5% (chi2), 0.5% (kinchi2), 0.2% (kinmapchi2). I think we need to be able to explain this behavior... For easier comparison, all tests are done with CRcut: False.

@prashjet, @boeckera: if you are working next week, would you have time to go over this together, perhaps in a zoom call...?

Cheers, Thomas

[prashjet]

Hey Thomas. Awesome, this looks great.

Happy to have a call but my schedule this week is quite full already, and next week Alina and are will be attending a meeting in Liverpool. Perhaps we schedule a call the week beginning 22nd to go over this... e.g. 12:00 on Monday 22nd? If that doesn't work, I'm quite flexible all week.

[maindlt]

Hi Prash, yes, Monday 22nd at 12:00 will work very well for me. I will be in Vienna that week so we can also meet in person if you are at the institute. Until then I'll be able to also implement the still missing kinematics with_pops option (i.e., part or all of the pop data in extra columns of the kinematics datafile). Have a great week and a successful meeting in Liverpool! Cheers, Thomas