New flows and fluid objects (Task3)

[Matthew-Boyd]

Thoughts on new flows and fluid objects? (below)

• Will be a common parameter that replaces many in the current function calls
• Will reduce the number of parameters in the function calls, increasing understanding and readability
• Should this continue to be explored, and UML diagrams created (which will be added to a markdown document in the sam-documentation repo)?
• How should particle flows be represented? How simple should the fluid representation be?

Potential new function I/O structures:

    flows                       // at boundaries
        src_in      [flow]
        src_out     [flow]
        sink_in     [flow]
        sink_out    [flow]
        ambient     [flow]

    flow
        fluid_
            type_       [const enum {water, Therminol, particle, etc.}]
            T_          // of the fluid or the particle/interstitial fluid combination
            P_          // of the fluid or the interstitial fluid
            h_
            s_
            x_
            cp_
            void_frac_
            fluid_
                type_
                T_
                P_
                h_
                etc.                
            particle_
                type_   [const enum {none, silica, etc.}]
                T_
                cp_
                density_
                roughness_
        mdot_
        direction_          // for wind direction?

    Examples:
        src_in = flow(FLUID_TYPE)   // sent to fluid constructor
        src_in.T(30);           // T_ is a private member so T() is flow mutator that passes value to
                        //    the fluid mutator which checks the input value and new state of the fluid
                        //    src_in.fluid.T() would do the same, but that is more typing
        src_in.mdot(5);         // similar to T() but this doesn't pass to the fluid object

[tyneises]

This would be a good time to think about how or if we want to combine the HTF properties with the CO2 and steam properties, and how particles fit in. Currently we have to code if/thens around fluid_type if we want to be able to use CO2 or therminol, for example.

I think the current HTF properties class is large, so if we're carrying that around with this new class (unclear if we are in this example or if we want to?), then we might want to think about using pointers.

For the mpst receiver the inlet state is known but we're solving for the mass flow and outlet state. For the cycle model, the inlet state and mass flow are known. One upside to asking for T and m_dot independently in the component method is to be clear what is required. I suppose there could be derived classes that reflect this different use case? I could also imagine derived classes to differentiate between other heat transfer "medium" characteristics.