-
Notifications
You must be signed in to change notification settings - Fork 15
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Version 3 - main thread #116
Comments
For shifting alpha by 180 deg, I think we should make this change for V3 because it's wrong and we should fix it. However, is it possible to set up the fix in a similar way to MAG_ZEROPOINT so the user can set it to the V2 convention if desired. |
Why are there two ways to calculate point source, binary lens magnification? We have both WittMao95 and VBBL. In the new architecture, this would be two separation magnification classes. Except the user never accesses these. Anyway, seems very complicated, so there must be a reason... |
Long time ago VBBL had a feature/bug: it checked if source-lens distance is larger than 10 and if so, then point lens approximation was used. I don't know if it's still true. At some point we decided to leave both versions since they were already coded. |
There is a FutureWarning in the function Should this variable be removed at this point? This is the only deprecated missing in |
@jenniferyee You have 2 defintions of |
@rpoleski Is there an example for the exception that is raised from VBBL PSBL calculation (or even a unit test)? Just having the code check for an exception makes debugging hard. I introduced some bugs with my refactor, and they weren't caught because the calculation just switched to WM95. Relatedly, if VBBL returns a magnification vector, why do we have the check magnification < 1? see BinaryLens.point_source_magnification() method. |
@rpoleski
(I also need help fixing the VBBL PSBL error.) |
Note on "use_planet_frame": these should just be implemented as child classes of the standard frame. So there would be BinaryLensPointSourceWM95Magnification() AND BinaryLensPointSourceWM95PlanetFrameMagnification(). These names are getting long, so we might also consider abbreviations, where BLPS_WM95Magnification inherits BinaryLensPointSourceWM95Magnification. |
I've checked that. It turned out that the bug was introduced while merging shear & convergence branch. I've made a quick fix in 3e31b57 . Proper solution requires more work on importing VBBL :( |
First, I think it would be best to fully solve issue with VBBL 4 vs. 7 parameters in master branch, then merge it to Version3_1 branch. Second, maybe this error was the caused somebody (Keto Zhang?) to report that our approach to importing C++ is too slow and we should try to pass vectors once instead of passing floats in a loop. Based on that comment, I've started vbbl_vectors branch, which is still not finished. |
Finished updating documentation. Still need help with fixing binarylens calculations. This is a prerequisite for finishing the binarylenswithshear refactor. Next task: fixing binary source implementation. |
@rpoleski documentation for BinaryLensPointSourceWM95Magnification has missing information. See boldface. |
@jenniferyee Do you mean the reference to WM95 paper? If not, then please be specific. |
Status Update: Implemented a SourceParameters class and the ModelParams unit tests now pass. However, Example 11 and several other binary source unit tests don't work because it checks for a "ModelParameters" object rather than a "SourceParameters" object. In addition, there is a bunch of code in "SourceParameters" that is copy-pasted directly from ModelParameters. This means these two objects are related. The question is whether they are both children of a "MulensParameters" class or whether "ModelParameters" is a child of "SourceParameters." (I don't think SourceParameters is a child of ModelParameters because SourceParameters is more simple.) Regardless, the checks for "ModelParameters" objects need to be updated. Relatedly: there is no real reason to store the source information differently for 1 source rather than multiple sources. |
I was supposed to make notes on classes called factories (wiki link). Here is an example code: model_1 = mm.GetModel({'t_0': 0, 'u_0': 0.5, 't_E': 10})
print(type(model_1))
# returns ModelPointSourcePointLens
model_2 = mm.GetModel({'t_0': 0, 'u_0': 0.5, 't_E': 10, 's': 1.5, 'q': 0.1, 'alpha': 123.})
print(type(model_2))
# returns ModelPointSourceBinaryLens Note - a single class GetModel produced objects of different types based on the input it got. |
Current thoughts on refactoring ModelParameters to support multiple sources: https://docs.astropy.org/en/stable/_modules/astropy/modeling/core.html#CompoundModel For more on simplifying architectures using inheritance, see also: |
Spent some time thinking about class diagrams, inheritance, and the order of adding effects. Although we might think finite source effects, extra lenses, parallax, etc. can be added in any order, the code needs a specific structure for adding these components. I propose:
Hence, a Binary Lens model with Binary Sources (both exhibiting finite source effects) including parallax would be built as follows: Basic Model (t0, u0, tE)
A PointSource model with a Binary Lens exhibiting full keplerian orbital motion and parallax would be: Basic Model (t0, u0, tE)
A triple source, point lens model, with finite source effects only for the third source:
|
I'm still not getting why you want to change ModelParameters. For me the current master branch is quite good. Ok, one obvious change is to keep multiple sources as a list, not hard-coded Minor comment:
I will keep our old decision to call these parameters (t_0_1, u_0_1, t_E) if there is more than one source. The idea was that parameters ending in |
Multisource problems all resolved. The thoughts listed above were too complicated. |
merged master into Version 3_1, but there are a lot of problems with incorporating xallarap. The next task will be to resolve the unit test failures. commit 721c4fc |
Merge complete: 28284c7 All the unit tests that fail also failed pre-merge. |
After discussion on May 20, 2024:
|
@jenniferyee, Where do you save plots from examples? |
Unit Tests needed in test_FitData.py
I found that satellite_skycoord was not being correctly masked when creating MagnificationCurve objects in FitData. _set_data_magnification_curves(). I fixed this, but it should have a unit test. Likewise, I noticed that behavior for n_sources == 1 and 2 was explicitly defined, which probably means FitData still needs to be updated to handle arbitrary numbers of sources. Therefore, we should write a unit test for this first. |
@jenniferyee - please make the tests faster. I've found that 3 tests take half of the total tests time:
I've checked that the first one tests small number of values, but a large number is calculated earlier. Whole trajectories (defined in |
@jenniferyee File
What is supposed to be wrong? Did you mean (20 lines later): self._position_z1 = -self.separation + 0.j
self._position_z2 = 0. + 0.j ? |
@jenniferyee , in |
Fixed in commit e336a45 |
I added this comment in commit daf1afe Prior to this commit, the statement "Calculate point source magnification for given position. The was part of the documentation for Anyway, the main action item is that the documentation for |
Do we need EDIT: done in 8ee4d2e |
yes. This is wrong. But there is a b0 factor in Next Steps:
|
I've added the class for 2L1S magnification that calls VBBL first and switches to WM95 if the former fails: commit 267cc0f1. @jenniferyee you may want to review it. |
Other n_source tests that are needed:
Generally:
|
Looks fine to me. |
I'm guessing more than 2 source and xallarap fails currently, so I suggest to forbid that. |
@rpoleski for multi-source models, having a single line of parameters in repr is very long + we have the keys ordered by type, but I would prefer them to be ordered by source. see example_25_multiple_sources/ex_25_1L4S_model.py Should we change repr for multi-source models to
|
Note to self: Apparently, N sources was not implemented in model.py. Next step: write a unit test (or several UTs), e.g., calculate the flux from a model as would be needed for FitData. Then: implement N sources in model.py and retry ex_25_1L4S_model.py |
I'm behind with @jenniferyee posts for 2 weeks, so let's try to get me on track:
Note that we already have 2L2S model in example 19.
|
|
as of ac630e4, multiple sources is nearly fully implemented. Remaining action item: separate gammas for the different sources, e.g., self._check_gamma_for_2_sources(gamma) and unit tests. |
@rpoleski Is the inverse also true? As in, if |
@rpoleski The problem with the |
I think it should be that way.
|
EDIT - currently remaining: only 8. |
Relatively small tasks:
|
@jenniferyee Function |
I reviewed this thread and made a list of necessary changes before merge:
And changes that are not required:
Some final tasks before merging:
|
What is decided to be done for Version 3:
Added later (only high-level ones):
Also check MM_v3.md file for less changes that were not accepted yet.
Not decided yet and important:
The text was updated successfully, but these errors were encountered: