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

Frequency scale in parameters should be set by the model #13

Open
MathieuRoule opened this issue Jun 15, 2024 · 1 comment
Open

Frequency scale in parameters should be set by the model #13

MathieuRoule opened this issue Jun 15, 2024 · 1 comment

Comments

@MathieuRoule
Copy link
Member

MathieuRoule commented Jun 15, 2024

Currently the default frequency scale inside the parameter structure is not necessarily the same as frequency_scale(model).
I think this is super dangerous and had a hard time debugging my secular code response because of it.
Typically broken when frequency_scale(model) is not 1.0 and the user don't manually fill in the parameters when creating the structure.

function LinearParameters(basis::AstroBasis.AbstractAstroBasis;
Orbitalparams::OrbitalElements.OrbitalParameters=OrbitalElements.OrbitalParameters(),Ω₀::Float64=1.0,

@michael-petersen
Copy link
Member

This is a great point. Only affects v0.11.0 and up, for now. The main issue is that the model is not exposed to the parameter structure, so this isn't a trivial fix.

I've checked in a draft change with d70b7a9. This has some good properties, and some bad, primarily arising from how we allow the user to input Ω₀. I propose that we now check the provided frequency scale against the model frequency, and override to the model scale. This is kind of convoluted, since we could just set Ω₀ ourselves in this case (and maybe the user really does have some reason they want a different frequency scale, for some dynamic range tests?). Unfortunately, this would require setting the parameter structure LinearParameters as mutable, which might result in a performance hit. It didn't cost anything in the standard test package, but that may not be conclusive. On the other hand, if we don't make LinearParameters mutable, the check will now just crash the program if the input Ω₀ and the model Ω₀ don't match (which we could then throw a verbose error explaining how to fix).

Another option would be to make Ω₀ a required argument to LinearParameters; for example, in the test code, I call LinearParameters as

Parameters = LinearResponse.LinearParameters(basis,Orbitalparams=OEparams,Ω₀=OrbitalElements.frequency_scale(model))

which circumvents the issue.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants