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.
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.