[CIG-MC] problem with citcoms vtk output?

[Dan Bower]

Just closing this e-mail thread with the bug (and solution) in case
anyone else is interested ...

Connectivity between cells is implied using the vtkstructuredgrid
class and from experimenting a little I've found that XML VTK requires
an output nodal (point) ordering like follows:

   # loop starts at 0 longitude, the North Pole
   for rr in radius1:
     for pp in phi1:
       for tt in theta1:

         # convert to cartesian (from citcoms c code)
         rst = float(rr)*sin(theta2)
         x = rst*cos(phi2)
         y = rst*sin(phi2)
         z = float(rr)*cos(theta2)

         Points.InsertNextPoint(x, y, z)


This is in contrast to the usual citcoms convention where radius is
always the innermost loop.  This is the source of the vtk output
error, and can easily be fixed by correcting the vtk output to loop zz
then yy then xx, or alternatively by reordering the data after it's
been output.

Hope this is helpful for others as well,

Dan

On Fri, Feb 11, 2011 at 12:11 PM, Thorsten Becker <thorstinski at gmail.com> wrote:
> hi dan,
>
> i used the routines in Output_gzdir.c for a few odd geometries, like the
> attached nodex=17 nodey=17 nodez=5 for 12 CPUs, and 33 x 9 x 33 for
> 2x2x2x12=96 CPUs  and everything seems to be fine. i have scripts to combine
> the  Output_gzdir.c format into one VTK file and that's why i've plotted using
> paraview. (i'd happily share those but they are a bit involved.)
>
> however, the coordinates are taken straight from the E->x[][][] Cartesian node
> locations, just like output_vtk, so i think that internally everything is fine.
>
> could it be that the problem is with output_vtk.c ? i took a very quick look
> but couldn't find anything.
>
> cheers
>
> t
>
>
>
> On Thursday, February 10, 2011 08:49:04 you wrote:
>> Hi Thorsten,
>>
>> Yes - If I use regular output and then convert to vtk (using the
>> rtp2xyz etc. functions) the same problem exists.
>>
>> I'll look into the smallest example problem and get back to you.
>>
>> I'd guess this has never worked properly, but I've only just started
>> using the vtk output so I'm not completely sure.
>>
>> Enjoy the rest of your vacation!
>>
>> Dan
>>
>> On Wed, Feb 9, 2011 at 11:07 PM, Thorsten Becker <thorstinski at gmail.com>
> wrote:
>> > Hi Dan
>> >
>> > I'll take a look when I'm back from vacation. Just to be clear: this is
>> > not just a vtk (output_gzdir) problem, but also arises when the regular
>> > output is used?
>> >
>> > Also, the smallest possible example problem where this happens would be
>> > helpful. Likewise, is this something that never worked or something that
>> > stopped working recently?
>> >
>> > Thanks!
>> >
>> > Thorsten W Becker - USC
>> >
>> > On Feb 9, 2011, at 16:23, Dan Bower <danb at gps.caltech.edu> wrote:
>> >> Hi all,
>> >>
>> >> For a citcoms global run if nodex=nodey=nodez the vtk output seems to
>> >> be correct and the data looks good in paraview.
>> >>
>> >> However, if nodex=nodey<>nodez there appears to be a problem.
>> >>
>> >> Attached (jpg) is the output from one processor (proc 0) for a 129 x
>> >> 129 x 65 mesh (per cap, global).  In this model
>> >> nprocx=nprocy=nprocz=2.
>> >>
>> >> You can see that the mesh is clearly distorted and the output funky
>> >> when visualized using paraview.
>> >>
>> >> The data itself is totally fine (independently checked using GMT).  I
>> >> wrote a python script to convert the standard output (*.velo.* files)
>> >> to vtk format and got the same problem (maybe not surprising, given
>> >> that I took the same coordinate mappings from the c code).
>> >>
>> >> I poked around in Full_sphere_related.c (for the co-ordinate mappings)
>> >> and Output_vtk.c, but didn't see anything obvious.
>> >>
>> >> Any pointers appreciated!
>> >>
>> >> Thanks,
>> >>
>> >> Dan
>> >> <problem1.jpg>
>> >> <problem2.jpg>
>> >> _______________________________________________
>> >> CIG-MC mailing list
>> >> CIG-MC at geodynamics.org
>> >> http://geodynamics.org/cgi-bin/mailman/listinfo/cig-mc
>
> --
> Thorsten Becker  - University of Southern California
> http://geodynamics.usc.edu/~becker/
>