Skip to content
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

Should z_s become a param? #303

Open
ConnorStoneAstro opened this issue Dec 20, 2024 · 1 comment · May be fixed by #305
Open

Should z_s become a param? #303

ConnorStoneAstro opened this issue Dec 20, 2024 · 1 comment · May be fixed by #305
Labels
fix A bug fix patch for the codebase refactor A code change that neither fixes a bug nor adds a feature

Comments

@ConnorStoneAstro
Copy link
Member

Now that its possible to link params, we could have it so that z_s for each lens is a param like z_l. Then for a class like SinglePlane we could enforce lens.z_s = self.z_s for all the lenses so that they have the same source redshift (same for z_l really).

@ConnorStoneAstro ConnorStoneAstro added refactor A code change that neither fixes a bug nor adds a feature fix A bug fix patch for the codebase labels Dec 20, 2024
@ConnorStoneAstro
Copy link
Member Author

It would also mean that z_s could become more out of the way for most lenses since it could be set at initialization and then ignored afterwards. Right now a bunch of functions need z_s as input even though they don't really need it.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
fix A bug fix patch for the codebase refactor A code change that neither fixes a bug nor adds a feature
Projects
None yet
Development

Successfully merging a pull request may close this issue.

1 participant