# Dynamic Contact Angle Definition (dynamicAlphaContactAngle)

 Register Blogs Members List Search Today's Posts Mark Forums Read

 May 22, 2020, 10:45 Dynamic Contact Angle Definition (dynamicAlphaContactAngle) #1 New Member   Mike Worth Join Date: Apr 2020 Posts: 7 Rep Power: 2 I'm trying to use a dynamicAlphaContactAngle boundary to 'pin' a contact point at the furthest that it reaches during advancement. As far as I understand dynamic contact angles this should work if the receding contact angle is zero, with a non-zero advancing contact angle. I've tried setting this up to no avail, and having looked into the code it doesn't seem to do what I'd expect. The contact angle returned seems to be calcuated as: theta0_ + (thetaA_ - thetaR_)*tanh(uwall/uTheta_) At low velocity (uwall<

 May 26, 2020, 05:34 #2 New Member   Mike Worth Join Date: Apr 2020 Posts: 7 Rep Power: 2 I've looked closer, and as far as I can tell the code for dynamicAlphaContactAngle doesn't behave at all as expected. At high velocity in either direction it doesn't tend towards the advancing or receding contact angle. I don't think that there is a standard theory for exactly how to transition between advancing and receding angles (there doesn't seem to be anything in my textbook). Reusing the tanh approach, I think that this calculation gives results much more in line with what I'd expect: Code: ``` u_ratio=uWall/uTheta t=tanh(u_ratio) if u_ratio >= 0: return (1-t)*theta0 + t*thetaA else: return (1+t)*theta0 + -t*thetaR``` As shown against the original in this plot: Unless anyone has an explanation I'll register this as a bug. Just having a bit of trouble with verifying my account on gitlab... And here is the implementation of my modified calculation: Code: ```Foam::tmp Foam::dynamicAlphaContactAngleFvPatchScalarField::theta ( const fvPatchVectorField& Up, const fvsPatchVectorField& nHat ) const { if (uTheta_ < SMALL) { return tmp::New(size(), theta0_); } const vectorField nf(patch().nf()); // Calculated the component of the velocity parallel to the wall vectorField Uwall(Up.patchInternalField() - Up); Uwall -= (nf & Uwall)*nf; // Find the direction of the interface parallel to the wall vectorField nWall(nHat - (nf & nHat)*nf); // Normalise nWall nWall /= (mag(nWall) + SMALL); // Calculate Uwall resolved normal to the interface parallel to // the interface scalarField uwall(nWall & Uwall); Info << "USING MIKE WORTHS MODIFIED DYNAMIC CONTACT ANGLE CALCULATION\n"; //Calculation will likely give nonsense without warning if values do not satisfy thetaA>=theta0>=thetaR return theta0_ * (1 - tanh(uwall/uTheta_) * sign(uwall/uTheta_) ) - thetaA_ * neg(uwall) * tanh(uwall/uTheta_) + thetaR_ * pos(uwall) * tanh(uwall/uTheta_); //Original calculation: //return theta0_ + (thetaA_ - thetaR_)*tanh(uwall/uTheta_); }``` Last edited by Mike.Worth; May 28, 2020 at 03:23. Reason: Added openfoam C++ implimentation

 May 28, 2020, 04:20 #3 New Member   Mike Worth Join Date: Apr 2020 Posts: 7 Rep Power: 2 I've also dug up this thread from last year, which was started with a bug report both that thetaA and thetaR are "the wrong way round" and that the limiting behaviour of the funciton is not to either thetaA or thetaR. The discussion charged off into a dispute about which way round to define the angle, and missed the other (in my mind far less subjective) issue that the function ought to tend to one of them at each extreme...