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

[Dave May]

I'd advocate flattening everything as a scalar field. Why?
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
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)
3) It will work for case 2 and case 3

On Thu, 28 Mar 2019 at 17:13, Patrick Sanan <patrick.sanan at gmail.com> wrote:

>
>
> Am Do., 28. März 2019 um 09:10 Uhr schrieb Patrick Sanan <
> patrick.sanan at gmail.com>:
>
>> 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.
>>
> PetscField isn't a thing - I meant the various PetscSection*Field*()
> functions.
>
>>
>> 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/0dcabe17/attachment.html>