Goal: To provide an extensible toolkit that is agnostic to synthesis algorithm.
The user may want to solve many kinds of problem:
AbstractHENSProblem: The classical Heat Exchanger Network Synthesis (HENS) problem. All other processes are fixed, so mass flows and temperatures are fixed. Output: The designed HEN as well as other useful data such as the GCC etc. Only simple utility configurations are considered.
AbstractUtilityHENSProblem: Synthesis of both the utility system and the HEN. See: Martelli_Marechal_2017.
AbstractProcessHENSProblem: Synthesis of generalized process and HEN. See Duran_Grossmann_1986. One may also want to implement a generalized background process superstructure that may alternately that may take in organic rankine cycles, steam cycles, heat pump systems and so on. This is reach goal, may be more feasible to start with sub-systems e.g. AbstractSteamCycleHENSProblem, AbstractHeatPumpHENSProblem.
The overall AbstractSynthesisAlgorithm holds types for the techniques to solve one or more of the above problems. As much as possible, these algorithms are named according to the first and last author of the published paper. For instance, one may use the Papoulias_Grossmann_1983() algorithm or the Anantharaman_Gundersen_2010() algorithm for a relevant problem.
The above algorithms involve subproblems usually held within an AbstractSubProblem type. One reach goal could be to also allow multiple AbstractSubProblemAlgorithm that solve certain subproblems. Each of these may make use of different AbstractSuperstructures.
In general, _Problem holds the problem data, _Algorithm works on the sub-problem. A listing of appropriate algorithms for appropriate sub-problems will be documented in the Read-Me (with appropriate checks).
A return type under AbstractSolution will generally be used to hold return types. For subproblems, AbstractSubProblemSolution may be used while AbstractFullSolution may be used for overall problems.
As much as possible, the style conventions and guide provided generally by the SciML Organization and specifically followed in SciMLBase will be followed. An attempt at documenting the code design decisions with issues is also made.
Overview of type hierarchy and code flow:
Goal: To provide an extensible toolkit that is agnostic to synthesis algorithm.
The user may want to solve many kinds of problem:
AbstractHENSProblem: The classical Heat Exchanger Network Synthesis (HENS) problem. All other processes are fixed, so mass flows and temperatures are fixed. Output: The designed HEN as well as other useful data such as the GCC etc. Only simple utility configurations are considered.AbstractUtilityHENSProblem: Synthesis of both the utility system and the HEN. See: Martelli_Marechal_2017.AbstractProcessHENSProblem: Synthesis of generalized process and HEN. See Duran_Grossmann_1986. One may also want to implement a generalized background process superstructure that may alternately that may take in organic rankine cycles, steam cycles, heat pump systems and so on. This is reach goal, may be more feasible to start with sub-systems e.g.AbstractSteamCycleHENSProblem,AbstractHeatPumpHENSProblem.The overall
AbstractSynthesisAlgorithmholds types for the techniques to solve one or more of the above problems. As much as possible, these algorithms are named according to the first and last author of the published paper. For instance, one may use thePapoulias_Grossmann_1983()algorithm or theAnantharaman_Gundersen_2010()algorithm for a relevant problem.The above algorithms involve subproblems usually held within an
AbstractSubProblemtype. One reach goal could be to also allow multipleAbstractSubProblemAlgorithmthat solve certain subproblems. Each of these may make use of differentAbstractSuperstructures.In general,
_Problemholds the problem data,_Algorithmworks on the sub-problem. A listing of appropriate algorithms for appropriate sub-problems will be documented in the Read-Me (with appropriate checks).A return type under
AbstractSolutionwill generally be used to hold return types. For subproblems,AbstractSubProblemSolutionmay be used whileAbstractFullSolutionmay be used for overall problems.As much as possible, the style conventions and guide provided generally by the SciML Organization and specifically followed in SciMLBase will be followed. An attempt at documenting the code design decisions with issues is also made.