Extracting Motion and Rotation using Chrono?
Hello!
I am using Chrono on a case with a few cylinders connected to each other. To look at the translations, I am looking at the ChronoExchange__.csv files, but I cannot see the rotations directly.
Do I have to do some integration of omega, if yes how to do so?
If I look at the translations (fcenter.x, fcenter.y, fcenter.z) I notice that these values do not match the values from the post-processing tool, BoundaryVTK. How come that is the case?
Kind regards
Comments
BoundaryVTK? Did you mean FloatingInfo, right?
The values from FloatingInfo are computed in terms of global coordinates.
Hi Álex!
No, I actually meant BoundaryVTK, which I like to use to generate the visualization files + movement csv's - they work for floating objects too.
I can try using FloatingInfo in the future, but it seems to me that the motion data from ChronoExchange and BoundaryVTK should be possible to get to match together? Since it is DSPH telling Chrono, "where is the object now"?
Possibly it is a coordinate transformation which must be done, but taking the position signal from ChronoExchange and turning it into Displacement, does not equal the Boundary post-processing tool result in all cases.
Kind regards
@Alex we have discovered that there is potentially a bug in BoundaryVTK, when post-processing floatings that use Chrono.
The bug seems to be that the BoundaryVTK tool uses the initial CoG of the particle distribution and NOT the value specified under "floating" properties in DualSPHysics XML file.
One could argue that this is intended behavior, but I would rather argue that it goes against expectation because examine the following case:
Two squares in 2D, one with CoG in the middle (blue) and one with CoG outside of the square (red) - CoG's denoted by black dots. Then if you impose a rotation around y-axis, while locking all other degrees of freedom (similar for both squares) and definite as a floating object with Chrona, then at a later time step it would look like this:
In which we will know that since only rotation is occuring around an axis, CoG should stay exactly where it is at all time steps.
This is captured in the ChronoExchange output files, but the BoundaryVTK gives weird angular results, and more importantly, it will show no translation for the blue square, but will show translation in x and z, for the red square, which is wrong when the CoG input in XML does not move.
Therefore the results from BoundaryVTK become less intuitive (even if they might be correct) the moment you have a CoG which is not at the center of your object.
Would love to hear the developers thoughts about this, perhaps there is an option in BoundaryVTK I am not aware of.
Kind regards
We will check it, however I do not understand why the bug it will be in BoundaryVTK since that is only visualisation during post-processing...
Perhaps the error is in FloatingInfo?
Alex
Hi again!
I have not compared up against FloatingInfo.exe, results in there might be correct. Perhaps I will give it a look tomorrow.
I have compared up against BoundaryVTK, since BoundaryVTK exports visualization files. The visualization files look fine in Paraview, so .vtk has no issues. But BoundaryVTK also allows for export of csv files - I believe that these files have a bug due to reasoning provided in my previous message.
Kind regards
@Alex I can confirm that FloatingInfo retrieves the correct center.x, center.y and center.z of both bodies, mentioned in the top post. The pitch signal are similar for both cases, and both experience the singularity error, i.e. flipping from -180 to 180 degrees.
Kind regards
FloatingInfo reads values stored in PartFloat.fbi4 by DualSPHysics. However, BoundaryVTK calculates the motion of the bodies according to the positions of the particles and this results in small differences. In addition, the position of particles is stored with single or double precision in BI4 files, which also generates differences.
File ChronoExchange_XXXX.csv stores the data less accurately and this also produces differences compared to the results of FloatingInfo.
I have not found any errors in BoundaryVTK. Anyway, the option -savemotion will generate a CSV file with the transformation matrix. In this way, anyone can apply this matrix to calculate the movement of any position. This change will be available in the next version of BoundaryVTK.
Best regards
Thank you very much for your feedback!
Is the source code for floating info available? I am interested in how it calculates pitch, surge etc.
Personally we have found ChronoExchange_XXXX.csv to produce results in a format we are much happier with, since it tracks the actual COG set in the XML file and not the COG of the particle distribution. In some cases you might have point masses in your system and in these cases COG of particle distribution only is not good enough - but it will be nice to have the transformation matrices in future versions, thank you very much for the hard work on the software.
I will keep in mind your comment about ChronoExchange losing some accuracy compared to FloatingInfo, when I compared the two outputs they looked quite familiar, so I assume it calculates the same as ChronoExchange just based on Part_XXXX.bi4, instead of "current running simulation values".
Kind regards