1

Topic: Boundary condition vtk export

I would like to open a discussion on this topic.

The export of boundary conditions to vtk is on my todo list for a long time, however, I am still not sure about the best way how to do it.
At least, it would be nice is to have the possibility to highlight the entities (nodes, element sides, etc) subjected to a specific boundary-condition.
At present, I am thinking about the following:
- export a new geometry, containing all nodes, element edges, surfaces, and element cells - basically all the entities, on which BC can be applied,
- attach with this dataset a scalar array, where the i-th value (equal to 1, or nonzero) will indicate applied i-th Boundary condition, zero value means i-th BC not applied,
- then the user can display the entities using threshold filter, by filtering only entities with nonzero value.

There is a small issue when the BC numbering will not be continuous and arbitrary, but at present the arbitrary component numbering is not supported for BCs, only for nodes and elements.

Any ideas or comments?

Re: Boundary condition vtk export

Similar to this, I've thought about exporting reaction forces
This would fit well with the current VTU-output, by simple adding a new export option, e.g. "reactions" which are associated with an UnknownType.
For example,
"primvars 1 1 reactions 1 1"
to export DisplacementVector and the reaction forces acting on DisplacementVector (as a vector).
(this feature has been requested several times).
Something very similar could be done to export the external forces as well (conveniently separated into each unknown type)

It should be fairly simple to implement, and very general (should work for all types of problems)

Of course, this will not highlight different boundary conditions in the way proposed, especially if the reaction forces happens to be zero, but it would be much easier to add into the current VTU export module.

3

Re: Boundary condition vtk export

I have spent a few hours googling and it seems, that one dataset containing cells ans well as boundary cells (edges, surfaces) can cause a problem during visualization (result depending on the order of entities, as they basically overlap).
So the solution would be to have another dataset, containing points and boundary entities in addition to the existing dataset with points and cells. By having two datasets, one can control independently the aplha value of each to get desired result.  Then for each boundary condition, one can export  scalar or vector data on points or cells in both datasets, depending on BC type. In this way, it will be possible to show BCs (and their values) on nodes, boundary edges (or surfaces) and cells.

Possible disadvantages:
- two independent datasets, switching to particular BC has to be made in both, so there is a danger of seeing incompatile data.
- need to open two datasets

Re: Boundary condition vtk export

Slightly off-topic, but again, related to this:
I have had the idea of reforming the way boundary conditions are applied (as we have discussed before).
One could construct a "set" of objects, like, nodesets, dofsets, edgesets, boundarysets, elementsets, etc. and then apply boundary conditions to each of the sets, rather than directly on elements/nodes/dofs.
I already use these sort of sets internally for my Active Boundary Conditions ( see MixedGradientPressureNeumann ).
Something like object-sets could unify the approach to applying boundary conditions, and possible help with adaptivity (e.g. an element surface is part of a certain set, any new surface nodes during refinement would also be part of that set) and visualization.

But that still doesn't help with the limitations of VTU files (e.g. all elements must have a complete set of all data, which makes this sort of export very impractical)

5

Re: Boundary condition vtk export

yes, there are two "dual" approaches, on how to specify boundary conditions: one possibility is to keep a list of applied boundary conditions on every component  (the current approach in oofem) or keep a list of components to which particular BC is applied to for every BC. Both approaches can be advantageous in some cases. In fact we could easily enable both approaches, so that the load vectors, for example, can be assembled from nodal and element contributions, but also from BC contributions.
The idea of having independent sets, that allow to assign various BCs to different components (or components satisfying given condition) is interesting. They can be specified  on input (they can be maintained by domain class) and could provide the iterators, that can loop over the components in the set and perform given action (determined by a functor class passed as a parameter to iterator).

Re: Boundary condition vtk export

I use the second approach in my active boundary condition (MixedGradientPressureNeumann).  It keeps a list of element boundaries, and I could in fact not do this any other way, since the boundary condition itself introduces some additional unknowns (lagrange multipliers).