> This would be an underlying bug. What specifically is a bug there ? I am solving a problem with 1 variable defined in a subdomain and another variable defined in another subdomain (non-overlapping). The first variable uses QUADs with Lagrange basis while the second uses QUADs with Monomials. I am in the process of writing a libmesh-only program and it will help me sort out the issues I'm facing as part of my larger code.
Anyway, would this be a situation where the assert could get triggered wrongly ? If so, let me know what specific behavior I need to look out for. Vijay On Tue, Jun 1, 2010 at 4:15 PM, Roy Stogner <royst...@ices.utexas.edu> wrote: > > On Tue, 1 Jun 2010, Vijay S. Mahadevan wrote: > >> From a user perspective, It is a little annoying that I can never >> access the actual dof_number associated with the unknown at the node >> due to the assert failures. Since all other build versions of the code >> give me the correct dof-number (I've verified this for small meshes), >> I think that the assert triggers a wrong failure for this use-case. > > No, IF the number of components on a node is zero, then asking for the > index of the first component on the node makes no sense. The assert > is correct. > > But if that IF is wrong: > >> There are dofs associated with the nodes and there are dofs associated >> with the elements based on the chosen basis. > > This would be an underlying bug. What elements are you using, with > what bases? Can you put together a test case that replicates the > problem? > --- > Roy > ------------------------------------------------------------------------------ _______________________________________________ Libmesh-devel mailing list Libmesh-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/libmesh-devel
