pgbinary

[matthiasfabry]

Hello MESA devs,

Working with binaries a lot, I think it would be useful to make a binary equivalent of pgstar, which I obviously dub pgbinary.

Main reasons are:

• When binary starts, pgstar spawns windows on top of one another (is this machine dependent? Can we control this?), so I have to move them around all the time.
• I typically use one pgstar_inlist to plot identical info of both stars (if present of course). Therefore, binary data like period get plotted twice, once as part of star one's plot, another time as part of star two's plot, which takes up that all so valuable screen space.

This leads to the conclusion that I'd rather have one window spawn: pgbinary, which would function much like a pgstar_grid does now: make room for some binary_history plots, and also for the two stars (which remains to be controlled by pgstar)

Additionally, with pgbinary, you could more easily make plots dedicated to binary info like one of the orbit (imagine seeing the ellipse circularize during mass transfer! Or maybe even visualize the size of the star with respect to its Roche Lobe). I understand you could do all of this in post-processing, but the simple rebuttal is that pgstar exists.

I've managed to get the basic infrastructure of pgbinary down which deals with gathering history data and their plotting, but the real feature of pgbinary, embedding pgstar plots, I think cannot be done without a major rework of pgstar. So currently, I could run binary spawning 3 plots, one for the binary history, and one each for the stars (without necessarily needing to plot binary history there) see attached screen shot.

What are your opinions on this work/feature? Has this been discussed before? I can imagine this is pretty low priority for the core devs, but then again, the more we flesh out mesa/binary, the more use it will see in the community.

I look forward to hearing back from you,
Matthias

[rjfarmer]

Hi Matthias,

It's a good idea and we haven't discussed this before.

When binary starts, pgstar spawns windows on top of one another (is this machine dependent? Can we control this?),

I don't believe we can control this.

I've managed to get the basic infrastructure of pgbinary down which deals with gathering history data and their plotting,

That very impressive. The pgstar code is abit messy....

I think cannot be done without a major rework of pgstar

Where are your concerns here? I've only been thinking about this a for a few minutes but it doesn't seem like we need to do a major rework. I'm thinking pgbinary could mostly work like the grid plots do. Which is you just need the plot's name set in a pgstar_binary inlist (with an option for saying which star to show), then we just read the star's pgstar inlist to get the "fine details" of the plotting options. Then we just need to add something for binary specific plot, but that would just look like the "normal" pgstar code just copied into binary/.

The only difficulty there is getting a public interface exposed to call the pgstar plots from binary/, buts that is just tedious rather than difficult.

[matthiasfabry]

Yes, that's precisely it. I tried first playing around abit with function that are public, namely update_pgstar_plots from star_lib, but of course there pgstar has no idea of the viewport I want to plot in.

The only difficulty there is getting a public interface exposed to call the pgstar plots from binary/, buts that is just tedious rather than difficult.

it is then as simple as exposing all the do_plot_something(id, device_id, viewport_options, etc...) from all the possible pgstar sources? only then the module pgstar should be made visible in binary. I don't believe it is currently.

hen we just need to add something for binary specific plot, but that would just look like the "normal" pgstar code just copied into binary/

That's indeed what I did. along with the necessary modifications to how history is handled.