A strange bug or a user made of human - forgotten enable/disable

[abokon]

Hi everybody,
I am András, from the workshops in Ljubljana, and working on multiple projects regarding interesting binary systems. I have a many tales to tell, but I wish to write about a recent one which I thought of initially as a bug.

So, I am on the mcmc stage on my one of the projects, and so far I was sampling the rv-s last month. Therefore I disabled the lightcurve as the textbook says. There was a month blackout on my part (correcting a paper according to the referee's comments, checking another phoebe2 project of a MSc student, etc), and I continued my project in question today. To check the fit of model to the lightcurve, I gave the following command as a first step

b.run_compute('nm_fit', dataset = 'lc_i03', model = 'latest')

and checking it with b.plot(...), I encountered with ridiculously large fluxes (~10^26 W/m^2 instead of normalized ones).

Luckily, I found the answer after some rest. I forgot to enable the lightcurve (lc_i03) in the computer options. So

b['enabled@lc_i03@nm_fit'] = True
b.run_compute('nm_fit', dataset = 'lc_i03', model = 'latest_v2')

resulted the correct fluxes, plots etc. I had the phoebe logger on WARNING, and it didn't warn that I would like to compute something which is not supposed to due to the disable.

So I made a test for phoebe2 and maybe it failed. Should it be working this way, and the user have the responsibility to realize this, or not?
Maybe important for reproducing: passband luminousity mode of lightcurve is on 'component-coupled' and the pblum of the primary component was fitted on the optimization stage of the project.

I imagine that you have such kind of encounters. The strange fact for me is the run_compute is working easily despite the disable of the dataset in question, but gives erroneous fluxes. I tried to search here about this but didn't find the proper keyword to find. If somebody asked this before, I am sorry for not finding it. 😆

PS: the master student found one or two strange behavior of phoebe (or even emcee but this was just for me...), and I found the cause of it after one-two days. I couldn't write or ask about it due to the closing deadline...

[kecnry]

Hi Andras!

Was the only difference between the two models whether the dataset was enabled vs passed to run_compute, or did you re-optimize for something in between (passband luminosities, for example)? And also - is nm_fit the name of the compute options? If nothing else was changed between, can you perhaps send a bundle with all the solvers/solutions/data removed that reproduces the problem (feel free to email if you'd rather even after removing all of those). I'd like to try to reproduce and see if that is expected or not.

PS: the master student found one or two strange behavior of phoebe (or even emcee but this was just for me...), and I found the cause of it after one-two days. I couldn't write or ask about it due to the closing deadline...

If you do hear anything - please encourage posting here or as an issue if its a bug.

[abokon]

Hi Kyle,

yes, that was the only one difference between the two models. The 'nm_fit' is the name of the compute. (Sry, if the names are confusing.)
I think I will contact you via e-mail, but I successfully reproduced this even with the default binary. So with

b = phoebe.default_binary()
b.add_dataset('lc', dataset = 'lc01')
b.flip_constraint('compute_phases', solve_for = 'compute_times')
b['compute_phases'] = phoebe.linspace(0,1,1001)
b.run_compute('phoebe01', model = 'test_enabled', overwrite = True)
b['enabled@lc01'] = False
b.run_compute('phoebe01', dataset = 'lc01', model = 'test_disabled', overwrite = True)
b.plot(x = 'phase', show = True)

you will see the exact issue.

However, I will send you the bundle with a note, because I found a similar bug I encountered during the work with the master student. (She didn't realize it at that time, just me after I wanted to check something.)

So, she did some mcmc with export_solver(), and checking the progress with import_solution(), as I am. But she accidentally sent me an older version of bundle, which didn't have the solver which was running. There was no issue during the import of the solution. And I could see the chains and everything in it I wanted.
That time I didn't know that I was working with an older version of bundle. When I checked the list of solvers with b.solvers, I saw the name of the solver in qeustion, and I thought, I will setup a longer chain, just to be sure (double check is needed sometimes). Ooops... an error message with "0 twigs with ..." or something like that. I didn't want to believe, and I realized the missing solver and its cause after some time. 😞
Again, which was strange to me, that the solver in question appeared in the list of b.solvers, but it didn't actually exist.

And now, during the preparation of the bundle, I removed the datasets, models, solutions and solvers, as you suggested. To be sure, I wanted to model again with this reduced bundle, and the 'lc01' still existed in the list of b.datasets. I wanted to check it, but didn't exist of course. I had a bad feeling and I realized that there was a distribution with parameters of ld coeffs of this very dataset. After removing the distributions, the dataset didn't appear anymore.
So I have a hunch that maybe we can see the none-existing solver/dataset in its proper list (b.solvers, b.datasets), if an associated solution or distribution with related parameter-set exist(s)...

---

Kyle, I will sent the e-mail to you in 1 hour to your address.

[kecnry]

The flux level does seem like a bug to me, I'll need to track down the actual cause and then open an issue (I did get your email, thanks!). It sounds like you can workaround it though, so it probably won't be top priority to get fixed, but we'll get to it eventually!

The second issue (b.datasets), I think is just a misunderstanding of what that does/means. b.datasets will just give you a list of all dataset tags across all parameters, so is expected to return 'lc01' if the dataset has been removed but there is still a model or distribution with that tag. If you want the names of all the actual existing datasets, you could do b.filter(context='dataset').datasets. This confusion really only should be able to happen if something was removed or renamed at some point - if there is a case where it happens without that, let me know and there might be something else going on.

[abokon]

Thank you your reply, and yes, we can avoid the original problem this way. Probably the phoebe-users will, because it is rare to execute run_compute in this brute-force method (I mean for disabled dataset forcibly). Or not knowingly by a forgetful user. :) Maybe it could be helpful to make a WARNING message for this case, when you debug the actual problem in question - e.g. "Dataset [lc01] is not enabled in compute [phoebe01], computing it anyway." or something like that. That's only an idea.

Your clarification about b.datasets et al was a new info for me. I just love using them in the beginning of every notebook where I prepare for a new run for optimization or sample, and so far I believed that it is a shortcut for checking the name of every dataset, solver etc. It is a habit for me since the first workshop where I attended in 2023. I can't recall whether you mentioned this and I didn't pay attention this time... Anyway, I will update my written notes and warn all the colleagues whom I told this (mis)interpretation. I guess, we all learn something new everyday. :)

Thank your for your time and help. 😃

[kecnry]

I was able to reproduce and modified simple example for the original fluxes issue - see #987.