Refactor r-tests for C-bindings interfaces

[faisal-bhuiyan]

Major refactor of the driver codes for Python-based libraries to the C-bindings interfaces. These driver codes are essentially regression tests for several modules of OpenFAST. Following tests were refactored in this work

Test project /Users/fbhuiyan/dev/fb-openfast/build
    Start  81: py_ad_5MW_OC4Semi_WSt_WavesWN
1/5 Test  #81: py_ad_5MW_OC4Semi_WSt_WavesWN ....   Passed    1.04 sec
    Start  82: py_ad_B1n2_OLAF
2/5 Test  #82: py_ad_B1n2_OLAF ..................   Passed    1.06 sec
    Start 114: py_hd_5MW_OC4Semi_WSt_WavesWN
3/5 Test #114: py_hd_5MW_OC4Semi_WSt_WavesWN ....   Passed    6.25 sec
    Start 134: py_ifw_turbsimff
4/5 Test #134: py_ifw_turbsimff .................   Passed    0.32 sec
    Start 155: py_md_5MW_OC4Semi
5/5 Test #155: py_md_5MW_OC4Semi ................   Passed    2.10 sec

[andrew-platt]

I would prefer we didn't hard code this to the build directory. But I think that is what we already had.

[rafmudaf]

After using this new change, I have some feedback. Consider it a suggestion or food for thought more than anything.

The Python interfaces to OpenFAST are in an interesting scenario in that they are a way to access a library but they aren't the library itself. From a design perspective, we would generally want to make it opaque to the user (Python programmer) that there's a Fortran module running behind the scenes. However, I think there is some benefit to maintaining a level of consistency with OpenFAST so that we can debug and move across entry points (Python vs C++ vs Fortran) easier. In that regard, I suggest to separate the concerns of this function. Instead of initializing the Python interface and attaching the compiled shared library to the CDLL object + reading the MoorDyn inputs and running MoorDyn.init, I think it would be better scoped to instantiate the interface and attach to the compiled library opaquely and then require that the user (Python programmer making an outer level interface) call MoorDyn init explicitly. As OpenFAST developers, we are accustomed to calling the module functions (i.e. MoorDyn init) but we aren't as accustomed to dealing with the ctypes / CDLL stuff.

I'm happy to have a more in depth chat about it or open a discussion. I think it's important to get right so that we can establish a good pattern and be consistent throughout the other modules.

[andrew-platt]

Good thoughts on this. I'm open to revising how this is done.

[rafmudaf]

@faisal-bhuiyan can you confirm that the error handling is working here? I've changed these two lines in MD_Init:

      ErrStat = ErrID_None
      ErrMsg  = ""

to this:

      ErrStat = ErrID_Fatal
      ErrMsg = "Big ole error"

And I expected it to error in the py_md_5MW_OC4Semi test case, but it does not. @andrew-platt is it true that this should error or am I using these two variables incorrectly?

[andrew-platt]

That should trigger an error. I'm a little surprised it doesn't -- maybe we don't capture it correctly on the py_md_5MW_OC4Semi case?