[CIG-MC] problem with citcoms vtk output?

[Thorsten Becker]

hi dan,

i checked in a new version of output_vtk which has the overall node
ordering you suggest. not sure if it matters
if things run S-N or N-S for vtk, for example, but a quick check in
paraview seems to show that the geometry is now at least ok.

if you need different sorting, just change loops like

for(l=1;l <= nox;l++)

into

for(l=nox;l >=1;l--)

to reverse the theta loop for example.

cheers

t


Thorsten Becker - http://geodynamics.usc.edu/~becker



On Sun, Feb 13, 2011 at 17:57, Dan Bower <danb at gps.caltech.edu> wrote:
> 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/
>>
> _______________________________________________
> CIG-MC mailing list
> CIG-MC at geodynamics.org
> http://geodynamics.org/cgi-bin/mailman/listinfo/cig-mc
>