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

How to restore EM field from polar back to Cartesian coordinates ? #203

Closed
zubairy opened this issue Apr 19, 2019 · 5 comments
Closed

How to restore EM field from polar back to Cartesian coordinates ? #203

zubairy opened this issue Apr 19, 2019 · 5 comments

Comments

@zubairy
Copy link

zubairy commented Apr 19, 2019

Postpic version v0.4 run on python 2.7.15 (Anaconda), GCC 7.3.0

Hi, the figure below shows my attempt to transform EM field from Cartesian to polar and then back.
Picture2
(a) is the original field; transform it to polar (b) using pp.Field.topolar();
(c) using the map_coordinate as described in the doc;
(d) & (e) are attempt to transform the field from (b) and (c) respectively, back to Cartesian using map_coordinates.

My question is that why (b) & (c) diffrent, and how can I get the correct field from polar back to Cartesian. There I think must be some I don't understand about the map_coordinates function. The Python script I used is also attached.

Thanks

@skuschel skuschel added bug Something isn't working (as expected) needs discussion question/support labels Apr 21, 2019
@skuschel
Copy link
Owner

skuschel commented Apr 21, 2019

Dear @zubairy
I realized, there is an inconsitency in the axis order. You can actually fix your example by changing the definitions of the conversion functions to:

 def polar_to_xy(Xn,Yn):
     r = np.sqrt(Xn**2+Yn**2)
     theta = np.arctan2(Yn,Xn)
     return theta, r
 
 def T(theta, r):
     x = r*np.cos(theta)
     y = r*np.sin(theta)
     return x, y

note, that only the order of the arguments (r, theta) is changed to (theta, r). Also I replaced ndgrid by np.meshgrid. The SciTools package has not been updated since 2011.

This will make your example almost work. In the back transformation the theta coordinate jumps from -pi to pi, which results in a tiny jacobian. Hence the negative x axis get huge values. If the color scale is adjusted, the image is fine anywhere else, as seen in the plot E4_back1_xy (according to your example file) below.

E4_back1_xy

I think we need to look into this, but I am on travel right now. However, i will leave the issue open for now, till we resolved the inconsistency. Thanks a lot for reporting it and I hope things work for you now! Please let me know if something else comes up.

Cheers
Stephan

@zubairy
Copy link
Author

zubairy commented Apr 21, 2019

Dear Stephan,

Thank you so much for replying me during your travel, changing the definition of the functions indeed works. Actually, this time in the helper.py file I found the linear2polar function, which is just for transforming field from polar to Cartesian. I should see it earlier!

So now, the only problem is the “huge value”. I don’t know much about the Jacobian; maybe you’ve got some idea to handle it in elegant way. If not, the transformation is already pretty fine for me.

Regards,
Lingang

@Ablinne
Copy link
Collaborator

Ablinne commented May 8, 2019

One possibility to fix the problem with the Jacobian is to pass it explicitly. To avoid confusion, please note that your function called polar_to_xy is actually used to transform the xy coordinates of the output Field to the polar coordinates where the input field is sampled. Its Jacobian is 1/r or 1/sqrt(x^2+y^2) instead of just r for the actual "polar to xy" transformation. By passing the function 1/sqrt(x^2+y^2) explicitly to Field.map_coordinates you can get a good result:
Screenshot_20190508_164421

I am not sure if there is anything we can do to the numeric code to automagically find the discontinuity and do the correct thing about it...

@zubairy
Copy link
Author

zubairy commented May 27, 2019

Dear Alexander,

Sorry for this long-delayed reply, I didn't see the notification email from github until today. Your reply perfectly solved my problem, and to my understanding, passing Jacobian explicitly can also be used for any other future transformation.

Thanks
Lingang

@Ablinne
Copy link
Collaborator

Ablinne commented May 27, 2019

Thanks for the feedback!

@Ablinne Ablinne closed this as completed May 27, 2019
@skuschel skuschel removed bug Something isn't working (as expected) needs discussion labels Jul 29, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants