search

rallured / PyXFocus

General purpose raytracing software with an emphasis on X-ray telescope design
Other
2 stars 3 forks source link

Radgratfix #9

Closed rallured closed 5 years ago

rallured commented 5 years ago

radgrat in transformationsf.f95 now uses arctan2. That function needs to be called from the hub, but now the hub can be placed at any point in the xy plane.

bddonovan commented 5 years ago

This messed up my OGRE raytrace. I'll look into this more tomorrow.

rallured commented 5 years ago

Hmm, that's weird. What was the mode of failure? Evanescence/NaNs? Or did it still come to a focus, but just an aberrated focus?

If the code moves the hub in the opposite direction as intended, then it would probably be the latter. This would essentially fan the grooves in the opposite manner, resulting in a pretty shitty focus.

bddonovan commented 5 years ago

There is seemingly a yaw error. It's diffracting to the same location, but instead of the LSF being <1mm in the cross-dispersion direction, it is extended over >140mm.

rallured commented 5 years ago

Yeah so you're moving the hub in the opposite direction as radgrat thinks you should. So the mean groove period is correct, but the grooves are fanned the opposite way, resulting in the cross dispersion being messed up.

I'm going to make a test function to make sure I have the sign conventions correct. I'll touch base with you soon.

rallured commented 5 years ago

I checked the sign conventions, and they seem correct to me.

Can you put in a break point right before you call the transformations to place the hub? Check the sign of the largest direction cosine (it should be rays[4] or rays[5] for grazing incidence). Next go to the hub. Check the sign of the largest cosine and the associated position vector...they should be opposite. For example, if mean(rays[5]) is ~ 1 and positive, the rays are pointed in the +y direction. If you are at the hub, mean(rays[2]) should therefore be negative. In other other words, the position vector and the direction vector should be pointing in opposite directions. If this is not true, you have an error in where you place the hub, which is probably because my sign conventions used to be weird.

Let me know.

bddonovan commented 5 years ago

I'm not sure I understand this. I have that mean(rays[5]) is ~1, but why should mean(rays[2]) be negative? As I understand your coordinate system for the radgrat function, the grooves emanate in the +y direction, which means that mean(rays[2]) should be positive if the hub is at y=0, no?

rallured commented 5 years ago

The grooves don't really emanate in any certain direction. They simply emanate from the hub.

In radgrat, the hub is your origin (x=y=z=0). Your rays are at some position unit vector P. For the usual OPG diffraction geometry, the rays should be pointing roughly at the hub. This means that the ray direction unit vector should be roughly -P. Sketch it out, and I bet you'll agree with me.

As radgrat is implemented in this update, you can actually put the hub anywhere you want in the xy plane, and it will do the correct thing. So you could do coordinate transformations to put the hub in the orthogonal direction (say +x if the rays are pointing in -y) by a very large distance, and it will approximate the usual parallel groove in plane reflection grating (provided your hubdist cancels out the large distance you've moved in +x). There is no longer any preferred direction.

This also means that you could write a function that automatically figures out which way to move the hub based on the direction cosines of the rays. If they are pointing in +y, then the hub should be moved in the same direction (to make the positions negative) after the yaw rotation about the z axis is applied.

rallured commented 5 years ago

You might be confused by the comments in transformationsf.f95. Those haven't been updated in years. I'll fix them.

bddonovan commented 5 years ago

I think I understand now. This seems to be an issue with the z-hat direction cosine? I've always created rays that had positive +z-hat direction cosines because I don't think the radgrat ever worked with -z-hat direction cosines and/or transformations always behaved opposite to how I thought they should with -z-hat direction cosines. So you're saying if my position vector is positive, my direction cosine needs to be negative? I would agree with this physically.

rallured commented 5 years ago

Ok, I fixed the comments and also made sure radgratW (with a wavelength vector) operates the same way.

So does this sound good? I think the function operates in a physically consistent manner now.