From: Karen Lee <kylkaren@gm...>  20100311 02:14:51

> If you're not using mesh adaptivity then this is easy, smooth or not  > a number associated with every node of your mesh can be stored on a > degree 1 LAGRANGE basis, or a number associated with every element can > be stored on a degree 0 MONOMIAL basis. > > If you're doing adaptivity then what you can do depends on what you > want associated with new child nodes/elements. > > > I also just wanted to check how to properly put in the RHS which I read >> into MeshData. (I have checked that it read >> in the correct things by outputting it to a file, but not getting the info >> entry by entry.) Is there a function >> analogous like get_xyz that I can use rather than doing the following >> (modified from example 3, and which may not >> even be correct)? >> >> const Real x = q_point[qp](0); >> const Real y = q_point[qp](1); >> const Real z = q_point[qp](2); >> >> Node node(x,y,z,qp); >> >> >> const Real fxy = mesh_data.operator() (node, 0); >> > > I think MeshData indexes by nodes, not by points  i.e. if you create > a new Node at a quadrature point, or even at the same point as an > existing node, MeshData will think you've just handed it a node it > doesn't know about. > I'm a newbie to finite element, and I guess I wasn't very clear how to store the data on a degree 1 LAGRANGE basis in the code... I just tried to give fxy the correct RHS value and do the same thing as example 3. I know that the quadrature points are not the node values... How do I assign the correct values and not have MeshData think I'm giving it a node it doens't know about? (Also, am I using mesh_data,operator() correctly? And is this the function to use?) Would I be better off storing data to be used in the RHS for elements instead of for the nodes instead? I guess I don't know this too well for now, so might need you to spell it out more... Sorry about that. Thanks! Karen 