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

add option for frame to rotate modes internally if required #226

Merged
merged 17 commits into from
Nov 26, 2024

Conversation

md-arif-shaikh
Copy link
Collaborator

Adds an argument frame which takes either of the two values inertial or coprecessing. If the system is precessing and frame='inertial', the modes are rotated internally to get the dataDict in the coprecessing frame. This completes the extension of gw_eccentricity to precessing system.

@md-arif-shaikh md-arif-shaikh marked this pull request as draft November 10, 2024 10:22
@md-arif-shaikh md-arif-shaikh marked this pull request as ready for review November 12, 2024 08:36
@md-arif-shaikh
Copy link
Collaborator Author

@vijayvarma392 this PR is ready to review now. As described at the top, it adds an option to rotate modes internally.

gw_eccentricity/eccDefinition.py Show resolved Hide resolved
gw_eccentricity/eccDefinition.py Show resolved Hide resolved
gw_eccentricity/eccDefinition.py Outdated Show resolved Hide resolved
@md-arif-shaikh
Copy link
Collaborator Author

@vijayvarma392 let me know if you have any other comments on this.

gw_eccentricity/eccDefinition.py Outdated Show resolved Hide resolved
gw_eccentricity/eccDefinition.py Outdated Show resolved Hide resolved
gw_eccentricity/eccDefinition.py Outdated Show resolved Hide resolved
gw_eccentricity/eccDefinition.py Outdated Show resolved Hide resolved
@md-arif-shaikh
Copy link
Collaborator Author

I have addressed all the comments @vijayvarma392

# frame, rotate the modes and obtain the corresponding modes in the
# coprecessing frame
if self.precessing is True and self.frame == "inertial":
warnings.warn(
Copy link
Owner

@vijayvarma392 vijayvarma392 Nov 26, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

To avoid annoyance, shouldn't you be using debug level? Same comment for all warnings.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

yes, that came to my mind as well. However, the issue was that this was happening while processing the dataDict before setting values to debug_level. The debug_level is available via extra_kwargs which we set only after processing the dataDict.

Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I see, was there a good reason for doing it like that? Would it make sense to flip things around, or even just read or pass extra_kwargs['debug_level'] where needed?

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Will the following work? Inside process_dataDict we check if debug_level is provided by the user via extra_kwargs and use it if its there else use the default value 0 as in the default_extra_kwargs

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The reason was that we needed information, for example, the width for peak finding, from the process_dataDict and then only set the default values.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

But if extra_kwargs is not provided then it's None which will raise an error.

Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

No, I mean, what is the entire debug_level option is made independent of extra_kwargs, like we did for https://github.com/vijayvarma392/gw_eccentricity/blob/main/gw_eccentricity/eccDefinition.py#L144. I don't know if this is the right approach, asking.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, that will solve this issue. Will need to make changes at several places though so that the checks pass. Would it be better to make that change in a separate PR?

Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sounds good. Revert the last commit first?

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Reverted.

@md-arif-shaikh
Copy link
Collaborator Author

Is it git commit --amend and then git push --force?

@vijayvarma392
Copy link
Owner

Is it git commit --amend and then git push --force?

Better is git revert <git hash>

This reverts commit f83d7e7.
@vijayvarma392 vijayvarma392 merged commit dd068f8 into main Nov 26, 2024
3 checks passed
@vijayvarma392 vijayvarma392 deleted the add_frame_option branch November 26, 2024 05:22
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

Successfully merging this pull request may close these issues.

2 participants