Regarding Simon's problem with Band, I spent some time yesterday working on it and discovered something odd that I've never seen before in DX. I haven't finished working on this, but I thought Donna or Nancy or others might have thoughts.
In the test file Simon sent, there are both "invalid positions" and "invalid connections". I thought this was weird, and probably bad, but this is what Export output. I did the following: 1. Remove "invalid positions", to Band, Autocolor, Image: this works. 2. Remove "invalid connections", B-A-I: error that Simon reported about dependent array must be scalar bytes 3. Checked and in fact, using Compute, forced "invalid positions" to scalar bytes of only 00 and 01, then B-A-I: Didn't fix it (same as Test 2). 4. Remove both "inv pos" and "inv conn", B-A-I: this works. In fact, it doesn't look a whole lot different than when you leave "invalid connections" in. There are some subtle differences. (Simon, did the invalids result from processing to remove the "0" data in the net that Exported this test?) 5. Ran the original data through Autocolor-Image (no Band): works without complaint. Of course, this shows a regular grid eroded by invalids. 6. Removed both invalids, A-I: works and of course shows the whole regular grid with lots of blue "0" areas. 7. Reconstructed a field from Extracted "positions", "connections", "data", and various permutations of the "invalid"s in the original data using Construct and Replace. This is where is gets weird: I Extract the "invalid positions", and Print them, and see a Generic array of scalar bytes as expected. But the simple act of Replacing these into my constructed Field, then Print that output shows that the field now miraculously has both "invalid positions" and "invalid connections". I don't think I've ever seen this happen. Richard and I started to poke around in some likely source code like helper.c and invalid.c (whew: that's a monster!) but didn't find the answer before other duties called. Now, as remarked earlier, the output of Band when the input field has no invalids shows the original regular grid with large holes in it and a variety of sliver triangles within the original grid cells (in some areas). These holes apparently occur wherever the data was "0". I guess I don't understand why Band should throw away all the "0" data. But clearly it is and therefore internally it is generating its own "invalids", then apparently culling them. So my tentative hypothesis is that the weird combination of a field with both invalid positions and connections, run through Band which tries to do its own invalidating, caused DX to barf trying to resolve who is more invalid. It may be the order that invalids are applied: if positions are invalidated first, but don't mesh perfectly with the polygons that invalid connections say are invalid, then I can imagine that the field internal structure may be corrupted and some error message generator deep down inside is spewing an error that isn't exactly the cause but a side-effect of the real problem. 8. Reminded by Donna's remarks on "ref" invalidity, I played with the idea that the "invalid connections" are processed first, then, somehow the "invalid positions" are being internally recast as "ref" rather than "dep". This didn't seem to pan out. So, what do you think? Why does Replace instantly generate "invalid connections"? Is it OK and I just never noticed it, to have a field with both invalids at the same time? Am I guessing right about Band's internals? Why does Band cull "0" (Simon might want to see all the 0 data!). Chris Pelkie Vice President/Scientific Visualization Producer Conceptual Reality Presentations, Inc. 30 West Meadow Drive Ithaca, NY 14850 [EMAIL PROTECTED] (607) 257-8335 or (607) 254-8794
