Inlet Velocity Profile BC - Floating Point exception during solution initialization
I´ve encountered a very weird problem during the implementation of a field function to describe an inlet velocity problem. I wish to use a velocity profil as inlet bc in this form: v = [k(zref)*(z/zref)^n , 0 , 0]
I´ve defined a vector field function in this form:
Function Name: Velocity Profile
Definition: [30 * pow(($$Position/15),0.22), 0 , 0]
Then I´ve defined a local coordinate system for my simulation case, called cartesian 1. For the initial conditions and the inlet bc i selected for the velocity nodes for the coordinate System "Laboratory->Cartesian 1" and for the method "Field Function" and so on...
Once I try to initialize the simulation I get following error:
A floating point exception has occured: floating point exception [invalid operation]. The specific cause cannot be identified. "
Can anyone imagine what the problem could be?
Have you experimented with simplifying your field function ( to something like [$$Position, 0 , 0] ) and see if that resolves the issue. I know that doesn't fix your problem, but it may help you to track down the bug.
Thanks for your answer and your tip ryan.
Okay now things becomes really strange. The simplified vectorfunction [$$Position, 0 , 0] operates also a more complicated function like [30*($$Position/15), 0, 0] operates too. It does not work with an exponential syntax like pow(($$Position/15),0.22)...
I am I correct that the expression pow($x,$y) is the syntax I´ve to use if i want to raise x to the power of y? :confused:
Edit: Okay I think I´ve isolated the problem:
It seems that CCM+ does not accept decimal digits for the exponent n in the expression pow($x,n)...
So in my case the exponent n=0.22 is not accepted by CCM+. I checked it with n=1,5 ; 2,5 and so, same errors. When I change the exponent to 1, 2, 3 and so on, no problem occures and he intializes the solution correctly without errors.
Anyone knows the reason for this and how I can fix it?
huh! this was so weird I just had to mess with it myself...
From my experimenting, it looks like pow doesn't accept entries to raise a number to a value less than 1. Is this what you see?
Not sure why that would be the case (you should send an email to the CD-adapco support poeple). Maybe as a work around you could create a table and use that to set you boundary values instead...?
Actually it won´t work with any decimal digit. For example try to use 1.5 or 2.4 for the exponent, it won´t work either.
I will contact the CD-Adapco support. The idea with the table as a workaround is good idea, thanks for your help Ryan.
|All times are GMT -4. The time now is 23:10.|