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

BUG: Converting from time domain to frequency domain and then back to time domain does return the original time domain variable. #321

Closed
degoeden opened this issue Mar 25, 2024 · 4 comments
Assignees
Labels
bug Something isn't working

Comments

@degoeden
Copy link

Bug Description
I'm getting a bug when I try to convert from time domain, to frequency domain, and then back into time domain. The weird thing I'm doing here is that my non-linear kinematics function is dependent on velocity rather than position, so I had the change the PTO class around a little.

Steps to Reproduce
To reproduce the error, please see the gist I created. It mostly follows the first part of the WaveBot tutorial with a few modifications, the most important being the change of what the kinematics function is a function of.

** Expected Behavior**
I expect converting a time domain variable from frequency domain and back into time domain would return the original value. I get this expected behavior when I use the original PTO class, or when I don't use a nonlinear kinematics function.

Experienced Behavior
Unfortunately when I use my new PTO class with the nonlinear kinematics function that essentially takes the absolute value of velocity I do not see that behavior and instead see very different numbers for the original time domain variable and the converted to frequency domain and then back to time domain result.

System Info

  • OS: Windows 11 Home, Version 23H2
  • Python version: 3.10.13
  • WecOptTool version: 2.6.0
  • Capytaine version: 2.0
@ryancoe ryancoe added the bug Something isn't working label Mar 25, 2024
@dtgaebe
Copy link
Collaborator

dtgaebe commented Apr 2, 2024

Hi @degoeden ,

I tried to replicate your error, but when I'm running your code I seem to get the expected behavior, with a new environment with WecOptTool 2.6.

You see different numeric values at every output?

Here is a snippet of my output:

td... [62.52013256]
td->fd->td... [62.52013256]
td... [62.52013256]
td->fd->td... [62.52013256]
td... [62.52013256]
td->fd->td... [62.52013256]
td... Autograd ArrayBox with value [62.52013256]
td->fd->td... Autograd ArrayBox with value [62.52013256]
td... [62.52013256]
td->fd->td... [62.52013256]
td... [62.52013256]
td->fd->td... [62.52013256]
td... Autograd ArrayBox with value [62.52013256]
td->fd->td... Autograd ArrayBox with value [62.52013256]
td... Autograd ArrayBox with value [62.52013256]
td->fd->td... Autograd ArrayBox with value [62.52013256]
td... [30.95517666]
td->fd->td... [30.95517666]
td... [30.95517666]
td->fd->td... [30.95517666]
td... [30.95517666]
td->fd->td... [30.95517666]
td... [30.95517666]
td->fd->td... [30.95517666]
td... Autograd ArrayBox with value [30.95517666]
td->fd->td... Autograd ArrayBox with value [30.95517666]
td... Autograd ArrayBox with value [30.95517666]
td->fd->td... Autograd ArrayBox with value [30.95517666]
td... Autograd ArrayBox with value [30.95517666]
td->fd->td... Autograd ArrayBox with value [30.95517666]
td... [0.10394093]
td->fd->td... [0.10394093]
td... [0.10394093]
td->fd->td... [0.10394093]
td... [0.10394093]
td->fd->td... [0.10394093]
td... [0.10394093]
td->fd->td... [0.10394093]

@degoeden
Copy link
Author

degoeden commented Apr 2, 2024

Hi Daniel,

Thank you for your response.

Yes, I get different numbers from the td... and the td->fd->td... lines, here is a snippet of my output:
td... [12.70222252]
td->fd->td... [-9.18424669]
td... [12.70222252]
td->fd->td... [-10.03008321]
td... [12.70222252]
td->fd->td... [-9.18424669]
td... Autograd ArrayBox with value [12.70222252]
td->fd->td... Autograd ArrayBox with value [-9.18424669]
td... [12.70222252]
td->fd->td... [-9.18424669]
td... [12.70222252]
td->fd->td... [-10.03008321]
Note that it does eventually move away from the 12.7 and -9/-10ish numbers.

Here is some sample output from a different machine, same environment though:
td... [10.30784814]
td->fd->td... [-11.06998034]
td... [10.30784814]
td->fd->td... [-10.22895532]
td... [10.30784814]
td->fd->td... [-11.06998034]

I feel at this point it is worth noting that the bug doesn't always seem to change the sign, it just happened to for these two examples.

I created a fresh environment, still running 2.6.0, and I get this:
td... [4.69682963]
td->fd->td... [-19.86181125]
td... [4.69682963]
td->fd->td... [-19.0364325]
td... [4.69682963]
td->fd->td... [-19.86181125]

If you aren't seeing this behavior then I am very confused. Before creating the fresh environment I thought maybe something in my environment was causing issues. Any ideas on what else might be going on?

@dtgaebe dtgaebe mentioned this issue Apr 2, 2024
10 tasks
@dtgaebe
Copy link
Collaborator

dtgaebe commented Apr 2, 2024

Hi @degoeden ,

many apologies. I was running wecopttool==2.4.
There was indeed a bug in fd_to_td() in the latest wecopttool versions. We should have fixed this bug with #329

@dtgaebe dtgaebe closed this as completed Apr 2, 2024
@degoeden
Copy link
Author

degoeden commented Apr 3, 2024

No worries, thank you for your help!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

No branches or pull requests

3 participants