Modelling brightness of variable stars

[henrysky]

I have started initial works on modelling brightness of variable stars.

Currently the brightness are simply sinusoidal regardless the type of variables, with brightness min, max, period and epoch at max brightness from the current GVCS data file.

To-do list:

• [ ] template light curve for different types of variables
• [ ] what to do about variables with irregular variable stars?
• [ ] settings for exaggerate brightness dip for transiting exoplanet?

Screenshots (if appropriate):

https://github.com/user-attachments/assets/cbe6d9a3-317a-4f06-8098-7613bd5bc7fc

Type of change

• [ ] Bug fix (non-breaking change which fixes an issue)
• [x] New feature (non-breaking change which adds functionality)
• [ ] Breaking change (fix or feature that would cause existing functionality to change)
• [ ] This change requires a documentation update
• [ ] Housekeeping

How Has This Been Tested?

Test Configuration:

• Operating system: MacOS 15
• Graphics Card: Apple M3

Checklist:

• [ ] My code follows the code style of this project.
• [ ] I have performed a self-review of my own code
• [ ] I have commented my code, particularly in hard-to-understand areas
• [ ] I have made corresponding changes to the documentation (header file)
• [ ] I have updated the respective chapter in the Stellarium User Guide
• [ ] My changes generate no new warnings
• [ ] I have added tests that prove my fix is effective or that my feature works
• [ ] New and existing unit tests pass locally with my changes
• [ ] Any dependent changes have been merged and published in downstream modules

[github-actions[bot]]

Great PR! Please pay attention to the following items before merging:

Files matching src/**/*.cpp:

• [ ] Are possibly unused includes removed?

This is an automatically generated QA checklist based on modified files.

[alex-w]

Great start!

what to do about variables with irregular variable stars?

For some irregular stars we can obtain the light curves from various sources (hello NASA ADS, arXiv, and printing books) and show this historical data - it have reasons for didactic and historical purposes. Of course, we can simulate some irregular process (sine wave + some random shift for each time moment) and get a syntetic light curve (it will not related to reality) - it can be acceptable for didactic purposes. And the last point - just a show info and not touch a brightness of these stars (like at the moment).

settings for exaggerate brightness dip for transiting exoplanet?

Do you planned to use data from Exoplanets plugin?

[gzotti]

Great next step!

Yes, we need definitely a few types of light curves. Occultation with 1 or 2 dips, $\delta$ Cephei type, Miras, ...

About periods and variations: I am afraid this needs some extras files to adjust. You could use some interval, so from 1800...1870, use $t_{max}=...$ and period $p$, for 1870...1964 use next set of values etc. (Or use JD based notation, whatever is available.) The oldest given data may well be extrapolated to the past then, lacking other data, and the latest data extrapolated into the future. (Maybe the infostring should then say "var mag extrapolated before 1800" or similar.) Semi-regulars like Mira type will certainly need that, but maybe we should tolerate slight errors for time (20 or 50 days?) and mag (0.5mag?) so we don't need adjustments every year. We have an own adjustment dialog for the Great Red Spot, but I am not sure users will need something similar to adjust ~250 stars (or more?) themselves.

If performance should suffer with all these extras and too many var stars now, probably this feature can be sensibly limited to 0.1mag light changes.

I am less sure about brightness changes of exoplanet transits. We cannot really display millimag changes. Maybe here the exoplanet dialog should be enhanced to show the light curve for a selected object in a QChart, and just mark the current phase with a line.

[alex-w]

@gzotti for many periodic variables we have already catalog with data for simple light curves ;)

[github-actions[bot]]

This pull request has conflicts, please resolve those before we can evaluate the pull request.

[github-actions[bot]]

Conflicts have been resolved. A maintainer will review the pull request shortly.