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

[Patrick Sanan]

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/10398849/attachment-0001.html>