Open akashsngh opened 11 months ago
which notebook is it? @akashsngh
Hello Alex, I did not get the question. Should I share the notebook with the example ?@alexlib
Best, Akash
Hello Alex,
I did not get the question. Should I share the notebook with the example ?@alexlib
Best,
Akash
yes please. i tested it and the direction seems fine at least same way as the windef somewhere i miss the problem you mentioned
Okay, here is the notebook. I have added some part regarding the corrections
https://colab.research.google.com/drive/1f3lSGfhQKPhnWECnzm1LrkvVRjDRZSRh?usp=sharing
Okay, here is the notebook. I have added some part regarding the corrections
https://colab.research.google.com/drive/1f3lSGfhQKPhnWECnzm1LrkvVRjDRZSRh?usp=sharing
I run the notebook and I think that everything is correct. Let's maybe talk about it and see if we understand. You refer to the first image that is attached - but please notice that it's shown with Python matplotlib conventions - the origin, 0,0 is at the bottom left, while in the images you look at, usually the origin is top left - which means that you see flow from top to bottom it's NEGATIVE VERTICAL VELOCITY in the axis x,y with the typical definitions of Numpy, Matplotlib, etc.
Hello Alex, Yes, that is true I am inverting the y-axis to bring the 0,0 at the bottom left. However, when plotting, this should work or both the image and the quiver array, so even if I comment on this line (#fig.gca().invert_yaxis()), the results seem wrong.
However, the x, y output I have from pyprocess.get_coordinates ( I use it to plot the results of pyprocess.extended_search_area_piv), are rightly shaped so I do not need to reshape the y.
Maybe it is a convention thing, I hope I am clear. Thanks!
we shall be correct in the output matrix, x,y,u,v shall be correct, independent of how we present those. v is negative and that's what we have in the file I think. The way to show it shall be adjusted depending on the way you need it - with or without the image, with the origin at the lower left or upper left. all these options are possible.
On Thu, Oct 19, 2023 at 3:24 PM akashsngh @.***> wrote:
Hello Alex, Yes, that is true I am inverting the y-axis to bring the 0,0 at the bottom left. However, when plotting, this should work or both the image and the quiver array, so even if I comment on this line (#fig.gca().invert_yaxis()), the results seem wrong.
However, the x, y output I have from pyprocess.get_coordinates ( I use it to plot the results of pyprocess.extended_search_area_piv), are rightly shaped so I do not need to reshape the y.
Maybe it is a convention thing, I hope I am clear. Thanks!
— Reply to this email directly, view it on GitHub https://github.com/OpenPIV/openpiv-python-examples/issues/15#issuecomment-1770860709, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAFWMZS4ONZGSDO452YJUSTYAELYNAVCNFSM6AAAAAA562KRFCVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTONZQHA3DANZQHE . You are receiving this because you were mentioned.Message ID: @.***>
Hello, When I plotted the output of the simple multipass, the direction of the quivers where not aligned. The exact bug is in the sign of the v component and the y array output of the simple_multipass. The correction is v= -v, and y = y[::-1, :] i.e. the outer axis of y needs to be inversed. Also, the u and v outputted are displacements and not velocities, so an additional division by dt should be added in.
Best regards. Akash