Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Why do we tag nodes with .vtp files? #42

Open
mrp089 opened this issue Aug 4, 2021 · 3 comments
Open

Why do we tag nodes with .vtp files? #42

mrp089 opened this issue Aug 4, 2021 · 3 comments
Labels
enhancement New feature or request

Comments

@mrp089
Copy link
Member

mrp089 commented Aug 4, 2021

Rant triggered by #41

Why do we have to supply .vtp meshes that contain the exact same nodes as the volume mesh? Shouldn't it be sufficient if I supply a volume mesh and a list of nodes where I want to apply BCs (i.e. like any other FE code)?

It's super easy to export lists of nodes in meshing tools. Now, I have to write additional code to extract surfaces (lines, points) that contain no additional information, save them as individual files, and later individually import them again. (I know svSolver does the same but that doesn't make it a good solution.) This can cause a bunch of problems:

  • code necessary to generate .vtps from the volume mesh
  • code necessary to read .vtps from the volume mesh and stitch everything back together
  • you need to keep track of a bunch of files
  • visualizing BCs is anoying
  • can't handle points, line? (see BCs on lines #41)
  • vtkPolyData can't natively handle quadratic meshes

Wouldn't a better solution be to tag nodes directly in the volume mesh:
bcs

Would love to hear your thoughts on this, @vvedula22 @ktbolt

@mrp089 mrp089 added the enhancement New feature or request label Aug 4, 2021
@ktbolt
Copy link
Contributor

ktbolt commented Aug 4, 2021

@mrp089 The GlobalNodeID data array is used to match nodal coordinates for BCs and for coupling FSI computations. This has caused problems in the past in the SV meshing code that needs to generate consistent node IDs for boundary layer meshing.

Most FE commercial codes I've seen use node and element IDs for setting BCs. I think the real problem is that the solvers use both a .vtp and .vtu file to setup BCs and such, not sure why.

However, it would be easy enough to just hash nodal coordinates to get a node ID if you can assume all IDs start from 0 or 1.

@vvedula22
Copy link
Contributor

@mrp089 svFSI allows you to import meshes and faces in multiple formats. The vtu/vtp system is one of them so that it is compatible with SimVascular generated meshes. The reason why we extract vtp's is to enable easier visualization of boundary conditions in Paraview, e.g., see bct.vtp file. But the only piece of information used is GlobalElementID. This refers to tagging elements in the volumetric mesh where you would like to apply BCs. Usually, people use SimVascular to extract these vtp files. You may start with @ktbolt's python scripts for model to mesh conversion.

An alternate approach is to import mesh using coordinates and connectivity, and set boundary conditions using ebc files. svFSI can compute GlobalNodeID internally but requires GlobalElementID as input via ebc file as described here. The mesh is then imported as set of coordinates and connectivity in ASCII formatted files.

You cannot set boundary conditions on point or lines (in 3D) but a single element is possible or a patch of elements is possible. You just have to tag them as separate faces either using a vtp file or using ebc format. As we use elements to set BCs, setting them on higher-order meshes is straightforward. You may use the Fortran code I shared earlier.

@andre-mourato-61459
Copy link

Hello! I'm having troubles correctly creating the ebc files. Do you know if there is any example i can follow? I've search for it but i wasn't able to find any

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

4 participants