Bug report - Wrong definition of the boundary layer thickness at zero AoA in `AeroAcoustics` module

[edaniele-tpi]

Bug description The definition of the boundary layer thickness at zero AoA within the THICK subroutine in the file AeroAcoustics.f90 is wrong, because of the usage of the log function instead of the correct log10 one.

To Reproduce Steps to identify error:

1. Look at the definition of DELTA0 variable in case p%ITRIP .GT. 0 within the THICK subroutine in the file AeroAcoustics.f90.
2. Compare it with the very same definition within the NAFNoise repository in the file PREDICT.FOR.
3. See the error.

Expected behavior The log function should be substituted by means of the correct log10 one.

Screenshots, if applicable None.

OpenFAST Version Commit 3456a645581456883e44d441eb285ed688e98797.

System Information (please complete the following information):

• OS: Ubuntu 20.04 LTS.
• Compiler: gfortran 9.3.
• Compiler settings: Standard as for repository configuration.

Additional context Original formulation is available in the corresponding literature source:

• Brooks, T. F.; Pope, D. S. & Marcolini, M. A., Airfoil self-noise and prediction, NASA, NASA, 1989. https://ntrs.nasa.gov/search.jsp?R=19890016302, §3.2, page 9, Equations 2-3-4.

[andrew-platt]

@ptrbortolotti, could you take a look at this?

[bjonkman]

Wondering if anyone has taken a look at this? In commit 292a479c, I can see that @ebranlard had some comments about those lines:

      DELTA0   = 10.**(1.6569-.9045*LOG10(RC)+ &
                .0596*LOG10(RC)**2.)*C
!      IF (p%ITRIP .EQ. 2) DELTA0 = .6 * DELTA0  ! corrected with respect to the Suzlon document Contact Pat Moriarty for further. added 2 lines below.(EB_DTU)
    IF (p%ITRIP .GT. 0) DELTA0 = 10.**(1.892-0.9045*LOG(RC)+0.0596*LOG(RC)**2.)*C
    IF (p%ITRIP .EQ. 2) DELTA0=.6*DELTA0

[ebranlard]

Sorry, I didn't look at this issue. I can confirm that it is indeed a bug. Comparing Figure 6 of https://ntrs.nasa.gov/search.jsp?R=19890016302 : With what's computed with our Fortran code (NOTE: I used fortran for the computation, not python): The log10 formulation is clearly the one matching the data.

Thanks a lot @edaniele-tpi for pointing out to this bug! I'll submit a quick pull request

[edaniele-tpi]

@ebranlard you are welcome, happy to help ;-)