Closed lesserwhirls closed 2 years ago
lesserwhirls
commented
10 years ago Ok, I think I have this figured out now and it appears be working as it should. Thanks to Don for the tip of setting the flow type (useFlow1 true/false) at the time the FlowDisplayable is constructed.
donmurray
commented
10 years ago Sean-
Thanks for tackling this. A few comments about your changes:
I don't think making it dependent on the type of display is a good idea because if I have 2 streamline displays, they'd each use the same FlowControl and changes (e.g, streamline density) to one would be reflected in the other. Also, if you set the Id in the DisplayControl properties dialog, it will change the id.
I would use the same sort of logic that FlowDisplayable uses - for each new display control, make useFlow1 = !useFlow1. The idea is to keep the same VisAD FlowXControl for each DisplayControl. Since you only have 2 possibilities (Flow1 and Flow2), it's not perfect, but at least you could have 2 of the same type of display (e.g. streamlines) and they wouldn't conflict.
You'll need to add set/getUseFlow1 methods so this will be persisted in a bundle.
It looks like there are some spurious imports in FlowDisplayable that should not be there:
import org.apache.xpath.operations.Bool; import ucar.unidata.ui.InputFieldPanel;
Finally, in FlowDisplayable, I would keep the useFlow1 = !useFlow1 so that for all the other classes that use FlowDisplayable (like profiler and cross section), the old logic will still hold such that with 2, they won't conflict. Instead of changing the semantics of useFlow1, add a new variable (e.g. useConstantFlowControl) and check that.
Don
CLAassistant
commented
2 years ago
Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.
...rs and different smoothing/non-smoothing options leads to funky-ness.
_Needs review!_ Not sure what the point of having Flow1 and Flow2 Keys for the various VisAD shadow objects that are created by the PlanFlowView controls; these are created when changing between vectors/streamlines and smoothing/non-smoothing options. Somewhere, the book keeping of flow1 and flow2, things get messed up and the ability to change between vector and streamline, smoothed/not-smoothed displays starts to fail (see Tom's ticket below). If all shadow objects are forced to use a Flow1 key, then everything seems to work just fine. I tested with bundles created with a 5.0 nightly build, and they still work just fine when useFlow1 is forced to be true.
Tom's latest ticket in e-support:
Hi Sean...
(I talked briefly with Don about this and he mentioned there was no ticket for it, so I'm sending this through support to get one for tracking.)
I wanted to follow-up on this issue of "smoothing" in the streamline/vector display. Last September you wrote that you'd been looking into this and it appeared that the error message was coming from VisAD, and I agree (visad.ShadowType); however, I think it's because there is something else going on in the IDV.
I gotta think it's something in one of the "Flow Controls" that's not being set (un-set?) right...try this:
Sometimes after doing this, I noticed that if I then change the smoothing type to something else, the correct display appears....
If you start again, but do this:
The data display will vanish and this message appears (which I think you've seen as well): "only one or two ScalarMaps to Flow per data allowed if streamlines enabled"
If you now change to Vector, then select a different smoothing type, the streamlines appear! Then if you pick a different smoothing type, the vectors show up!
It's all very odd...and I can't help but think more than one thing is going "wrong" here...but I looked into FlowPlanViewControl and PlanViewControl and DisplayImpl, and (of course) I got lost in the woods...so I hope you can find out what's going on!
tom