[Python-apps-team] Bug#478359: Bug#478359: mayavi2: fails to read blocks other than the first, in multiblock PLOT3D files

[Francesco Poli]

On Mon, 05 May 2008 21:38:45 +0530 Prabhu Ramachandran wrote:

[...]
> Varun Hiremath wrote:
> >> I'm unable to read any block, except the first, in multiblock
> >> PLOT3D files.
> >> I can reproduce this bug with any multiblock PLOT3D file having more
> >> than one block.  For instance we can consider the test case I prepared
> >> for bug #400406 (see [1] and [2]).
> 
> Mayavi2's current plot3d support is very basic and does not support any 
> multi-block data.

Well, I would say it supports it partially, in the sense that it reads
multi-block data, but is only able to load the first block...

[...]
> >> [2] http://bugs.debian.org/cgi-bin/bugreport.cgi/vtk-multiblockPLOT3D-bug-test.tar.gz?bug=400406;msg=5;att=1
> 
> The test data is useful thanks.

You're welcome.

> I'll keep a copy just so it can be used 
> when I get to implementing the multi block support.

I hope that this can happen soon, because MayaVi2 is really unusable
for me, until it can read multi-block PLOT3D files.

[...]
> >> I would like to have a means to decide which grid blocks will be loaded
> >> (e.g.: I want to load block 1, 2, and 4, but not the remaining two),
> >> so that a number of PLOT3D:tiny.xyz, tiny.q objects are automatically
> >> created, each one corresponding to one of the requested grid blocks
> >> (e.g.: three objects are created, corresponding to blocks 1, 2, and 4).
> 
> The trouble with this approach is that it breaks down when you have 100 
> blocks.  How do you view 100 of them?  Anyway, this is something that 
> would require some thought and work.

OK, let's tell the truth, the whole truth, and nothing but the truth!

What would be really great to have (a dream, actually) is the
possibility to select which blocks to load from a PLOT3D file
(say, blocks #1, #2 and #4) and have them as children of the data
source.  E.g.:

 * TVTK Scene 1
   * PLOT3D:tiny.xyz, tiny.q
     * Modules
       * ContourGridPlane
     * data block #1
       * Modules
         * Surface
     * data block #2
     * data block #4
       * Modules
         * Surface

Then, the user could select one block (say, block #4 only) or the whole
data source, and create filters and modules in single clicks that
would apply to the selected block or to all loaded blocks, respectively.

Automatic data ranges (for contours, color maps, and so forth)
would be computed by taking into account the selected block only
or all loaded blocks, respectively, unless the user asks for
global data range.
In the above example, assume the scalar minima and maxima are:

  block #1:  min = 0.1  max = 0.5
  block #2:  min = 0.3  max = 3.1
  block #4:  min = 6.5  max = 7.8

Then the automatic data range would be (0.1, 7.8) for the
ContourGridPlane, while (0.1, 0.5) and (6.5, 7.8) for the two
Surface modules, but the user would have an option to switch
to global data range, so that he/she could have block #4 Surface
data range set to (0.1, 7.8), in case he/she wants to, without
having to manually enter the numerical values!


I am aware that the above could be tricky and burdensome to implement.
If it turns out to be really too hard (even for visualization gurus
like you!), my original request is an second-choice simpler approach.
I'll repeat it here, just to be sure what I'm referring to is clear
enough:

| I would like to have a means to decide which grid blocks will be loaded
| (e.g.: I want to load block 1, 2, and 4, but not the remaining two),
| so that a number of PLOT3D:tiny.xyz, tiny.q objects are automatically
| created, each one corresponding to one of the requested grid blocks
| (e.g.: three objects are created, corresponding to blocks 1, 2, and 4).

Obviously the objects corresponding to the load blocks could well be
represented as children of one single data source object:

 * TVTK Scene 1
   * PLOT3D:tiny.xyz, tiny.q
     * data block #1
       * Modules
         * Surface
     * data block #2
     * data block #4
       * Modules
         * Surface

and an option to compute automatic data ranges from the whole set of
loaded data, rather than from the current block, would be really
useful. 


I really hope one of these two possible approaches can be implemented
soon.

-- 
 http://frx.netsons.org/doc/index.html#nanodocs
 The nano-document series is here!
..................................................... Francesco Poli .
 GnuPG key fpr == C979 F34B 27CE 5CD8 DC12  31B5 78F4 279B DD6D FCF4

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://lists.alioth.debian.org/pipermail/python-apps-team/attachments/20080507/7bbd7008/attachment.pgp