Flow renderer doesn't work with some UGRID data

[clyne]

The flow renderer does not seem to work with UGRID data.

To reproduce:

1. Load all of the files in UGRID/NOAA-geoflow/small
2. Create a flow renderer and set the X,Y,Z component variables to v1, v2, v3
3. Enable the renderer

Nothing is displayed. Changing various flow parameters doesn't seem to help

[shaomeng]

Here's a description of the cause of this bug, and possible solutions.

1. This particular dataset is super fat: its X, Y extents are in the order of tens of millions, and Z extent is 1.
2. There is a parameter deltaT in advection code that controls the step size of advection. Currently, deltaT is a scalar value. Also, deltaT is initialized so that it takes approximately 1000 steps for a particle to travel from one corner of the volume to another corner, i.e., distance in millions.
3. The same scalar deltaT applies on all directions, including the Z direction. Using this dataset, even samples of surrounding areas of a particle required by Runge Kudda 4 is out of the domain in Z. These out of domain samples cause the reported failure.

One possible solution is to fall back to Euler method instead of RK4 when this type of failure happens. It will solve the problem for that particular particle which itself is still in the domain, but I suspect its immediate next few positions will be out of domain again, and not render any meaningful trajectories.

Another possible solution is to accept the fact that any meaningful advection will place the particle out of domain given how fat it is. There could be a more informative message to the users though.

Please let me know what you think. @clyne

[clyne]

@shaomeng I think that there are two issues with the flow renderer with this data set:

1. If all three components of velocity are used (v1, v2, v3), then given the huge asymmetry of the data what I would expect to happen is that the flow lines would immediately exit the Z-top or Z-bottom of the domain (instead nothing is drawn).. I think this behavior is explained by your comments above. Perhaps the calculation of deltaT should be performed differently?
2. The second problem is perhaps more problematic. If the third component of velocity is set to I would expect the integration to work more as expected, because now there is no Z velocity to send the streamlines out of the top or bottom of the domain. However, something is not quite right. Streamlines are drawn in this case, but they don't seem to go very far. Changing the "Integration steps" from the default 100 to 1000 doesn't have any significant impact. Nor does changing the Velocity Field Multiplier from 1.0 to 1000.0. I don't know if this is again related to the deltaT calculation, but perhaps the domain size along an axis with a zero velocity field should not be used in the deltaT calculation?

[shaomeng]

1. To see "the flow lines would immediately exit the Z-top or Z-bottom of the domain (instead nothing is drawn)" you need to have at least 2 valid positions inside of the domain. But the difference is so big that not only the 2nd position is out, even the "surrounding areas" of the 1st position is also out, and out by a lot. This issue, however, can be fixed by a much much smaller deltaT. Then the question becomes, how to decide deltaT so that it works well on both super flat and kinda normal volumes? I'd say there simply isn't an ideal deltaT to make this extremely asymmetric volume work well.

2. The second point you made, if I understand correctly, is to set variable v1 as X field, v2 as Y field, and nothing in the Z field? In that case, I do see some line segments but they don't go very far. They do advance for 100 or 10000 steps though, which can be verified when you output the calculated trajectories. Do you know what physics is this dataset and what the trajectories are supposed to look like ? @clyne

[clyne]

1. To see "the flow lines would immediately exit the Z-top or Z-bottom of the domain (instead nothing is drawn)" you need to have at least 2 valid positions inside of the domain. But the difference is so big that not only the 2nd position is out, even the "surrounding areas" of the 1st position is also out, and out by a lot. This issue, however, can be fixed by a much much smaller deltaT. Then the question becomes, how to decide deltaT so that it works well on both super flat and kinda normal volumes? I'd say there simply isn't an ideal deltaT to make this extremely asymmetric volume work well.

Perhaps a simple fix that might help this problem is to calculate deltaT as you have done, but then check to ensure that it is not so large that you can't complete a single integration step along every direction. If it is, simply make it as small as it needs to be.

2. The second point you made, if I understand correctly, is to set variable v1 as X field, v2 as Y field, and nothing in the Z field? In that case, I do see some line segments but they don't go very far. They do advance for 100 or 10000 steps though, which can be verified when you output the calculated trajectories. Do you know what physics is this dataset and what the trajectories are supposed to look like ? @clyne

No, I do not know what they are supposed to look like, but I don't see any evidence by looking at the v1 and v2 velocity components that there is a critical point (zero velocity) in the region where the stream lines appear to stop progressing. You should verify that he behavior is correct, and not a bug.

[shaomeng]

1. That sounds like a reasonable fix, and I can go ahead and implement that fix.
2. One thing to be clear is that a random field can also cause trajectories to "stop." That's because random fields can often cause sudden turns on the trajectory, and deltaT is automatically shrank when sudden turns happen. When deltaT is shrank many times, it appears that the trajectory has stopped. I'm investigate if that's what happened.