Discussion Closed This discussion was created more than 6 months ago and has been closed. To start a new discussion with a link back to this one, click here.
Integration on different expressions of the same surface giving different results
Posted 16 giu 2014, 18:21 GMT-4 Fluid & Heat, Computational Fluid Dynamics (CFD), Geometry, Results & Visualization 3 Replies
Please login with a confirmed email address before reporting spam
Hello,
I am hoping that someone can help me with a problem I am encountering in attempting to measure mass flux in my fluid dynamics simulation. I am getting very strange and different results when integrating on different data sets in my results.
I am trying to measure the mass flux on an arbitrary surface in the interior of my simulation box. I thought that an integral on a parameterized surface would be the best way to do this. I realize that I can redefine the geometry in order to create a new boundary, but I'd prefer to do this in post processing so that I can play around with using different surfaces without recalculating each time.
Integrating on a rectangular parameterized surface in the area of interest gave a result that is orders of magnitude to large. The boundary condition for my inlet is a mass flow rate of -1.07669e-9[kg/s] and integrating v*spf.rho on my surface gave -138.2 kg/s. (Note that I could not figure out how to access the normal to the parameterized surface, but since mine is perpendicular to the y-axis, I just used the y-component of the velocity)
In order to test that I was using the parameterized surface correctly, I decided to use my inlet as a test case, since there I know exactly what the flow should be and I have a surface there already which I can integrate over. Integrating over the inlet surface gives my boundary condition value for mass flux, but creating a parameterized surface in the exact same place gives 1076.3 kg/s, about 10^12 times too big. The factor of 10^12 seems like a units issue, since my geometry is defined in μm and I’m integrating over an area. How do I make this go away? The remaining small discrepancy in value is probably because I used u*spf.rho as my integrand despite the fact that the surface is not quite normal to the x-axis. Is there a way to get the variables for the normal to a parameterized surface? ps1nx, ps1ny, and ps1nz in analogy to a cut plane do not work.
I also tried using a cut plane defined across the inlet. I thought that this should give the same result as the plane only intersects the geometry on that boundary. I defined a general cut plane using 3 points on the inlet and then integrated with integrand (cpl4nx*u+cpl4ny*v+cpl4nz*w)*spf.rho but I got 9.28e-16 kg/s instead of the boundary value.
One more thing I tried was a cut plane in the interior with Booleans in the integrand to restrict the surface. Integration on an xz-plane through my geometry with integrand (cpl1nx*u+cpl1ny*v+cpl1nz*w)*spf.rho gives a value of 2.47e-16 kg/s, again way too low, and adding in Boolean restrictions so that the integrand is (59<x)*(-45<z)*(cpl1nx*u+cpl1ny*v+cpl1nz*w)*spf.rho*(x<84)*(z<5) gives a value of 0! It seems that the (59<x) is the one causing the 0 for some reason since (-45<z)*(cpl1nx*u+cpl1ny*v+cpl1nz*w)*spf.rho*(x<84)*(z<5) gives the same value as with no Booleans, but that just means that the Booleans aren’t working at all. I am now thoroughly confused and would appreciate any help on where these issues are coming from.
Thank you!
Geoffrey
I am hoping that someone can help me with a problem I am encountering in attempting to measure mass flux in my fluid dynamics simulation. I am getting very strange and different results when integrating on different data sets in my results.
I am trying to measure the mass flux on an arbitrary surface in the interior of my simulation box. I thought that an integral on a parameterized surface would be the best way to do this. I realize that I can redefine the geometry in order to create a new boundary, but I'd prefer to do this in post processing so that I can play around with using different surfaces without recalculating each time.
Integrating on a rectangular parameterized surface in the area of interest gave a result that is orders of magnitude to large. The boundary condition for my inlet is a mass flow rate of -1.07669e-9[kg/s] and integrating v*spf.rho on my surface gave -138.2 kg/s. (Note that I could not figure out how to access the normal to the parameterized surface, but since mine is perpendicular to the y-axis, I just used the y-component of the velocity)
In order to test that I was using the parameterized surface correctly, I decided to use my inlet as a test case, since there I know exactly what the flow should be and I have a surface there already which I can integrate over. Integrating over the inlet surface gives my boundary condition value for mass flux, but creating a parameterized surface in the exact same place gives 1076.3 kg/s, about 10^12 times too big. The factor of 10^12 seems like a units issue, since my geometry is defined in μm and I’m integrating over an area. How do I make this go away? The remaining small discrepancy in value is probably because I used u*spf.rho as my integrand despite the fact that the surface is not quite normal to the x-axis. Is there a way to get the variables for the normal to a parameterized surface? ps1nx, ps1ny, and ps1nz in analogy to a cut plane do not work.
I also tried using a cut plane defined across the inlet. I thought that this should give the same result as the plane only intersects the geometry on that boundary. I defined a general cut plane using 3 points on the inlet and then integrated with integrand (cpl4nx*u+cpl4ny*v+cpl4nz*w)*spf.rho but I got 9.28e-16 kg/s instead of the boundary value.
One more thing I tried was a cut plane in the interior with Booleans in the integrand to restrict the surface. Integration on an xz-plane through my geometry with integrand (cpl1nx*u+cpl1ny*v+cpl1nz*w)*spf.rho gives a value of 2.47e-16 kg/s, again way too low, and adding in Boolean restrictions so that the integrand is (59<x)*(-45<z)*(cpl1nx*u+cpl1ny*v+cpl1nz*w)*spf.rho*(x<84)*(z<5) gives a value of 0! It seems that the (59<x) is the one causing the 0 for some reason since (-45<z)*(cpl1nx*u+cpl1ny*v+cpl1nz*w)*spf.rho*(x<84)*(z<5) gives the same value as with no Booleans, but that just means that the Booleans aren’t working at all. I am now thoroughly confused and would appreciate any help on where these issues are coming from.
Thank you!
Geoffrey
3 Replies Last Post 27 giu 2014, 17:51 GMT-4
Please login with a confirmed email address before reporting spam
Posted:
1 decade ago
Hi
You talked about probable units issues, by default, even if your geometry is in [um], the coordinates x,y,z are in SI or [m] by default so "(59<x)" means "True if x smaller than 59[m]", and you might have wanted 59[um], or ?
In which case I would write (59<x[1/um]), as Boolean operator expect unit less values
I do not believe that COMSOL defines a surface normal for a Results - Data Set - "Cut plane" I would have to dig into the doc to check but look at the "advanced" features. But "my way" is mostly to define an internal boundary, then the normal is defined thereon (remains to know or display with a coordinate plot, what is "up" and "down") and you can always use Booleans to restrict the area of interest.
You must check with support if there might be some internal errors in your version, what I doubt, or to update to a more recent one
Check also the blog page www.comsol.eu/blogs/computing-total-normal-flux-planar-surface/
--
Good luck
Ivar
You talked about probable units issues, by default, even if your geometry is in [um], the coordinates x,y,z are in SI or [m] by default so "(59<x)" means "True if x smaller than 59[m]", and you might have wanted 59[um], or ?
In which case I would write (59<x[1/um]), as Boolean operator expect unit less values
I do not believe that COMSOL defines a surface normal for a Results - Data Set - "Cut plane" I would have to dig into the doc to check but look at the "advanced" features. But "my way" is mostly to define an internal boundary, then the normal is defined thereon (remains to know or display with a coordinate plot, what is "up" and "down") and you can always use Booleans to restrict the area of interest.
You must check with support if there might be some internal errors in your version, what I doubt, or to update to a more recent one
Check also the blog page www.comsol.eu/blogs/computing-total-normal-flux-planar-surface/
--
Good luck
Ivar
Please login with a confirmed email address before reporting spam
Posted:
1 decade ago
Hi Ivar,
Thank you for your reply. Adding [1/μm] to the variables in the boolean restrictions for the cut plane gives a syntax error, but I have appended "e-6" to all of the numbers and am now getting 3.05e-16, which still doesn't really make sense, though at least it isn't 0.
COMSOL does indeed let you define a surface normal for cut planes (you will see the instructions on how to do so are in the blog post you linked), and I was hoping that there was a similar option for a parameterized surface, as that is really what I would like to use.
I assume that by "define an internal boundary" you mean create a boundary in your geometry and then run the computation? I realize that this is an option, but I would prefer to define the boundary in post-processing so that I can explore different boundaries easily without having to recompute my solution each time. It seems that this is exactly what the parameterized surface is for, so I do not know why it is not working.
Best,
Geoffrey
Thank you for your reply. Adding [1/μm] to the variables in the boolean restrictions for the cut plane gives a syntax error, but I have appended "e-6" to all of the numbers and am now getting 3.05e-16, which still doesn't really make sense, though at least it isn't 0.
COMSOL does indeed let you define a surface normal for cut planes (you will see the instructions on how to do so are in the blog post you linked), and I was hoping that there was a similar option for a parameterized surface, as that is really what I would like to use.
I assume that by "define an internal boundary" you mean create a boundary in your geometry and then run the computation? I realize that this is an option, but I would prefer to define the boundary in post-processing so that I can explore different boundaries easily without having to recompute my solution each time. It seems that this is exactly what the parameterized surface is for, so I do not know why it is not working.
Best,
Geoffrey
Please login with a confirmed email address before reporting spam
Posted:
1 decade ago
It turns out that the order of magnitude error on the parameterized surface was a bug fixed in the latest update. I thought comsol was up to date, but apparently there was an error with updating. Reinstalling with the latest version fixed the issue.