To the best of my knowledge, the current version of tripcolor (and by extension tricontour and tricontourf) requires a function call of the following form:
tripcolor(x,y,triangles,z)
where "z" is a vector that is of the same length as "x" and "y". In other words, "z" represents a function that lives at the nodes of the triangular mesh. Then, when the function is actually plotted, a color value is assigned to the triangle in the mesh by arithmetically averaging the values on the 3 nodes that make up the current triangle.
If one is plotting a function that is truly node-centered, this is probably fine. However, if one has an element-based function, it would be much preferable if tripcolor would allow an input "z" that is of the length of "triangles" rather than "x" and "y". Then the color value for the triangle can directly come from "z" instead of from arithmetically averaging of node values.
To the best of my knowledge, the current version of tripcolor (and by extension tricontour and tricontourf) requires a function call of the following form:
where "z" is a vector that is of the same length as "x" and "y". In other words, "z" represents a function that lives at the nodes of the triangular mesh. Then, when the function is actually plotted, a color value is assigned to the triangle in the mesh by arithmetically averaging the values on the 3 nodes that make up the current triangle.
If one is plotting a function that is truly node-centered, this is probably fine. However, if one has an element-based function, it would be much preferable if tripcolor would allow an input "z" that is of the length of "triangles" rather than "x" and "y". Then the color value for the triangle can directly come from "z" instead of from arithmetically averaging of node values.