Added InterfaceBuilder to improve ergonomics of creating our CFD interface

[ddement]

No description provided.

[deslaughter]

I like the overall concept and it better documents the values that the user species.

My main concern is the ability of a user to discover which fields must be set. That will need to be documented or the builder will need to keep track of which values have been set and throw an error on the final build call after checking all the inputs. I found there was also something called a Step Builder which uses additional interfaces to expose different functions at various stages of the build. Might be worth looking into.

I think that I'd also prefer a AddMooringLine() function instead of SetNumberOfMooringLines(3) and then specifying an index number. Then the SetMooringLine*() functions could just set the values in the last index of the vector (after checking that there is at least one mooring line). This will visually separate the mooring lines functions into groups and prevents a whole class of indexing issues.

By the way, the functions to set the fair lead velocity and acceleration need to be removed and some code added in Build to calculate those values based on the platform node velocity and acceleration, since they're rigidly connected. I'll have the necessary functions in the model.hpp class soon, but you can go ahead and drop those methods from the builder.

Thanks for putting this together.

[faisal-bhuiyan]

Use brace initializer here as well?

std::vector<MooringLineInput> mooring_lines{};

[ddement]

I tried that. Clang-Tidy had some reason for not liking it there.

[faisal-bhuiyan]

There's a trailing whitespace in this file -- let's remove it.

target_sources(openturbine_library
  PRIVATE
  interface.cpp
)

install(FILES
  floating_platform.hpp
  floating_platform_input.hpp
  interface.hpp
  interface_builder.hpp
  interface_input.hpp
  mooring_line.hpp
  mooring_line_input.hpp
  node_data.hpp
  turbine.hpp
  turbine_input.hpp
  DESTINATION include/OpenTurbine/interfaces/cfd/
)

[faisal-bhuiyan]

Let's call this interface_input or just input?

[faisal-bhuiyan]

I think we could shorten the argument names here, without losing any readability benefits. E.g.

    InterfaceBuilder& SetNumberOfMooringLines(size_t n) {
        interface_in.turbine.floating_platform.mooring_lines.resize(n);
        return *this;
    }

[faisal-bhuiyan]

Should we call it BuildInterface to be consistent with how we named our other factory methods (such as CreateBeams)?

[ddement]

I was trying to be consistent with the Builder Pattern, where things are named this way by convention. I'm open to changing it if there are strong opinions.

[faisal-bhuiyan]

No strong opinion here, wanted to make sure we are being consistent within the codebase.

[faisal-bhuiyan]

We may want to add some validation logic here to make sure we provide some guardrails for user error.

[ddement]

Agreed. I am thinking these guardrails will come once we have fully fleshed out the interface and added other features (such as an actual turbine). I'd have to rely on yall to know what would make sense to check in this domain beyond certain obvious things (negative mass, etc).

[ddement]

@deslaughter I've put together a prototype implementation of the a step-builder version of the interface. I'd love your feedback on it. See the FloatingPlatform regression test for a comparison of it versus the traditional builder. Obviously, the implementation needs a little clean up, but I wanted to get your input before I blew away the old stuff.