errror when adding in stellar properties

[toribonidie]

Hi!

I am trying to use SHERLOCK to search for planetary transits around red clump stars. I am receiving an error message when I try to input stellar properties to my .yaml file. I am attaching both the .yaml file and the output file with the error message. It seems that it is creating a very short period grid (19.503 - 32.968 days) to search in, and I am unsure why. Please let me know if you can look into this issue, as I've been unable to fix it on my own so far and would really love to keep using your PlanetHunters suite for my research.

Thank you so much!

test.yaml.txt

sherlock_test.out.txt

[martindevora]

Hello, this is mostly not a bug from SHERLOCK but related to the way Transit Least Squares (which SHERLOCK uses under the hood) computes the period grid. If you take a look into Hippke & Heller, 2019 (https://ui.adsabs.harvard.edu/abs/2019A%26A...623A..39H/abstract) you will see equations 6 and 7. After these, they mention:

 The minimum and maximum trial orbital frequencies can be found at fmin = 2/S (or
fmin = 3/S if three transits are required) and at the most shortperiod (high-frequency) circumstellar orbit, the Roche limit,
fmax =pGMs/(3Rs)3/(2π). Strictly speaking, the Roche limit depends on the density (ρp) of the planet, and the term 3 Rs for our expression of fmax assumes the most pessimistic case of an extremely low-density fluid-like planet with ρp = 1 g cm−3, which can be compared to Jupiter’s mean density of 1.33 g cm−3

Hence, I'd assume that 19.5 days is the first period after the Roche Limit of the given star. Have you already considered that possibility?

Kind regards, Martín.

[toribonidie]

Hi Martín!

Thank you so much for the quick response! It does seem that the issue with the period grid is stemming from the TLS algorithm, but I am not sure if that is what is causing the error message. The error I am getting says:

`Traceback (most recent call last): File "/home/veb19/miniconda3/envs/sherlock/lib/python3.8/site-packages/sherlockpipe/search/sherlock.py", line 260, in __run_object for index in np.arange(len(signal_selection.transit_result.t0s)): TypeError: len() of unsized object

During handling of the above exception, another exception occurred:

Traceback (most recent call last): File "/home/veb19/miniconda3/envs/sherlock/lib/python3.8/runpy.py", line 194, in _run_module_as_main return _run_code(code, main_globals, None, File "/home/veb19/miniconda3/envs/sherlock/lib/python3.8/runpy.py", line 87, in _run_code exec(code, run_globals) File "/home/veb19/miniconda3/envs/sherlock/lib/python3.8/site-packages/sherlockpipe/main.py", line 12, in run_search(args.properties, args.explore, args.results_dir) File "/home/veb19/miniconda3/envs/sherlock/lib/python3.8/site-packages/sherlockpipe/search/run.py", line 326, in run_search sherlock.Sherlock(sherlock_targets, explore, cache_dir=cache_dir, results_dir=results_dir).run() File "/home/veb19/miniconda3/envs/sherlock/lib/python3.8/site-packages/sherlockpipe/search/sherlock.py", line 205, in run self.run_object(sherlock_target) File "/home/veb19/miniconda3/envs/sherlock/lib/python3.8/site-packages/sherlockpipe/search/sherlock.py", line 340, in run_object logging.exception(str(e)) File "/home/veb19/miniconda3/envs/sherlock/lib/python3.8/logging/init.py", line 2057, in exception error(msg, *args, exc_info=exc_info, *kwargs) File "/home/veb19/miniconda3/envs/sherlock/lib/python3.8/logging/init.py", line 2049, in error root.error(msg, args, kwargs) File "/home/veb19/miniconda3/envs/sherlock/lib/python3.8/logging/init.py", line 1475, in error self._log(ERROR, msg, args, kwargs) TypeError: _log() got an unexpected keyword argument 'exc_info'`

I will keep looking into this! Thank you for your help.

[martindevora]

Ah sorry, I didn't take a look on that. That is a bug and it means that SHERLOCK did not find any signal in the entire run and it will be stopping after it. I will correct it, but your execution would have ended anyway.

Kind regards.

[martindevora]

The bug has already been fixed and will be published with the next version.

[toribonidie]

Hi Martin!

I am so sorry to keep bugging you, I have one (hopefully last) question.

When I manually input my minimum and maximum periods in the .yaml file, sherlock reads it in, but then they get overriden by the values computed by TLS. I am attaching the output file that shows this.

I think that the minimum period TLS is calculating is the first possible period after the Roche Limit of the given star, given by the equation fmax =pGMs/(3Rs)3/(2π), as you previously pointed out. But I think they are hard coding in the density values to achieve this equation. Because I am working with Red Clump stars, which are much less dense, I am getting really inaccurate values for the minimum period possible.

If you know how to prevent TLS from overriding the period grid I manually input, please let me know! If not, I can just raise an issue on the TLS github page instead!

Thanks so much, Tori sherlock_test.txt

[martindevora]

Hello Tori,

I think that the density used in the TLS equation is the orbiting object density, where TLS assumes 1 g / cm³ for a really low-dense object. This is what it does:

f_max = 1.0 / (2 * pi) * sqrt(tls_constants.G * M_star / (3 * R_star) ** 3)

Please mind that the equation from the paper contains a squared root that copy-pasting from my side omitted. This is the equation:

To me it seems that the density of the star would already being taken into account as the star mass and radius are part of the equation.

However, if you say that your calculations lead to a very different roche limit, I'd be open to modify the TLS computation in SHERLOCK to let the user enforce the minimum period if you elaborate a little bit further.

Kind regards, Martín.

[toribonidie]

Hi Martin,

Thanks for your quick response! In their paper, they say that the most short- period (high-frequency) circumstellar orbit is given by

f_{max} = \frac{\sqrt{GM_{s}/(3R_{s}})^{3}}{2\pi}

where the $3R{s}$ term is calculated from the Roche limit, assuming a pessimistic density of $\rho{p} = 1 g/cm^{3}$. They did not show a derivation for this formula in their paper, but I think they are starting with Kepler's 3rd law

f_{max} = 1/P =  \frac{\sqrt{GM_{s}/(a})^{3}}{2\pi}

And they are using the roche limit to calculate the semi major axis. For a rigid transiting body, the roche limit is given by,

a = R_{s} (2 \frac{\rho_{s}}{\rho_{p}})^{1/3}.

Or, for a fluid transiting body, the roche limit is given by,

a \approx 2.44R_{s} (\frac{\rho_{s}}{\rho_{p}})^{1/3}.

They are assuming $\rho{p} = 1 g/cm^{3}$, but I do not see them making any assumption about $\rho{s}$. Now, if use this assumption of planet density and I plug in my value for a typical density of a RC star (0.002 $g/cm^{3}$), I get

a^{3} = 0.004 R_{s}^{3} 

for a rigid body and

a^{3} = 0.03 R_{s}^{3} 

These are both extremely different from the value they are getting for their $a^3$ term, which is $(3R{s})^3$. My best guess is that maybe they are inputing a typical density for a solar mass star (~1.4 $g/cm^{3}$ for the sun), because that would produce an $a^{3}$ term that is roughly $(3R{s})^3$.

I don't see anything in the paper that makes this assumption, so I could be misinterpreting the way they are deriving their equation for $f_{max}$. This formula is restricting the period range that Sherlock searches, but I believe shorter periods are physically possible.

Please let me know if this makes sense. Thank you so much!

[martindevora]

Hello, Your guess sounds very reasonable. I will implement this change so the mínimos frecuency could be enforced by the user. Keep posted!

[toribonidie]

Perfect! Thank you so much.

[martindevora]

Hello @toribonidie . You should now be able to run it with your parameters and they will be respected with the 0.36.1 version (now it requires Python 3.9 or higher):

2023-04-19 21:35:21 INFO     SEARCH RUNS with period grid: [0.50 - 32.97] and length 5437

However, as you can see, the period grid is very thin. This is due to the way TLS computes the optimal frequency sampling. In order to avoid hacking it and breaking other things, I'd suggest you to use a higer oversampling up to 5 or even more. The optimal scenario would be to run some injection and recovery tests with different oversampling values and decide the best one for this type of stars, if there are any differences. For that you could use MATRIX.

Please close the issue in case you find it resolved.

Kind regards.

[toribonidie]

Great, thank you so much!