New nonzero MALLOC error when using periodic boundary on a variable defined in a subdomain

[AlbertoBittes]

I am trying to apply periodic boundary conditions on my computational domain. I have a system with one variable defined in the whole domain and another variable defined in a subdomain. My problem is a quarter of a sphere, generated by revolving a plane mesh. the second variable is defined only in the red elements in the picture:

I apply periodic boundary conditions between the two bounding planes for the first variable, and another periodic boundary condition for the second variable between the red elements:

First variable periodic boundary:

Those nodes connected to the axis are not included to the set that will delimit the sides for the periodic boundary conditions, because they will give invalid periodic boundary.

Second variable periodic boundary:

When I try to add the constrained element matrix to the system matrix:

dof_map.constrain_element_matrix(Ke, dof_indices_buf); matrix.add_matrix(Ke, dof_indices_buf);

I get the following error:

[0]PETSC ERROR: Argument out of range [0]PETSC ERROR: New nonzero at (483,1287) caused a malloc

This happens when I try to add the element matrix of the element selected in the first paraview screenshot. This does not happen if I apply the periodic boundary only on the first variable. Are periodic boundaries supported for variables in subdomains? Can I someway fix this with a supplementary ghosting functor, or am I forced to define the variable in the whole domain and then exclude it via restrict_solve?

[jwpeterson]

This is a pretty common issue, and we have a mechanism, GhostingFunctor, which can be customized by the user to expand the sparsity pattern so that it includes non-physically-adjacent neighbors. You can see an example of how this is intended to work in miscellaneous/miscellaneous_ex9.

But, your question raises another one: what version of PETSc are you using? If you are using a new enough PETSc (>=3.23?), I think you might be able to use the

  matrix.use_hash_table(true);

flag to have PETSc internally use its "hash table" approach while building the sparse matrix, which does not require preallocation and should fix the "New nonzero at" error that you see currently.

[AlbertoBittes]

Thank you, yes as I mentioned maybe a ghosting functor works but I was wondering whether I was using in a wrong way the periodic boundaries already implemented in libMesh.

If possible, I would ask a further question related to this: I think that the periodic boundaries of libMesh are exclusively used for LAGRANGE elements, is there some additional option for NEDELEC or RAVIART elements?

[roystgnr]

Periodic boundaries are not exclusive to LAGRANGE; personally I used them most for HERMITE. If your periodic boundary only maps points via a translation then it should be fine for vector-valued elements as well, but I wouldn't expect them to be supported by periodic boundaries where the pairing of sides includes any kind of scaling or rotation.