[petsc-dev] DMDA VTK viewer regression: field names missing

[Patrick Sanan]

Agreed that
- these viewers should prioritize being quick and viewable with as little
post-processing as possible
- this change is bad in throwing away the field name metadata

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
1. a single scalar field
2. multiple scalar fields (which the user wants to store interlaced, as
opposed to using a DMComposite)
3. a single vector-valued field
4. multiple scalar or vector fields, of arbitrary dimensions (adding up the
total dof of the DMDA), interlaced

Case 4 can be approximated by case 2, as in Jed's initial example.
I believe that the PetscSection / PetscField framework was introduced to
more generally support this, at least for DMPlex.

My PR broke (or at least harmed) case 2, to allow for more-convenient
handling of case 3.
As Jed says, this was motivated by requiring less post-processing to view a
vector field in Paraview,
but it created the need for more post-processing for the
multiple-scalar-field approach.

Options to fix this include
a. Revert to the old behavior
b. Provide options to the user to distinguish between cases 2 and 3
(multiple scalar fields vs vector field)
c. Try to automatically detect which type of output (say, check if any
field names have been set)
d. Investigate supporting case 4 (arbitrary fields of arbitrary dimension)
by using PetscSection
e. (If even possible) Properly name the components of a vector in a VTK file

Before I start poking around, I'm shaky on assessing options d and e!




Am Do., 28. März 2019 um 08:21 Uhr schrieb Dave May via petsc-dev <
petsc-dev at mcs.anl.gov>:

>
>
> On Thu, 28 Mar 2019 at 15:42, Jed Brown via petsc-dev <
> petsc-dev at mcs.anl.gov> wrote:
>
>> Matthew Knepley <knepley at gmail.com> writes:
>>
>> > On Wed, Mar 27, 2019 at 10:56 PM Jed Brown via petsc-dev <
>> > petsc-dev at mcs.anl.gov> wrote:
>> >
>> >> Prior to this PR, which was merged for 3.10
>> >>
>> >>
>> >>
>> https://bitbucket.org/petsc/petsc/pull-requests/1029/dmda-vtk-viewing-output-multiple-dof/diff
>> >>   https://bitbucket.org/petsc/petsc/commits/ea2d7708fa6
>> >>
>> >> we could have files that look like the following, and thus were easy to
>> >> navigate in Paraview and Visit.
>> >>
>> >
>> > Tell me if I am wrong (since I do not run it this way). I think the
>> point
>> > of Patrick's change is a good one, and
>> > necessary to view things with DMStag.
>>
>> Or maybe just necessary to avoid needing to use multiple files or add
>> filters.
>>
>> > What Jed dislikes, rightly, is that some metadata has gone missing.
>> > Does Xdmf allow you to name the components? The way I do this
>> > petsc_gen_xdmf.py is to write the whole thing as Patrick does, but
>> > then create views into the data using the component names. It sound
>> > like this should be doable here.
>>
>> Perhaps.  A key reason for using VTK viewers is that they're relatively
>> quick and foolproof compared to formats that need libraries and/or
>> auxiliary files.
>
>
> I completely agree with the above comment. I consider these files as
> "instant and usable viz".
>
> I'd like both the dm field names and the vec name to be used to define the
> vtk field names.
>
> One idea:
>   vecname_fieldname
> falling back to
>   "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)
> faillng back to
>   "field"%d_%d
> where the last index here is the block index.
>
> 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)
>
> Thanks
> Dave
>
>
>
>
>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mcs.anl.gov/pipermail/petsc-dev/attachments/20190328/772b9039/attachment.html>