<div dir="ltr"><div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">Am Do., 28. März 2019 um 14:47 Uhr schrieb Dave May <<a href="mailto:dave.mayhem23@gmail.com" target="_blank">dave.mayhem23@gmail.com</a>>:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, 28 Mar 2019 at 21:38, Matthew Knepley <<a href="mailto:knepley@gmail.com" target="_blank">knepley@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div dir="ltr">On Thu, Mar 28, 2019 at 1:38 PM Dave May <<a href="mailto:dave.mayhem23@gmail.com" target="_blank">dave.mayhem23@gmail.com</a>> wrote:<br></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div>On Thu, 28 Mar 2019 at 18:05, Matthew Knepley <<a href="mailto:knepley@gmail.com" target="_blank">knepley@gmail.com</a>> wrote:<br></div><div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div dir="ltr">On Thu, Mar 28, 2019 at 12:47 PM Dave May via petsc-dev <<a href="mailto:petsc-dev@mcs.anl.gov" target="_blank">petsc-dev@mcs.anl.gov</a>> wrote:<br></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div><div dir="auto">I'd advocate flattening everything as a scalar field. Why? </div><div dir="auto">1) the xml vtk formats for vector only work if ncomponents = 3, so for a 2d field you have to insert a dummy set of zero values for the z component </div><div dir="auto">2) its simple to build vector fields which paraview can render if the scalar fields are properly named (and inserting the k-components with zeroes if required)</div><div dir="auto">3) It will work for case 2 and case 3</div></div></blockquote><div><br></div><div>The painful thing on the other side is that you cannot plot glyphs for the vector field without</div><div>defining it by hand with the calculator. This was enough to kick me in the ass and define it.</div></div></div></blockquote><div dir="auto"><br></div><div dir="auto">So you're fine screwing up your C code and storing unnecessary data in a file (e.g. the dumm zeros) in 2D to accommodate paraviews broken support for their own native file format?? </div></div></div></blockquote><div><br></div><div>Sure. The C is poop anyway because its writing a quick and dirty format. The file itself also does not matter because</div><div>the format is embarassing. The whole point here is automation. It should automatically go end-to-end so Matt does</div><div>nothing but load the file into Paraview.</div></div></div></blockquote><div><br></div><div>Sure - I completely agree. </div><div>I "solve" the end-to-end problem by using state files. One time cost to type field_X*iHat + field_Y*jHat + 0*kHat in the calculator and create the state file. From then on, reloading via a state file requires the same number of mouse clicks (maybe one more). It works if and only if the field names do not change (e.g. are not stringified memory addresses).</div><div><br></div><div>Yes, working with those formats is definitely lame in more than one way ....</div></div></div></div></div></blockquote><div>I was going to say something similar to Matt; to me it is worth the 1.5x redundancy in the data if I can just view the output file with "doing anything special". I have also done something similar to what you're describing with save states, and it works fine; weirdly it seems like much higher overhead than it is, though. </div><div><br></div><div><div>It's not at all obvious to me what the best thing to do is, here. The 3.11 release is so imminent that I don't think any option other than a full revert could make it in. </div></div><div><br></div><div>Here's what I'd propose: too ugly and convoluted?</div><div>- If the user has set any custom field names for the DMDA, interpret that to mean that they want to deal with them individually, so use the old behavior (but incorporate Dave's comments on improving the field names)</div><div>- Otherwise, assume that the user wants the new (current) behavior</div><div>- Document this stuff as much as possible to try to avoid confusion</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div class="gmail_quote"><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_quote"><div><br></div><div> Matt</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div><div class="gmail_quote"><div dir="auto">I'd say that using the calculator is a small price to pay and I'd prefer to use it over messing up my code to accommodate problems with others software </div><div dir="auto"><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_quote"><div></div><div><br></div><div> Matt</div></div></div><div dir="ltr"><div class="gmail_quote"><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div><div class="gmail_quote"><div dir="ltr">On Thu, 28 Mar 2019 at 17:13, Patrick Sanan <<a href="mailto:patrick.sanan@gmail.com" target="_blank">patrick.sanan@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">Am Do., 28. März 2019 um 09:10 Uhr schrieb Patrick Sanan <<a href="mailto:patrick.sanan@gmail.com" target="_blank">patrick.sanan@gmail.com</a>>:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div dir="ltr">Agreed that <div>- these viewers should prioritize being quick and viewable with as little post-processing as possible</div><div>- this change is bad in throwing away the field name metadata<br><div><br></div><div>The trick here seems to be knowing what the user is representing with a multi-dof DMDA, and being faithful to that in the output file. This could be</div><div>1. a single scalar field</div><div>2. multiple scalar fields (which the user wants to store interlaced, as opposed to using a DMComposite)</div><div>3. a single vector-valued field</div><div>4. multiple scalar or vector fields, of arbitrary dimensions (adding up the total dof of the DMDA), interlaced</div><div><br></div><div>Case 4 can be approximated by case 2, as in Jed's initial example.</div><div>I believe that the PetscSection / PetscField framework was introduced to more generally support this, at least for DMPlex.<br></div></div></div></blockquote><div>PetscField isn't a thing - I meant the various PetscSection*Field*() functions. </div></div></div><div dir="ltr"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div><div></div><div><br></div><div>My PR broke (or at least harmed) case 2, to allow for more-convenient handling of case 3. </div><div>As Jed says, this was motivated by requiring less post-processing to view a vector field in Paraview,</div><div>but it created the need for more post-processing for the multiple-scalar-field approach.</div><div><br></div><div>Options to fix this include</div><div>a. Revert to the old behavior </div><div>b. Provide options to the user to distinguish between cases 2 and 3 (multiple scalar fields vs vector field)</div><div>c. Try to automatically detect which type of output (say, check if any field names have been set)</div><div>d. Investigate supporting case 4 (arbitrary fields of arbitrary dimension) by using PetscSection</div><div>e. (If even possible) Properly name the components of a vector in a VTK file</div><div><br></div><div>Before I start poking around, I'm shaky on assessing options d and e!</div><div><br></div><div><br></div><div><br></div></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">Am Do., 28. März 2019 um 08:21 Uhr schrieb Dave May via petsc-dev <<a href="mailto:petsc-dev@mcs.anl.gov" target="_blank">petsc-dev@mcs.anl.gov</a>>:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div><br></div><div><br><div class="gmail_quote"><div dir="ltr">On Thu, 28 Mar 2019 at 15:42, Jed Brown via petsc-dev <<a href="mailto:petsc-dev@mcs.anl.gov" target="_blank">petsc-dev@mcs.anl.gov</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">Matthew Knepley <<a href="mailto:knepley@gmail.com" target="_blank">knepley@gmail.com</a>> writes:<br>
<br>
> On Wed, Mar 27, 2019 at 10:56 PM Jed Brown via petsc-dev <<br>
> <a href="mailto:petsc-dev@mcs.anl.gov" target="_blank">petsc-dev@mcs.anl.gov</a>> wrote:<br>
><br>
>> Prior to this PR, which was merged for 3.10<br>
>><br>
>><br>
>> <a href="https://bitbucket.org/petsc/petsc/pull-requests/1029/dmda-vtk-viewing-output-multiple-dof/diff" rel="noreferrer" target="_blank">https://bitbucket.org/petsc/petsc/pull-requests/1029/dmda-vtk-viewing-output-multiple-dof/diff</a><br>
>> <a href="https://bitbucket.org/petsc/petsc/commits/ea2d7708fa6" rel="noreferrer" target="_blank">https://bitbucket.org/petsc/petsc/commits/ea2d7708fa6</a><br>
>><br>
>> we could have files that look like the following, and thus were easy to<br>
>> navigate in Paraview and Visit.<br>
>><br>
><br>
> Tell me if I am wrong (since I do not run it this way). I think the point<br>
> of Patrick's change is a good one, and<br>
> necessary to view things with DMStag. <br>
<br>
Or maybe just necessary to avoid needing to use multiple files or add<br>
filters.<br>
<br>
> What Jed dislikes, rightly, is that some metadata has gone missing.<br>
> Does Xdmf allow you to name the components? The way I do this<br>
> petsc_gen_xdmf.py is to write the whole thing as Patrick does, but<br>
> then create views into the data using the component names. It sound<br>
> like this should be doable here.<br>
<br>
Perhaps. A key reason for using VTK viewers is that they're relatively<br>
quick and foolproof compared to formats that need libraries and/or<br>
auxiliary files.</blockquote><div dir="auto"><br></div><div dir="auto">I completely agree with the above comment. I consider these files as "instant and usable viz".</div><div dir="auto"><br></div><div dir="auto">I'd like both the dm field names and the vec name to be used to define the vtk field names.</div><div dir="auto"><br></div><div dir="auto">One idea:</div><div dir="auto"> vecname_fieldname</div><div dir="auto">falling back to</div><div dir="auto"> "field"%d_fieldname, where %d is the index of the vector to be written (we can determine this as all vectors are cached to support appended data)</div><div dir="auto">faillng back to</div><div dir="auto"> "field"%d_%d</div><div dir="auto">where the last index here is the block index.</div><div dir="auto"><br></div><div dir="auto">These names should work with unnamed dm fields, multiple vectors obtained from DMCreateGlobalVector or VecDuplicate. It does not account immediately address what happens if two vectors produce identical fieldname - code should be added for that using the last fall back. I think this would be better than using the stringifed memory address which was used before Patrick's PR. That suffered from the same issue Jed raised at the start of this thread (users must remember the order vecs were written)</div><div dir="auto"><br></div><div dir="auto">Thanks</div><div dir="auto">Dave</div><div dir="auto"><br></div><div dir="auto"><br></div><div dir="auto"><br></div><div dir="auto"><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><br>
</blockquote></div></div>
</blockquote></div>
</blockquote></div></div>
</blockquote></div></div>
</blockquote></div><br clear="all"><div><br></div>-- <br><div dir="ltr" class="m_-4170695004120629679gmail-m_-8015843908585885772gmail-m_-2901768437186909954gmail-m_-5299837530719434673m_-3759804047643035218gmail_signature"><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div>What most experimenters take for granted before they begin their experiments is infinitely more interesting than any results to which their experiments lead.<br>-- Norbert Wiener</div><div><br></div><div><a href="http://www.cse.buffalo.edu/~knepley/" target="_blank">https://www.cse.buffalo.edu/~knepley/</a><br></div></div></div></div></div></div></div></div>
</blockquote></div></div>
</blockquote></div><br clear="all"><div><br></div>-- <br><div dir="ltr" class="m_-4170695004120629679gmail-m_-8015843908585885772gmail-m_-2901768437186909954gmail_signature"><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div>What most experimenters take for granted before they begin their experiments is infinitely more interesting than any results to which their experiments lead.<br>-- Norbert Wiener</div><div><br></div><div><a href="http://www.cse.buffalo.edu/~knepley/" target="_blank">https://www.cse.buffalo.edu/~knepley/</a><br></div></div></div></div></div></div></div></div>
</blockquote></div></div></div></div>
</blockquote></div></div></div>