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.
Problems with defining inlet velocity profile (undefined value found)
Posted Mar 1, 2012, 6:11 a.m. EST 7 Replies
Please login with a confirmed email address before reporting spam
Good Day,
I'm running into troubles trying to apply a defined variable onto a surface boundary.
I'm running a Turbulence k-epsilon model and defined the inlet normal velocity as U_profile (with r and h as variables in it).
U_profile: I*(1-exp(-nu_Ga*Ha*t/h^2))/(4*pi*r*sqrt(sigma_Ga*rho_Ga*nu_Ga))
I, nu_Ga, Ha, sigma_Ga, rho_Ga are all constants.
r is defined as sqrt(x^2+y^2) and h is defined as z.
As the inlet velocity profile isn't uniform, I'm thinking of defining the equation such that velocity varies with height and radius of the duct. Once I began the calculations however, Comsol returns an error message
"Undefined value found in the constraint residual vector: NaN or Inf in vector."
i began debugging it and found that it can't recognize r and h as variable in Cartesian coordinate. Is there any known way to allow such variation in calculation to proceed? I'm new to COMSOL, is there any rules regarding the use of x,y, and z as variables itself?
Thanks in advance...
I'm running into troubles trying to apply a defined variable onto a surface boundary.
I'm running a Turbulence k-epsilon model and defined the inlet normal velocity as U_profile (with r and h as variables in it).
U_profile: I*(1-exp(-nu_Ga*Ha*t/h^2))/(4*pi*r*sqrt(sigma_Ga*rho_Ga*nu_Ga))
I, nu_Ga, Ha, sigma_Ga, rho_Ga are all constants.
r is defined as sqrt(x^2+y^2) and h is defined as z.
As the inlet velocity profile isn't uniform, I'm thinking of defining the equation such that velocity varies with height and radius of the duct. Once I began the calculations however, Comsol returns an error message
"Undefined value found in the constraint residual vector: NaN or Inf in vector."
i began debugging it and found that it can't recognize r and h as variable in Cartesian coordinate. Is there any known way to allow such variation in calculation to proceed? I'm new to COMSOL, is there any rules regarding the use of x,y, and z as variables itself?
Thanks in advance...
7 Replies Last Post Mar 3, 2012, 5:20 a.m. EST
Please login with a confirmed email address before reporting spam
Posted:
1 decade ago
Hi
I suspect a naming error, as "h" is already used by COMSOL for the average mesh size. You should try to keep clear of short variable names. And COMSOL does not flag most naming conflicts, as it allows us to tweak the internal variables, with the side effect that sometimes we get some confusions and bizarre results ;)
Hope this is the issue, try it out with a my_h instead of "h"
--
Good luck
Ivar
I suspect a naming error, as "h" is already used by COMSOL for the average mesh size. You should try to keep clear of short variable names. And COMSOL does not flag most naming conflicts, as it allows us to tweak the internal variables, with the side effect that sometimes we get some confusions and bizarre results ;)
Hope this is the issue, try it out with a my_h instead of "h"
--
Good luck
Ivar
Please login with a confirmed email address before reporting spam
Posted:
1 decade ago
Hi,
Thanks for your suggestion! I've tried replacing "h" with a number(length) instead and the model runs fine. Turns out the problem lies with defining/including z as a variable in U_profile. I've further ran some tests, I found that the problem lies with the relationship between "t" and "z".
I ran some test with similarly drawn model but defining U_profile as 20[m/s]*r/z, I found that Cartesian coordinate z can't go well with time, "t". Any form of "t" present along with z with return the "undefined value found" error. However, under certain conditions if "z" is made such that it is dimensionless (10^z, for example), the problem is gone. Making "d_h = z/1[m]*1[m]" won't work however.
The problem is now between "z" and "t". Is there any workaround to replace "z"? Is "z" simply the Cartesian coordinate in z-direction or it has some other formulation?
I'll keep on trying for solutions but your advice will help me a lot. Thanks...
Thanks for your suggestion! I've tried replacing "h" with a number(length) instead and the model runs fine. Turns out the problem lies with defining/including z as a variable in U_profile. I've further ran some tests, I found that the problem lies with the relationship between "t" and "z".
I ran some test with similarly drawn model but defining U_profile as 20[m/s]*r/z, I found that Cartesian coordinate z can't go well with time, "t". Any form of "t" present along with z with return the "undefined value found" error. However, under certain conditions if "z" is made such that it is dimensionless (10^z, for example), the problem is gone. Making "d_h = z/1[m]*1[m]" won't work however.
The problem is now between "z" and "t". Is there any workaround to replace "z"? Is "z" simply the Cartesian coordinate in z-direction or it has some other formulation?
I'll keep on trying for solutions but your advice will help me a lot. Thanks...
Please login with a confirmed email address before reporting spam
Posted:
1 decade ago
Hi
What you havent clearly said yet is that "t" is time and you are using a simple SPF in turbulent mode and transient solver ?
if not, i.e you have FSI or an ALE in your model it could be that you should use "Z" and not "z" to be in the material frame as Z is independent of time z might not be, all depends on the boundary. But in simple SPF this is not differentiated and you have only lower case "z".
Or it's not that your z=0 somewhere along the boundary then you get a NaN with your 1/z
--
Good luck
Ivar
What you havent clearly said yet is that "t" is time and you are using a simple SPF in turbulent mode and transient solver ?
if not, i.e you have FSI or an ALE in your model it could be that you should use "Z" and not "z" to be in the material frame as Z is independent of time z might not be, all depends on the boundary. But in simple SPF this is not differentiated and you have only lower case "z".
Or it's not that your z=0 somewhere along the boundary then you get a NaN with your 1/z
--
Good luck
Ivar
Please login with a confirmed email address before reporting spam
Posted:
1 decade ago
Hello,
Thanks for pointing out all the possibilities. Yes indeed that I'm using SPF and a transient solver. The model works perfectly now.
I do have a question though, if "z" can't be a 0 at all times (since my function has a "1/z" in it), the best solution I can come up with is to "shift" the drawn model up (maybe around 0.001m, so that the bottom boundary doesn't reach zero). This seems a very crude way of solving the problem, is there a better way in COMSOL to do such calculations? Does COMSOL allow user to state a condition where z>0?
Thanks again for your advices, it's been really helpful.
Thanks for pointing out all the possibilities. Yes indeed that I'm using SPF and a transient solver. The model works perfectly now.
I do have a question though, if "z" can't be a 0 at all times (since my function has a "1/z" in it), the best solution I can come up with is to "shift" the drawn model up (maybe around 0.001m, so that the bottom boundary doesn't reach zero). This seems a very crude way of solving the problem, is there a better way in COMSOL to do such calculations? Does COMSOL allow user to state a condition where z>0?
Thanks again for your advices, it's been really helpful.
Please login with a confirmed email address before reporting spam
Posted:
1 decade ago
Hi
I wounder if its not that you formula should have a an offset in it (which is equivalent to shifting the the geometry, and/or that the hypothesis is not valid for t=0 but t>t0 with some t0>0
--
Good luck
Ivar
I wounder if its not that you formula should have a an offset in it (which is equivalent to shifting the the geometry, and/or that the hypothesis is not valid for t=0 but t>t0 with some t0>0
--
Good luck
Ivar
Please login with a confirmed email address before reporting spam
Posted:
1 decade ago
hi,
I've ran some test on both conditions (setting t=0 to see if it encounters problem, and also with the offset for z). The model didn't encounter problems for the first case probably because exp(0) is a valid number, whereas having z=0 would mean a division by zero (as you mentioned before).
thus, I redefined the z as such:
Name: DH--------> Expression: if(z==0,0.00000001,z)[m]
so that if z=0, it would take 0.00000001m as the first value. I hope I got the expression and the "if" operator right...
Another question came into mind. Since for my geometry, the bottom wall of the duct lies at z=0, once i offset the z up away from the bottom boundary, will the wall function still apply right after the bottom boundary at the start of the duct?
Picture description:
The highlighted rectangle is the applied inlet where my previously defined U_profile is placed. The bottom line of the highlighted boundary is z=0.
Thanks for all your help in this.
I've ran some test on both conditions (setting t=0 to see if it encounters problem, and also with the offset for z). The model didn't encounter problems for the first case probably because exp(0) is a valid number, whereas having z=0 would mean a division by zero (as you mentioned before).
thus, I redefined the z as such:
Name: DH--------> Expression: if(z==0,0.00000001,z)[m]
so that if z=0, it would take 0.00000001m as the first value. I hope I got the expression and the "if" operator right...
Another question came into mind. Since for my geometry, the bottom wall of the duct lies at z=0, once i offset the z up away from the bottom boundary, will the wall function still apply right after the bottom boundary at the start of the duct?
Picture description:
The highlighted rectangle is the applied inlet where my previously defined U_profile is placed. The bottom line of the highlighted boundary is z=0.
Thanks for all your help in this.
Attachments:
Please login with a confirmed email address before reporting spam
Posted:
1 decade ago
Hi
for "small" values you can also consider "eps" the smallest real number the binary system of your PC mathc processor can distinguis from "1"
Still I do not understand your original equation "U_profile" as it contains a NaN, that cannot be physical, there must be another hypothesis we have missed that is setting back the formula to all real numbers ;)
--
Good luck
Ivar
for "small" values you can also consider "eps" the smallest real number the binary system of your PC mathc processor can distinguis from "1"
Still I do not understand your original equation "U_profile" as it contains a NaN, that cannot be physical, there must be another hypothesis we have missed that is setting back the formula to all real numbers ;)
--
Good luck
Ivar