Ah the motivation in my case is for strongly enforcing dirichlet boundary conditions. Storing the node-id associated with a dirichlet node allows me to manipulate the necessary data as a post-processing step and without the dof-number, this would be pretty hard. I understand that the implementation then becomes specific to Lagrange or some other nodal basis as a result of this but currently, for the problem of interest, that would be enough for me.
>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. There are dofs associated with the nodes and there are dofs associated with the elements based on the chosen basis. And so I do not understand the requirement to specify a non-zero component number for a nodal dof ! I am interested to know if there is an alternate way to get the information which might be the libmesh way to do it. If not, that is fine though and I'll find some other way to enforce my dirichlet conditions. Thanks, Vijay On Tue, Jun 1, 2010 at 2:52 PM, Roy Stogner <royst...@ices.utexas.edu> wrote: > > On Tue, 1 Jun 2010, Vijay S. Mahadevan wrote: > >>> Yes. We're using C-like semantics here, where if you want to access >>> the 0th index in an array then the array should be at least length 1. >> >> Roy, I agree. But if I did want to know the dof_number associated with >> the a certain variable at a node (nodal dof) that does not have any >> components associated with it, then what do I specify for the third >> argument. This was my dilemma and since it's an unsigned int, I wasn't >> sure what else to specify. Or am I going about finding the dof_number >> for the node wrongly ? > > If there aren't any components associated with a variable at a node, > then there doesn't exist a dof_number for that variable at that node. > If you're solving Q2/Q1 velocity-pressure, for instance, you need > HEX27 elements to give you enough velocity nodes, but the pressure > DoFs are only located on vertex nodes; to get the pressure value on > any other node you have to interpolate. > > Which isn't a bad idea in general. My own prejudice is that if > application code uses DofObject::dof_number directly then it's > probably doing something wrong, typically by making itself > incompatible with non-LAGRANGE elements. > --- > Roy > ------------------------------------------------------------------------------ _______________________________________________ Libmesh-devel mailing list Libmesh-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/libmesh-devel
