On Wed, 9 Mar 2011, Roman Vetter wrote:
>> Looking over this... would it make sense to interpolate instead when
>> we find nodes with missing Lagrange DoFs, to get an isoparametric
>> result? VTK supports second order elements, and first order data is a
>> subset of second order data, so we coul
> Looking over this... would it make sense to interpolate instead when
> we find nodes with missing Lagrange DoFs, to get an isoparametric
> result? VTK supports second order elements, and first order data is a
> subset of second order data, so we could still naturally represent it
> on those elem
On Thu, 3 Mar 2011, Roman Vetter wrote:
> Judging from the latest VTK file format specification (4.2) apparently
> existing on the web, mixed-number-of-component entities seem
> unsupported. A field can be scalar or vectorial, but has a fixed
> number of components for all nodes/elements either w
> There's another test where we die with an error: mixed-order elements.
> E.g. ex11 with VTKIO dies screaming as soon as VTKIO::solution_to_vtk
> hits a side node on a QUAD9, when it expects to see two velocity
> components plus one pressure component but it only sees one pressure
> component. I
On Mon, 28 Feb 2011, Roy Stogner wrote:
> Works on the initial tests where it's expected to work, anyway. Does
> the newest VTK support triquadratic hexes yet? vtk_io.C seems to
> think that VTK_BIQUADRATIC_QUAD is relatively new, and it would be
> nice if we didn't have to die with an error in
On Thu, 24 Feb 2011, Roman Vetter wrote:
>>> There is a third possibility, which is a compromise:
>>> In the case of higher order variables, one could write each component
>>> separately as scalar variables, perhaps with a suffix in the name
>>> denoting the component. This way, all information
>> There is a third possibility, which is a compromise:
>> In the case of higher order variables, one could write each component
>> separately as scalar variables, perhaps with a suffix in the name
>> denoting the component. This way, all information is written, while
>> Paraview will still be able
On Wed, 23 Feb 2011, Roman Vetter wrote:
> I suppose it's a matter of opinion/objective. Do the libMesh
> developers/users want their solution output either
>
> a) complete, including higher order terms, in a way that complies with
> the VTK file format, but not necessarily perfectly visualizable
2011/2/22, Roy Stogner :
>
>>> Does VTK have native support for higher-order data? If so, adding
>>> that to our VTKIO output would be fantastic.
>>
>> Yes, VTK does, but it's not implemented in VTKIO. I attached a patch
>> that does it. :-)
>
> Does it, but how well? It looks like the higher ord
>> Does VTK have native support for higher-order data? If so, adding
>> that to our VTKIO output would be fantastic.
>
> Yes, VTK does, but it's not implemented in VTKIO. I attached a patch
> that does it. :-)
Does it, but how well? It looks like the higher order coefficients
are getting added
>> Patch didn't apply cleanly for me (submit as an attachment next time?
>> my email system must have mangled the whitespace or something) but it
>> looks simple enough to apply by hand.
Sorry about that. I'll attach patches as files in the future.
>
> And I'm glad I looked at it more closely - s
On Mon, 21 Feb 2011, Roy Stogner wrote:
> Patch didn't apply cleanly for me (submit as an attachment next time?
> my email system must have mangled the whitespace or something) but it
> looks simple enough to apply by hand.
And I'm glad I looked at it more closely - shouldn't we also be using
v
On Mon, 21 Feb 2011, Roman Vetter wrote:
>> EquationSystems::allgather() is actually a second step up in
>> sophistication from where VTK output is - it gathers geometry data and
>> degree of freedom numbering in the case of a distributed mesh. The
>> gathering (and sadly, the decimation of high
> EquationSystems::allgather() is actually a second step up in
> sophistication from where VTK output is - it gathers geometry data and
> degree of freedom numbering in the case of a distributed mesh. The
> gathering (and sadly, the decimation of higher-order solutions) of
> vector data happens in
On Wed, 9 Feb 2011, Vetter Roman wrote:
> VTK output crashes when run in parallel (mpirun -n 2 ...). The following
> assertion fails:
>
> Assertion `it!=_global_to_local_map.end()' failed.
> [...]/libmesh/include/numerics/petsc_vector.h, line 1073, [...]
Yup - the VTK support was a contribution
Dear libmesh developers
VTK output crashes when run in parallel (mpirun -n 2 ...). The following
assertion fails:
Assertion `it!=_global_to_local_map.end()' failed.
[...]/libmesh/include/numerics/petsc_vector.h, line 1073, [...]
The problem is reproducible with the following minimal working exa
16 matches
Mail list logo
