Compiling OpenFAST in Single Precision

[mjs271]

When trying to compile in single precision, errors are encountered in Driver_Beam_Subs.f90 and OrcaDriver_Subs.f90.

In Driver_Beam_Subs, the problems are at lines 427, 596, 598. At 596 and 598, the fix is relatively simple--just need to change those constant 1.0_ReKi's to 1.0_R8Ki. I believe this is the correct fix, as BeamDyn is always run in double precision. At line 427, the variable DvrData%MultiPointLoad is the problem in that it needs to be double (BDKi) instead of single to be passed to the Find_IniNode() subroutine. DvrData is of type BD_DriverInternalType (defined at the top of Driver_Beam_Subs), and MultiPointLoad is given type ReKi, which, perhaps, should instead be R8Ki. However, I do not know enough about the inner workings to know whether this is the case.

In OrcaDriver_Subs, the problems are at lines 1981 and 1990, and are the same issue. The offending variable here is u%PtfmMesh%TranslationDisp, where PtfmMesh is MeshType, and TranslationDisp is defined to be R8Ki. Everything else in the array being constructed at 1981/1990 is real(4) in single precision, so the quick and dirty fix that gets it to compile is wrapping the three references to u%PtfmMesh%TranslationDisp on each line in real( *, ReKi). However, the better strategy may be to change TranslationDisp to ReKi in ModMesh_Types.f90, though, again, I may not know enough to be correct in this.

[bjonkman]

A few comments:

• Driver_Beam_Subs should define MultiPointLoad as BDKi (line 30). In general it's probably best not to assume BDKi=R8Ki.
• Do not change the types defined in ModMesh_Types.f90. If you do, you will have to change many lines of code throughout FAST, and--most importantly--you will not be able to run BeamDyn simulations in single precision.
• If I were going to change OrcaDriver_Subs, I would create a ReKi array, fill it based on the AnglesInDegrees conditional, and then call WrNumAryFileNR() with that.

[bjonkman]

Also, the problems with the BeamDyn driver were fixed in my fork of OpenFAST earlier this month. I have some more BeamDyn changes that we need to put on the f/Envision-BeamDyn branch in the next couple of weeks (before I do some more testing and do a pull request), but you may want to take a look at the changes we have already done, especially the changes to ElastoDyn and the BeamDyn driver that allow BeamDyn to produce acceptable results in single precision. https://github.com/bjonkman/openfast/tree/f/Envision-BeamDyn

[ghost]

fixed by #46