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.