markcmiller86
commented
1 year ago We were just having a dialog about this in email within the last couple of weeks and I've completed preliminary changes to support that. But, there are other issues with displaying the result on a "curve" mesh (which is what the revolved_volume expression would have to do) because we currently treat curves specially in VisIt and, in particular, they do not support zone-centered values (#18602) wold have to be addressed first because revolved_volume is generate a value per line-segement, not per-node.
Other notes from our email discussion...
Oh, right...a mix of 2D and 1D elements would likely yield non-sensical results. I hadn’t thought of that case.
BTW...I notice we have Revolve operator, Revolved volume Query and revolved_volume expression which I don’t think share any code.
Regarding broader observation of expression details documentation...I agree.
When I made a pass for tensor expressions, it was quite a bit of work to fully unravel everything they do and how they do it, etc. In addition, I added several opportunities for user to expand documentation to show actual lines of code so they have complete access to the numerics involved in a given tensor expression. It was quite a bit of work to research all of that and document it (and add good tests for it too) ;)
Mark
"Brugger, Eric" wrote:
Hi Mark,
The behavior you describe definitely makes sense, my question is more about whether it is correct for the revolved_volume expression. The revolved volume expression defines a revolved volume for every zone in the mesh, so the revolved volume for each line segment would be revolved volume enclosed by that line segment. If the mesh was a curve or only contained line segments that would be fine behavior. What about if the mesh had both line segments and quads, does that still make sense? The answer may be yes, but we should ask the question in terms of what folks would expect and I don’t know necessarily know the answer. I think another perfectly logical interpretation would be a line segment gives a truncated cone surface, which has zero volume since it is a surface. I guess I’m thinking of a mesh with quads and hexes and what a volume query would return.
I tried the expression with the ucd_lines2d.silo database and it gave zero for all the lines, so that is at least what the current implementation does.
What ever we decide is correct, we should definitely describe it in the documentation. Too many of our expression descriptions are quite vague when the underlying implementation is quite complex.
Eric
From: Miller, Mark C.
Hmmm....I don’t think we’re talking about the same thing.
If I have a semicircle “curve”, for example, and revolve it about the X axis, I get a sphere and I can talk about the volume of that sphere and/or its surface area.
The revolved_volume expression can compute the volume of that rotated contour curve by treating each line segment as a quad with two ends projected onto the axis of revolution defining four points. Those quads, when revolved, create volumes.
Am I missing something?
Mark
"Brugger, Eric" wrote:
Hi Mark,
If the contour forms a closed surface when revolved, it will calculate the surface area of the closed surface. When the line segments get revolved they would create a bunch of quads. When you compute the “volume” you would get an area. The only way you would get a volume is if the revolve operator generated volume elements such as hexahedra, which is what you get when you revolve quads.
Eric
From: Miller, Mark C.
well, if the contour intersects the axis of revolution (or the user was fine with “capping” the contour at either end so that it does), then it could also compute a volume, couldn’t it?
"Harrison, Cyrus D." wrote:
That would be revolved surface area – not volume?
From: "Miller, Mark C."
Ah, ok. Thanks for that. That is kinda what I was thinking.
After looking at the code for revolve_volume expr and comparing to Revolve operator, I notice that the operator supports VTK_LINE type cells whereas the expr does not. I am thinking the expr could easily support VTK_LINE type cells in which case, it could probably easily be used to compute revolved_volume of a curve or other 2D contour.
Thoughts?
Mark
"Harrison, Cyrus D." wrote:
Hi Mark,
The revolved volume expr will look for the AVT_RZ, or AVT_ZR meta data info and use that along with the proper area calculate to compute the volume.
You can think of it as, per element calculate the revolved volume of a solid from the axis to “top edge” of the element, and then subtracting the revolved volume of a solid from the axis to “bottom edge” of the element.
It doesn’t have to chop things up like the revolve operator does, since revolved operator creates discrete geometry.
From: "Miller, Mark C."
Sorry, I mean revolved_volume EXPRESSION.
Mark
"Miller, Mark C." wrote:
Anyone know what kind of assumptions revolved volume operator makes?
I have a curve file and I wanted to know the revolved volume of the area under the curve. I tried this but VisIt threw an exception. Now I have to abandon the curve file and make an actual 2D file that contains quads/triangles.
Enhance the RevolvedVolume query to make VisIt create quads/triangles from the curve line segments (down to axis of revolution) and compute the revolved volume.