diff --git a/ChangeLog.md b/ChangeLog.md deleted file mode 100644 index 949e878..0000000 --- a/ChangeLog.md +++ /dev/null @@ -1,3 +0,0 @@ -# Changelog for mivika - -## Unreleased changes diff --git a/Setup.hs b/Setup.hs deleted file mode 100644 index 9a994af..0000000 --- a/Setup.hs +++ /dev/null @@ -1,2 +0,0 @@ -import Distribution.Simple -main = defaultMain diff --git a/doc/MastersThesis/Lhs/Appendix.lhs b/doc/MastersThesis/Lhs/Appendix.lhs index c1f49e0..fd4d1d4 100644 --- a/doc/MastersThesis/Lhs/Appendix.lhs +++ b/doc/MastersThesis/Lhs/Appendix.lhs @@ -1,4 +1,3 @@ - \section{Literate Programming} This dissertation made use of literate programming~\footnote{\href{https://en.wikipedia.org/wiki/Literate_programming}{\textcolor{blue}{Literate Programming}}.}, a concept @@ -26,4 +25,111 @@ the latest iteration of the Lorenz Attractor example, time step of $0.01$ with t commands for Windows when running in a Linux machine and vice-versa, should be ignored. \end{itemize} +\section{FFACT's Manual} +\label{appendix:manual} + +This is a concise and pragmatic manual on how to create and run simulations using \texttt{FFACT}. For a deeper and more detailed description +of the internals of the DSL, including a walkthrough via examples, please consult (and generate via \texttt{literate.sh}) either \texttt{GraduationThesis} (for \texttt{FACT}) or \texttt{MasterThesis} (for \texttt{FFACT}). + +\subsection{Models} + +A simulation model is defined using \texttt{mdo-notation} (check +\href{https://ghc.gitlab.haskell.org/ghc/doc/users_guide/exts/recursive_do.html}{recursive +do}) to describe a system of \textit{differential equations}. The current version of \texttt{FFACT} only supports +continuous simulations, i.e., discrete or hybrid simulations are future work. Alongside the equations, one must provide \textit{initial conditions} for +each individual equation, such as the following: + +\begin{purespec} +lorenzModel :: Model [Double] +lorenzModel = mdo + x <- integ (sigma * (y - x)) 1.0 + y <- integ (x * (rho - z) - y) 1.0 + z <- integ (x * y - beta * z) 1.0 + let sigma = 10.0 + rho = 28.0 + beta = 8.0 / 3.0 + return $ sequence [x, y, z] +\end{purespec} + +In this example, \texttt{lorenzModel} will return the state variables of interest via a list, hence the model having the type \texttt{Model [Double]}. +Recursive monadic bindings are possible due to \texttt{mdo}, which makes the description of a model in code closer to its mathematical counterpart. + +\subsection{Solver} + +Solver-specific configurations, e.g., which numerical method should be used and with which \textit{time step}, which solver stage should it start with, +are configured \textit{separately} from the model and from executing a simulation. This sort of configuration details are set via a separate record, such as the following: + +\begin{purespec} +lorenzSolver = Solver { dt = 1, + method = RungeKutta2, + stage = SolverStage 0 + } +\end{purespec} + +Available numerical methods: +\begin{itemize} +\item \texttt{Euler} +\item \texttt{RungeKutta2} +\item \texttt{RungeKutta4} +\end{itemize} + +\subsection{Simulation} + +A model and a record with solver's configuration are some of the \textit{arguments} to a \textit{driver function}. A driver function runs the simulation starting from 0 until +a provided timestamp (in seconds). Currently, \texttt{runCTFinal} outputs the final result of the system +at the provided final time and \texttt{runCT} outputs a \textit{list} of intermediate values from the start +until the provided final time spaced by the time step within the solver's configuration. +The type signatures of these functions are the following (\texttt{Double} is the final time of choice): + +\begin{purespec} +runCTFinal :: Model a -> Double -> Solver -> IO a +runCT :: Model a -> Double -> Solver -> IO [a] +\end{purespec} + +\subsection{Interpolation} + +Both \texttt{FACT} and \texttt{FFACT} use \textit{linear interpolation} to approximate results in requested timestamps that are not reachable via the chosen time step within +the solver's configuration. Driver functions automatically take care of detecting and running interpolations. +The type signature of the provided interpolation function (and probably future extensions) is the following: + +\begin{purespec} +interpolate :: CT Double -> CT Double +\end{purespec} + +\subsection{Caching} + +Both \texttt{FACT} and \texttt{FFACT} employ a \textit{memoization strategy} for caching, in order to speed up the simulation execution. Without this, simulations recompute previously +computed values multiple times, due to the recursive nature of the numerical methods available. A table is saved in memory with already calculated values, and lookups +are done instead of triggering a new computation. +The type signature of the provided memoization function (and probably future extensions) is the following: + +\begin{purespec} +memo :: UMemo e => (CT e -> CT e) -> CT e -> CT (CT e) +\end{purespec} + +The typeclass \texttt{UMemo} is provided custom typeclass. + +\subsection{Example} + +Lorenz Attractor complete example: + +\begin{purespec} +lorenzModel :: Model [Double] +lorenzModel = mdo + x <- integ (sigma * (y - x)) 1.0 + y <- integ (x * (rho - z) - y) 1.0 + z <- integ (x * y - beta * z) 1.0 + let sigma = 10.0 + rho = 28.0 + beta = 8.0 / 3.0 + return $ sequence [x, y, z] + +lorenzSolver = Solver { dt = 1, + method = RungeKutta2, + stage = SolverStage 0 + } + +lorenz = runCTFinal lorenzModel 100 lorenzSolver +\end{purespec} + diff --git a/doc/MastersThesis/Lhs/Conclusion.lhs b/doc/MastersThesis/Lhs/Conclusion.lhs index 9e70d10..74086e7 100644 --- a/doc/MastersThesis/Lhs/Conclusion.lhs +++ b/doc/MastersThesis/Lhs/Conclusion.lhs @@ -1,3 +1,6 @@ +Our motivation was to mitigate the high difficulty of modeling +arbitrary closed feedback loops, using the DSL proposed by Medeiros et al.~\cite{Edil2018}. In their DSL, time-varying signals are abstracted by a function data type that updates the state of the system, and the topology of the system can only be described via a set of composition operators instead of dealing with the signals explicitly. In this work, we tackled this by proposing \texttt{FACT}: a reimplementation of the DSL based on a new implementation abstraction, called \texttt{CT}, whilst maintaining GPAC as the formal inspiration. This new data type holds the state of the system indirectly, thus allowing the user of the DSL to directly manipulate the signals when describing a system of equations. The guiding example used throughout this work, the Lorenz Attractor in Figure~\ref{fig:introExample}, is an example of a system with feedback loops that the former DSL could not express. Despite solving this expressivenness problem, \texttt{FACT} introduced an abstraction leaking, exposing to the users of the DSL internal implementation details. We solved this issue leveraging the monadic fixed-point combinator, resulting \texttt{FFACT} and thus improving the notation and usability. + Chapter 2 established the foundation of the implementation, introducing functional programming (FP) concepts and the necessary types to model continuous time simulation --- with continuous time machines (\texttt{CT}) being the main type. Chapter 3 extended its power via @@ -7,15 +10,9 @@ for it, as well as the available numerical methods for simulation. As a follow-up, Chapter 4 raised intuition and practical understanding of \texttt{FACT} via a detailed walkthrough of an example. Chapter 5 explained and fixed the mix between different domains in the simulation, e.g., continuous time, discrete time and iterations, via an additional linear interpolation when executing a model. Chapter 6 addressed performance concerns via a memoization strategy. Finally, -Chapter 7 introduced the fixed-point combinator in order to increase conciseness of the HEDSL, bringing more familiarity to systems designers +Chapter 7 introduced the fixed-point combinator and its monadic counterpart in order to increase conciseness of the HEDSL, bringing more familiarity to systems designers experienced with the mathematical descriptions of their systems of interest. This notation enhancement is the defining feature between FACT and FFACT. -\section{Final Thoughts} - -When Shannon proposed a formal foundation for the Differential Analyzer~\cite{Shannon}, mathematical abstractions were leveraged to model continuous time. However, after the transistor era, a new set of concepts that lack this formal basis was developed, and some of which crippled our capacity of simulating reality. Later, the need for some formalism made a comeback for modeling physical phenomena with abstractions that take \textit{time} into consideration. Models of computation~\cite{LeeModeling, LeeChallenges, LeeComponent, LeeSangiovanni} and the ForSyDe framework~\cite{Sander2017, Seyed2020} are examples of this change in direction. Nevertheless, Shannon's original idea is now being discussed again with some improvements~\cite{Graca2003, Graca2004, Graca2016} and being transposed to high level programming languages in the hybrid system domain~\cite{Edil2018}. - -The \texttt{FACT} EDSL~\footnote{\texttt{FACT} \href{https://github.com/FP-Modeling/fact/releases/tag/3.0}{\textcolor{blue}{source code}}.} follows this path of bringing CPS simulation to the highest level of abstraction, via the Haskell programming language, but still taking into account a formal background inspired by the GPAC model. The software uses advanced functional programming techniques to solve differential equations, mapping the abstractions to FF-GPAC's analog units. Although still limited by the discrete nature of numerical methods, the solution is performant and accurate enough for studies in the cyber-physical domain. - \section{Future Work} The following subsections describe the three main areas for future improvements in \texttt{FFACT}: formalism, possible extensions, and code refactoring. diff --git a/doc/MastersThesis/Lhs/Design.lhs b/doc/MastersThesis/Lhs/Design.lhs index 58ec516..0071d49 100644 --- a/doc/MastersThesis/Lhs/Design.lhs +++ b/doc/MastersThesis/Lhs/Design.lhs @@ -35,8 +35,6 @@ Composition rules that restrict how these units can be connected to one another. \item Each variable of integration of an integrator is the input \textit{t}. \end{itemize} -During the definition of the DSL, parallels will map the aforementioned basic units and composition rules to the implementation. With this strategy, all the mathematical formalism leveraged for analog computers will drive the implementation in the digital computer. Although we do not formally prove a refinement between the GPAC theory, i.e., our specification, and the final implementation of \texttt{FACT}, is an attempt to build a tool with formalism taken into account; one of the most frequent critiques in the CPS domain, as explained in the previous Chapter. - \section{The Shape of Information} \label{sec:types} diff --git a/doc/MastersThesis/Lhs/Enlightenment.lhs b/doc/MastersThesis/Lhs/Enlightenment.lhs index 5993fac..200a3a3 100644 --- a/doc/MastersThesis/Lhs/Enlightenment.lhs +++ b/doc/MastersThesis/Lhs/Enlightenment.lhs @@ -34,7 +34,7 @@ oldLorenzSystem = runCTFinal oldLorenzModel 100 lorenzSolver \end{code} } -Previously, we presented in detail the latter core type of the implementation, the integrator, as well as why it can model an integral when used with the \texttt{CT} type. This Chapter is a follow-up, and its objectives are threefold: to describe how to map a set of differential equations to an executable model, to reveal which functions execute a given example and to present a guided-example as a proof-of-concept. +Previously, we presented in detail the latter core type of the implementation, the integrator, as well as why it can model an integral when used with the \texttt{CT} type. This Chapter is a follow-up, and its objectives are threefold: to describe how to map a set of differential equations to an executable model, to reveal which functions execute a given example and to present a guided-example as a proof-of-concept. For a simplified guide on how to use the DSL, check the Appendix~\ref{appendix:manual}. \section{From Models to Models} diff --git a/doc/MastersThesis/Lhs/Introduction.lhs b/doc/MastersThesis/Lhs/Introduction.lhs index 5dd7055..27d2dc5 100644 --- a/doc/MastersThesis/Lhs/Introduction.lhs +++ b/doc/MastersThesis/Lhs/Introduction.lhs @@ -7,7 +7,7 @@ import MastersThesis.Lhs.Enlightenment \end{code} } -Continuous behaviours are deeply embedded into the real world. However, even our most advanced computers are not capable of completely modeling such phenomena due to its discrete nature; thus becoming a still-unsolved challenge. Cyber-physical systems (CPS) --- the integration of computers and physical processes~\cite{LeeModeling, LeeChallenges} --- tackles this problem by attempting to include into the \textit{semantics} of computing the physical notion of \textit{time}~\cite{LeeChallenges, Lee2016, Lee2014, Ungureanu2018, Seyed2020, Edil2021}, i.e., treating time as a measurement of \textit{correctness}, not \textit{performance}~\cite{LeeModeling} nor just an accident of implementation~\cite{LeeChallenges}. Additionally, many systems perform in parallel, which requires precise and sensitive management of time; a non-achievable goal by using traditional computing abstractions, e.g., \textit{threads}~\cite{LeeChallenges}. +Continuous behaviours are deeply embedded into the real world. However, even our most advanced computers are not capable of completely modeling such phenomena due to its discrete nature; thus continuing to be a challenge. Cyber-physical systems (CPS) --- the integration of computers and physical processes~\cite{LeeModeling, LeeChallenges} --- tackles this problem by attempting to include into the \textit{semantics} of computing the physical notion of \textit{time}~\cite{LeeChallenges, Lee2016, Lee2014, Ungureanu2018, Seyed2020, Edil2021}, i.e., treating time as a measurement of \textit{correctness}, not \textit{performance}~\cite{LeeModeling} nor just an accident of implementation~\cite{LeeChallenges}. Additionally, many systems perform in parallel, which requires precise and sensitive management of time; a non-achievable goal by using traditional computing abstractions, e.g., \textit{threads}~\cite{LeeChallenges}. Examples of these concepts are older than the digital computers; analog computers were used to model battleships' fire systems and core functionalities of fly-by-wire aircraft~\cite{Graca2003}. The mechanical metrics involved in these problems change continuously, such as space, speed and area, e.g., the firing's range and velocity are crucial in fire systems, and surfaces of control are indispensable to model aircraft's flaps. The main goal of such models was, and still is, to abstract away the continuous facet of the scenario to the computer. In this manner, the human in the loop aspect only matters when interfacing with the computer, with all the heavy-lifting being done by formalized use of shafts and gears in analog machines~\cite{Shannon, Bush1931, Graca2003}, and by \textit{software} after the digital era. @@ -15,18 +15,18 @@ Within software, the aforementioned issues --- the lack of time semantics and th The development of a \textit{model of computation} (MoC) to define and express models is the major hero towards this better set of abstractions, given that it provides clear, formal and well-defined semantics~\cite{LeeModeling} on how engineering artifacts should behave~\cite{Lee2016}. These MoCs determine how concurrency works in the model, choose which communication protocols will be used, define whether different components share the notion of time, as well as whether and how they share state~\cite{LeeModeling, LeeComponent}. Also, Sangiovanni and Lee~\cite{LeeSangiovanni} proposed a formalized denotational framework to allow understanding and comparison between mixtures of MoCs, thus solving the heterogeneity issue that raises naturally in many situations during design~\cite{LeeModeling, LeeComponent}. Moreover, their framework also describes how to compose different MoCs, along with addressing the absence of time in models, via what is defined as \textit{tagged systems}~\cite{Chupin2019, Perez2023, Rovers2011} --- a relationship between a \textit{tag}, generally used to order events, and an output value. -Ingo et al. went even further~\cite{Sander2017} by presenting a framework based on the idea of tagged systems, known as \textit{ForSyDe}. The tool's main goal is to push system design to a higher level of abstraction, by combining MoCs with the functional programming paradigm. The technique separates the design into two phases, specification and synthesis. The former stage, specification, focus on creating a high-level abstraction model, in which mathematical formalism is taken into account. The latter part, synthesis, is responsible for applying design transformations --- the model is adapted to ForSyDe's semantics --- and mapping this result onto a chosen architecture to be implemented later in a target programming language or hardware platform~\cite{Sander2017}. Afterward, Seyed-Hosein and Ingo~\cite{Seyed2020} created a co-simulation architecture for multiple models based on ForSyDe's methodology, addressing heterogeneity across languages and tools with different semantics. One example of such tools treated in the reference is Simulink~\footnote{Simulink \href{http://www.mathworks.com/products/simulink/}{\textcolor{blue}{documentation}}.}, the de facto model-based design tool that lacks a formal semantics basis~\cite{Seyed2020}. Simulink being the standard tool for modeling means that, despite all the effort into utilizing a formal approach to model-based design, this is still an open problem. +Ingo et al. went even further~\cite{Sander2017} by presenting a framework based on the idea of tagged systems, known as \textit{ForSyDe}. The tool's main goal is to push system design to a higher level of abstraction, by combining MoCs with the functional programming paradigm. The technique separates the design into two phases, specification and synthesis. The former stage, specification, focus on creating a high-level abstraction model, in which mathematical formalism is taken into account. The latter part, synthesis, is responsible for applying design transformations --- the model is adapted to ForSyDe's semantics --- and mapping this result onto a chosen architecture to be implemented later in a target programming language or hardware platform~\cite{Sander2017}. Afterward, Seyed-Hosein and Ingo~\cite{Seyed2020} created a co-simulation architecture for multiple models based on ForSyDe's methodology, addressing heterogeneity across languages and tools with different semantics. One example of such tools treated in the reference is Simulink~\footnote{Simulink \href{http://www.mathworks.com/products/simulink/}{\textcolor{blue}{documentation}}.}, the de facto model-based design tool~\cite{Seyed2020}. Simulink being the standard tool for modeling means that, despite all the effort into utilizing a formal approach to model-based design, there is still room for improvement. \section{Contribution} \label{sec:intro} -The aforementioned works --- the formal notion of MoCs, the ForSyDe framework and its interaction with modeling-related tools like Simulink --- comprise the domain of model-based design or \textit{model-based engineering}. Furthermore, the main goal of this work is to contribute to this area of CPS by creating a domain-specific language tool (DSL) for simulating continuous-time systems that addresses the absence of a formal basis. Thus, this tool will help to deal with the incompatibility of the mentioned sets of abstractions~\cite{LeeChallenges} --- the discreteness of digital computers with the continuous nature of physical phenomena. +The aforementioned works --- the formal notion of MoCs, the ForSyDe framework and its interaction with modeling-related tools like Simulink --- comprise the domain of model-based design or \textit{model-based engineering}. Furthermore, the main goal of this work is to contribute to this sub-area of CPS by creating a domain-specific language tool (DSL) for simulating continuous-time systems that addresses inspired by a mathematical model of computation. Thus, this tool will serve as the foundation to deal with the incompatibility of the mentioned sets of abstractions~\cite{LeeChallenges} --- the discreteness of digital computers with the continuous nature of physical phenomena. The proposed DSL has three special properties of interest: \begin{enumerate} \item it needs to have well-defined \textit{operational} semantics, as well as being a piece of \textit{executable} software; -\item it needs to be related or inspired by a \textit{formal} foundation, moving past \textit{ad-hoc} implementations; +\item it needs to be related or inspired by a \textit{formal} model, moving past \textit{ad-hoc} implementations; \item it should be \textit{concise}; its lack of noise will bring familiarity to the \textit{system's designer} --- the pilot of the DSL which strives to execute a given specification or golden model. \end{enumerate} @@ -34,7 +34,7 @@ The proposed DSL has three special properties of interest: By making an executable software capable of running continuous time simulations, \textit{verification via simulation} will be available --- a type of verification that is useful when dealing with \textit{non-preserving} semantic transformations, i.e., modifications and tweaks in the model that do not assure that properties are being preserved. Such phenomena are common within the engineering domain, given that a lot of refinement goes into the modeling process in which previous proof-proved properties are not guaranteed to be maintained after iterations with the model. A work-around solution for this problem would be to prove again that the features are in fact present in the new model; an impractical activity when models start to scale in size and complexity. Thus, by using an executable tool as a virtual workbench, models that suffered from those transformations could be extensively tested and verified. -Furthermore, this implementation is based on \texttt{Aivika}~\footnote{\texttt{Aivika} \href{https://github.com/dsorokin/aivika}{\textcolor{blue}{source code}}.} --- an open source multi-method library for simulating a variety of paradigms, including partial support for physical dynamics, written in Haskell. Our version is modified for our needs, such as demonstrating similarities between the implementation and GPAC, shrinking some functionality in favor of focusing on continuous time modeling, and re-thinking the overall organization of the project for better understanding, alongside code refactoring using other Haskell's abstractions. So, this reduced and refactored version of \texttt{Aivika}, so-called \texttt{FACT}~\footnote{\texttt{FACT} \href{https://github.com/FP-Modeling/fact/releases/tag/3.0}{\textcolor{blue}{source code}}.}, will be a Haskell Embedded Domain-Specific Language (HEDSL) within the model-based engineering domain. The built DSL will explore Haskell's specific features and details, such as the type system and typeclasses, to solve differential equations. Figure \ref{fig:introExample} shows a side-by-side comparison between the original implementation of Lorenz Attractor in FACT, presented in~\cite{Lemos2022}, and its final form, so-called FFACT, for the same physical system. +Furthermore, this implementation is based on \texttt{Aivika}~\footnote{\texttt{Aivika} \href{https://github.com/dsorokin/aivika}{\textcolor{blue}{source code}}.} --- an open source multi-method library for simulating a variety of paradigms, including partial support for physical dynamics, written in Haskell. Our version is modified for our needs, such as demonstrating similarities between the implementation and GPAC, shrinking some functionality in favor of focusing on continuous time modeling, and re-thinking the overall organization of the project for better understanding, alongside code refactoring using other Haskell's abstractions. So, this reduced and refactored version of \texttt{Aivika}, so-called \texttt{FACT}~\footnote{\texttt{FACT} \href{https://github.com/FP-Modeling/fact/releases/tag/4.0}{\textcolor{blue}{source code}}.}, will be a Haskell Embedded Domain-Specific Language (HEDSL) within the model-based engineering domain. The built DSL will explore Haskell's specific features and details, such as the type system and typeclasses, to solve differential equations. Figure~\ref{fig:introExample} shows a side-by-side comparison between the original implementation of Lorenz Attractor in FACT, presented in~\cite{Lemos2022}, and its final form, so-called FFACT, for the same physical system. \begin{figure}[ht!] \begin{minipage}{0.5\linewidth} @@ -73,11 +73,20 @@ Furthermore, this implementation is based on \texttt{Aivika}~\footnote{\texttt{A \label{fig:introExample} \end{figure} -\subsection{Formal Foundation} +\subsection{GPAC: inspiration for a Formal Model} -The tool is inspired by the general-purpose analog computer (GPAC) formal guidelines, proposed by Shannon~\cite{Shannon} in 1941, as an inspiration for a solid and formal foundation. This concept was developed to model a Differential Analyzer --- an analog computer composed by a set of interconnected gears and shafts intended to solve numerical problems~\cite{Graca2004}. The mechanical parts represents \textit{physical quantities} and their interaction results in solving differential equations, a common activity in engineering, physics and other branches of science~\cite{Shannon}. The model was based on a set of black boxes, so-called \textit{circuits} or \textit{analog units}, and a set of proved theorems that guarantees that the composition of these units are the minimum necessary to model the system, given some conditions. For instance, if a system is composed by a set of \textit{differentially algebraic} equations with prescribed initial conditions~\cite{Graca2003}, then a GPAC circuit can be built to model it. Later on, some extensions of the original GPAC were developed, going from solving unaddressed problems contained in the original scope of the model~\cite{Graca2003} all the way to make GPAC capable of expressing generable functions, Turing universality and hypertranscendental functions~\cite{Graca2004, Graca2016}. Furthermore, although the analog computer has been forgotten in favor of its digital counterpart~\cite{Graca2003}, recent studies in the development of hybrid systems~\cite{Edil2018} brought GPAC back to the spotlight in the CPS domain. +This work and its artifact (a functional DSL to execute simulations) is a direct continuation of the work +made by Edil Medeiros et al.~\cite{Edil2018}. Their work tackled CPS-modeling via a DSL, which used the general-purpose +analog computer (GPAC), proposed by Shannon~\cite{Shannon} in 1941, as a guideline for a solid and formal foundation. -The HEDSL will translate GPAC's original set of black boxes to some executable software leveraging mathematical constructs to simplify its usability. The programming language of choice was \textit{Haskell} --- a well known language in the functional paradigm (FP). The recognition that such paradigm provides better well-defined, mathematical and rigourous abstractions has been proposed by Backus~\cite{Backus1978} in his Turing Award lecture; where he argued that FP is the path to liberate computing from the limitations of the \textit{von Neumann style} when thinking about systems. Thus, continuous time being specified in mathematical terms, we believe that the use of functional programming for modeling continuous time is not a coincidence; properties that are established as fundamental to leverage better abstractions for CPS simulation seem to be within or better described in FP. +Hence, the tool we propose is also inspired by GPAC. This concept was developed to model a Differential Analyzer --- an analog computer composed by a set of interconnected gears and shafts intended to solve numerical problems~\cite{Graca2004}. The mechanical parts represents \textit{physical quantities} and their interaction results in solving differential equations, a common activity in engineering, physics and other branches of science~\cite{Shannon}. The model was based on a set of black boxes, so-called \textit{circuits} or \textit{analog units}, and a set of proved theorems that guarantees that the composition of these units are the minimum necessary to model the system, given some conditions. For instance, if a system is composed by a set of \textit{differentially algebraic} equations with prescribed initial conditions~\cite{Graca2003}, then a GPAC circuit can be built to model it. Later on, some extensions of the original GPAC were developed, going from solving unaddressed problems contained in the original scope of the model~\cite{Graca2003} all the way to make GPAC capable of expressing generable functions, Turing universality and hypertranscendental functions~\cite{Graca2004, Graca2016}. Furthermore, although the analog computer has been forgotten in favor of its digital counterpart~\cite{Graca2003}, recent studies in the development of hybrid systems~\cite{Edil2018} brought GPAC back to the spotlight in the CPS domain. + +During the design of the DSL, parallels will establish some resemblance between GPAC's constructs and the implementation. With this strategy, all the mathematical formalism leveraged for analog computers will drive the implementation in the digital computer. However, it is worth noting that we do not formally prove this mapping +holds using dedicated tools, such as proof assistants or dependently-typed prograamming languages. GPAC serves as an initial specification in which +the generated artifact (executable models for simulation) attempts to follow. Although outside of the scope of this work, this pursue for a formal foundation +can be developed in the future. + +With that in mind, the HEDSL will strive to translate GPAC's original set of black boxes to some executable software leveraging mathematical constructs to simplify its usability. The programming language of choice was \textit{Haskell} --- a well known language in the functional paradigm (FP). The recognition that such paradigm provides better well-defined, mathematical and rigourous abstractions has been proposed by Backus~\cite{Backus1978} in his Turing Award lecture; where he argued that FP is the path to liberate computing from the limitations of the \textit{von Neumann style} when thinking about systems. Thus, continuous time being specified in mathematical terms, we believe that the use of functional programming for modeling continuous time is not a coincidence; properties that are established as fundamental to leverage better abstractions for CPS simulation seem to be within or better described in FP. Lee describes a lot of properties~\cite{LeeModeling} that matches this programming paradigm almost perfectly: @@ -91,22 +100,65 @@ paradigm almost perfectly: In terms of the DSL being \textit{embedded} in Haskell, this approach of making specialized programming languages, or \textit{vocabularies}, within consistent and well-defined host programming languages, has already proven to be valuable, as noted by Landin~\cite{Landin1966}. Further, this strategy is already being used in the CPS domain in some degree, as showed by the ForSyDe framework~\cite{Sander2017, Seyed2020}. -\subsection{Conciseness} +\subsection{Expressiveness and Conciseness} -Finally, conciseness to improve the DSL's usability will be assured by the use of the \textit{fixed-point combinator}; a mathematical construct used in the DSL's machinery to hide implementation details noise from the user's perspective, keeping on the surface only the constructs that matter from the designer's point of view. As the dissertation will explain, this happens due to an \textit{abstraction leak} in the original DSL~\cite{Lemos2022}, identified via -an overloaded syntax. Once the leak is solved, it is expected that the \textit{target audience} --- system's designers with less programming experience but familiar with the system's mathematical description --- will be able to leverage the DSL either when improving the system's description, using the DSL as a refinement tool, or as a way to execute an already specified system. Given that the present work, FFACT, being a direct continuation of FACT~\cite{Lemos2022}, it is important to highlight that this final property is the main differentiating factor between the two pieces. +This dissertation being a step in a broader story, started in 2018 by Medeiros et al.~\cite{Edil2018}, one of the goals is to +improve on the identified limitations in the first proposed DSL, such as the lack or high difficulty on +expressing systems via explicit signal manipulation for arbitrary closed feedback loops. Later publications addressed this issue~\cite{Lemos2022, EdilLemos2023} whilst introducing or keeping known problems, such as noisy and overloaded notation when using the DSL (Figure~\ref{fig:comparison})-- a consequence of an \textit{abstraction leaking} -- and +not being able to model hybrid systems; systems with changes in continuous behavior based on discrete events. -When comparing models in FFACT to other implementations in other ecosystems and programming languages, FFACT's conciseness brings more familiarity, i.e., +\begin{figure}[ht!] +\begin{subfigure}{1\linewidth} + \begin{minipage}{0.62\linewidth} + \begin{purespec} + sineModel = intCT rk4 0 0 p1 + where + p1 = (constCT (-1) *** idCT) >>> multCT >>> integ + integ = intCT rk4 0 1 loopBreaker + loopBreaker = (idCT *** constCT 0) >>> adderCT + \end{purespec} + \end{minipage} \;\;\;\;\;\;\;\;\;\;\;\;\;\;\;\; + \begin{minipage}{0.17\linewidth} + \begin{equation*} + \begin{cases} \dot{y}(t) = z(t) \\ + \dot{z}(t) = -y(t) + \end{cases} + \end{equation*} + \end{minipage} +\end{subfigure} +\begin{subfigure}{1\linewidth} + \vspace{1cm} + \begin{minipage}{0.4\linewidth} + \begin{purespec} + sineModel = + do integY <- createInteg 1 + integZ <- createInteg 0 + let y = readInteg integY + z = readInteg integZ + updateInteg integY z + updateInteg integZ (-y) + return $ sequence [y, z] + \end{purespec} + \end{minipage} \;\;\;\;\;\;\;\;\;\;\;\;\;\;\;\; + \begin{minipage}{0.59\linewidth} + \centering + \includegraphics[width=0.91\linewidth]{MastersThesis/img/sine_circuit.pdf} + \end{minipage} +\end{subfigure} +\caption{Comparison between the original proposed DSL~\cite{Edil2018} and the first version of \texttt{FACT}~\cite{Lemos2022, EdilLemos2023} +using the same sine model, alongside its mathematical and GPAC descriptions.} +\label{fig:comparison} +\end{figure} + +So, to address the aforementioned abstraction leaking and improve the DSL's conciseness, this work uses the \textit{fixed-point combinator}; a mathematical construct. The goal is to make the DSL's machinery hide implementation details noise from the user's perspective, keeping on the surface only the constructs that matter from the designer's point of view. Once the leak is solved, it is expected that the \textit{target audience} --- system's designers with less programming experience but familiar with the system's mathematical description --- will be able to leverage the DSL either when improving the system's description, using the DSL as a refinement tool, or as a way to execute an already specified system. Given that the present work, FFACT, being a direct continuation of FACT~\cite{Lemos2022}, it is important to highlight that this final property is the main differentiating factor between the two pieces. + +When comparing models in \texttt{FFACT} to other implementations in other ecosystems and programming languages, \texttt{FFACT}'s conciseness brings more familiarity, i.e., one using the HEDSL needs less knowledge about the host programming language, Haskell in our case, \textit{and} one can more easily bridge the gap between a mathematical -description of the problem and its analogous written in FFACT, due to less syntatical burden and noise from a user's perpective. Examples and comparisons will be +description of the problem and its analogous written in \texttt{FFACT}, due to less syntatical burden and noise from a user's perpective. Examples and comparisons will be depicted in Chapter 7, \textit{Fixing Recursion}, Section~\ref{sec:examples}. \section{Outline} -This dissertation is a step in a broader story, started in 2018 by Edil Medeiros et al.~\cite{Edil2018}. Medeiros' work had some limitations, such as having difficulty -modeling systems via explicit signal manipulation, and later publications addressed this issue~\cite{Lemos2022, EdilLemos2023}. The chapters -in this work encompass the previous milestones from this story, giving the reader a complete overview from the ground up in this research thread. - Chapter 2, \textit{Design Philosophy}, presents the foundation of this work, started in 2018~\cite{Edil2018}. Although the artifacts presented in the original work and this work are far apart, the mathematical base is the same. Chapters 3 to 6 describe future improvements made in 2022~\cite{Lemos2022} and 2023~\cite{EdilLemos2023}. These chapters go in detail about the DSL's implementation details, such as the used abstractions, going through executable examples, diff --git a/doc/MastersThesis/img/sine_circuit.pdf b/doc/MastersThesis/img/sine_circuit.pdf new file mode 100644 index 0000000..b93047f Binary files /dev/null and b/doc/MastersThesis/img/sine_circuit.pdf differ diff --git a/doc/MastersThesis/thesis.lof b/doc/MastersThesis/thesis.lof index 9d455e6..fbd2565 100644 --- a/doc/MastersThesis/thesis.lof +++ b/doc/MastersThesis/thesis.lof @@ -3,62 +3,63 @@ \babel@toc {american}{}\relax \addvspace {10\p@ } \contentsline {figure}{\numberline {1.1}{\ignorespaces The translation between the world of software and the mathematical description of differential equations are more concise and explicit in \texttt {FFACT}.}}{4}{figure.caption.8}% +\contentsline {figure}{\numberline {1.2}{\ignorespaces Comparison between the original proposed DSL~\cite {Edil2018} and the first version of \texttt {FACT}~\cite {Lemos2022, EdilLemos2023} using the same sine model, alongside its mathematical and GPAC descriptions.}}{6}{figure.caption.9}% \addvspace {10\p@ } -\contentsline {figure}{\numberline {2.1}{\ignorespaces The combination of these four basic units compose any GPAC circuit (taken from~\cite {Edil2018} with permission).}}{9}{figure.caption.9}% -\contentsline {figure}{\numberline {2.2}{\ignorespaces Polynomial circuits resembles combinational circuits, in which the circuit respond instantly to changes on its inputs (taken from~\cite {Edil2018} with permission).}}{10}{figure.caption.10}% -\contentsline {figure}{\numberline {2.3}{\ignorespaces Types are not just labels; they enhance the manipulated data with new information. Their difference in shape can work as the interface for the data.}}{11}{figure.caption.11}% -\contentsline {figure}{\numberline {2.4}{\ignorespaces Functions' signatures are contracts; they purespecify which shape the input information has as well as which shape the output information will have.}}{11}{figure.caption.11}% -\contentsline {figure}{\numberline {2.5}{\ignorespaces Sum types can be understood in terms of sets, in which the members of the set are available candidates for the outer shell type. Parity and possible values in digital states are examples.}}{12}{figure.caption.12}% -\contentsline {figure}{\numberline {2.6}{\ignorespaces Product types are a combination of different sets, where you pick a representative from each one. Digital clocks' time and objects' coordinates in space are common use cases. In Haskell, a product type can be defined using a \textit {record} alongside with the constructor, where the labels for each member inside it are explicit.}}{12}{figure.caption.13}% -\contentsline {figure}{\numberline {2.7}{\ignorespaces Depending on the application, different representations of the same structure need to used due to the domain of interest and/or memory constraints.}}{13}{figure.caption.14}% -\contentsline {figure}{\numberline {2.8}{\ignorespaces The minimum requirement for the \texttt {Ord} typeclass is the $<=$ operator, meaning that the functions $<$, $<=$, $>$, $>=$, \texttt {max} and \texttt {min} are now unlocked for the type \texttt {ClockTime} after the implementation. Typeclasses can be viewed as a third dimension in a type.}}{13}{figure.caption.15}% -\contentsline {figure}{\numberline {2.9}{\ignorespaces Replacements for the validation function within a pipeline like the above are common.}}{14}{figure.caption.16}% -\contentsline {figure}{\numberline {2.10}{\ignorespaces The initial value is used as a starting point for the procedure. The algorithm continues until the time of interest is reached in the unknown function. Due to its large time step, the final answer is really far-off from the expected result.}}{16}{figure.caption.17}% -\contentsline {figure}{\numberline {2.11}{\ignorespaces In Haskell, the \texttt {type} keyword works for alias. The first draft of the \texttt {CT} type is a \textit {function}, in which providing a floating point value as time returns another value as outcome.}}{16}{figure.caption.18}% -\contentsline {figure}{\numberline {2.12}{\ignorespaces The \texttt {Parameters} type represents a given moment in time, carrying over all the necessary information to execute a solver step until the time limit is reached. Some useful typeclasses are being derived to these types, given that Haskell is capable of inferring the implementation of typeclasses in simple cases.}}{17}{figure.caption.19}% -\contentsline {figure}{\numberline {2.13}{\ignorespaces The \texttt {CT} type is a function of from time related information to an arbitrary potentially effectful outcome value.}}{18}{figure.caption.20}% -\contentsline {figure}{\numberline {2.14}{\ignorespaces The \texttt {CT} type can leverage monad transformers in Haskell via \texttt {Reader} in combination with \texttt {IO}.}}{18}{figure.caption.21}% +\contentsline {figure}{\numberline {2.1}{\ignorespaces The combination of these four basic units compose any GPAC circuit (taken from~\cite {Edil2018} with permission).}}{9}{figure.caption.10}% +\contentsline {figure}{\numberline {2.2}{\ignorespaces Polynomial circuits resembles combinational circuits, in which the circuit respond instantly to changes on its inputs (taken from~\cite {Edil2018} with permission).}}{10}{figure.caption.11}% +\contentsline {figure}{\numberline {2.3}{\ignorespaces Types are not just labels; they enhance the manipulated data with new information. Their difference in shape can work as the interface for the data.}}{11}{figure.caption.12}% +\contentsline {figure}{\numberline {2.4}{\ignorespaces Functions' signatures are contracts; they purespecify which shape the input information has as well as which shape the output information will have.}}{11}{figure.caption.12}% +\contentsline {figure}{\numberline {2.5}{\ignorespaces Sum types can be understood in terms of sets, in which the members of the set are available candidates for the outer shell type. Parity and possible values in digital states are examples.}}{11}{figure.caption.13}% +\contentsline {figure}{\numberline {2.6}{\ignorespaces Product types are a combination of different sets, where you pick a representative from each one. Digital clocks' time and objects' coordinates in space are common use cases. In Haskell, a product type can be defined using a \textit {record} alongside with the constructor, where the labels for each member inside it are explicit.}}{12}{figure.caption.14}% +\contentsline {figure}{\numberline {2.7}{\ignorespaces Depending on the application, different representations of the same structure need to used due to the domain of interest and/or memory constraints.}}{13}{figure.caption.15}% +\contentsline {figure}{\numberline {2.8}{\ignorespaces The minimum requirement for the \texttt {Ord} typeclass is the $<=$ operator, meaning that the functions $<$, $<=$, $>$, $>=$, \texttt {max} and \texttt {min} are now unlocked for the type \texttt {ClockTime} after the implementation. Typeclasses can be viewed as a third dimension in a type.}}{13}{figure.caption.16}% +\contentsline {figure}{\numberline {2.9}{\ignorespaces Replacements for the validation function within a pipeline like the above are common.}}{14}{figure.caption.17}% +\contentsline {figure}{\numberline {2.10}{\ignorespaces The initial value is used as a starting point for the procedure. The algorithm continues until the time of interest is reached in the unknown function. Due to its large time step, the final answer is really far-off from the expected result.}}{15}{figure.caption.18}% +\contentsline {figure}{\numberline {2.11}{\ignorespaces In Haskell, the \texttt {type} keyword works for alias. The first draft of the \texttt {CT} type is a \textit {function}, in which providing a floating point value as time returns another value as outcome.}}{16}{figure.caption.19}% +\contentsline {figure}{\numberline {2.12}{\ignorespaces The \texttt {Parameters} type represents a given moment in time, carrying over all the necessary information to execute a solver step until the time limit is reached. Some useful typeclasses are being derived to these types, given that Haskell is capable of inferring the implementation of typeclasses in simple cases.}}{17}{figure.caption.20}% +\contentsline {figure}{\numberline {2.13}{\ignorespaces The \texttt {CT} type is a function of from time related information to an arbitrary potentially effectful outcome value.}}{17}{figure.caption.21}% +\contentsline {figure}{\numberline {2.14}{\ignorespaces The \texttt {CT} type can leverage monad transformers in Haskell via \texttt {Reader} in combination with \texttt {IO}.}}{18}{figure.caption.22}% \addvspace {10\p@ } -\contentsline {figure}{\numberline {3.1}{\ignorespaces Given a parametric record \texttt {ps} and a dynamic value \texttt {da}, the \textit {fmap} functor of the \texttt {CT} type applies the former to the latter. Because the final result is wrapped inside the \texttt {IO} shell, a second \textit {fmap} is necessary.}}{20}{figure.caption.22}% -\contentsline {figure}{\numberline {3.2}{\ignorespaces With the \texttt {Applicative} typeclass, it is possible to cope with functions inside the \texttt {CT} type. Again, the \textit {fmap} from \texttt {IO} is being used in the implementation.}}{21}{figure.caption.23}% -\contentsline {figure}{\numberline {3.3}{\ignorespaces The $>>=$ operator used in the implementation is the \textit {bind} from the \texttt {IO} shell. This indicates that when dealing with monads within monads, it is frequent to use the implementation of the internal members.}}{22}{figure.caption.24}% -\contentsline {figure}{\numberline {3.4}{\ignorespaces The typeclass \texttt {MonadIO} transforms a given value wrapped in \texttt {IO} into a different monad. In this case, the parameter \texttt {m} of the function is the output of the \texttt {CT} type.}}{22}{figure.caption.25}% -\contentsline {figure}{\numberline {3.5}{\ignorespaces The ability of lifting numerical values to the \texttt {CT} type resembles three FF-GPAC analog circuits: \texttt {Constant}, \texttt {Adder} and \texttt {Multiplier}.}}{23}{figure.caption.26}% -\contentsline {figure}{\numberline {3.6}{\ignorespaces Example of a State Machine}}{24}{figure.caption.27}% -\contentsline {figure}{\numberline {3.7}{\ignorespaces The integrator functions attend the rules of composition of FF-GPAC, whilst the \texttt {CT} and \texttt {Integrator} types match the four basic units.}}{29}{figure.caption.28}% +\contentsline {figure}{\numberline {3.1}{\ignorespaces Given a parametric record \texttt {ps} and a dynamic value \texttt {da}, the \textit {fmap} functor of the \texttt {CT} type applies the former to the latter. Because the final result is wrapped inside the \texttt {IO} shell, a second \textit {fmap} is necessary.}}{20}{figure.caption.23}% +\contentsline {figure}{\numberline {3.2}{\ignorespaces With the \texttt {Applicative} typeclass, it is possible to cope with functions inside the \texttt {CT} type. Again, the \textit {fmap} from \texttt {IO} is being used in the implementation.}}{21}{figure.caption.24}% +\contentsline {figure}{\numberline {3.3}{\ignorespaces The $>>=$ operator used in the implementation is the \textit {bind} from the \texttt {IO} shell. This indicates that when dealing with monads within monads, it is frequent to use the implementation of the internal members.}}{22}{figure.caption.25}% +\contentsline {figure}{\numberline {3.4}{\ignorespaces The typeclass \texttt {MonadIO} transforms a given value wrapped in \texttt {IO} into a different monad. In this case, the parameter \texttt {m} of the function is the output of the \texttt {CT} type.}}{22}{figure.caption.26}% +\contentsline {figure}{\numberline {3.5}{\ignorespaces The ability of lifting numerical values to the \texttt {CT} type resembles three FF-GPAC analog circuits: \texttt {Constant}, \texttt {Adder} and \texttt {Multiplier}.}}{23}{figure.caption.27}% +\contentsline {figure}{\numberline {3.6}{\ignorespaces Example of a State Machine}}{24}{figure.caption.28}% +\contentsline {figure}{\numberline {3.7}{\ignorespaces The integrator functions attend the rules of composition of FF-GPAC, whilst the \texttt {CT} and \texttt {Integrator} types match the four basic units.}}{29}{figure.caption.29}% \addvspace {10\p@ } -\contentsline {figure}{\numberline {4.1}{\ignorespaces The integrator functions are essential to create and interconnect combinational and feedback-dependent circuits.}}{33}{figure.caption.29}% -\contentsline {figure}{\numberline {4.2}{\ignorespaces The developed DSL translates a system described by differential equations to an executable model that resembles FF-GPAC's description.}}{33}{figure.caption.30}% -\contentsline {figure}{\numberline {4.3}{\ignorespaces Because the list implements the \texttt {Traversable} typeclass, it allows this type to use the \textit {traverse} and \textit {sequence} functions, in which both are related to changing the internal behaviour of the nested structures.}}{34}{figure.caption.31}% -\contentsline {figure}{\numberline {4.4}{\ignorespaces A \textit {state vector} comprises multiple state variables and requires the use of the \textit {sequence} function to sync time across all variables.}}{34}{figure.caption.32}% -\contentsline {figure}{\numberline {4.5}{\ignorespaces Execution pipeline of a model.}}{35}{figure.caption.33}% -\contentsline {figure}{\numberline {4.6}{\ignorespaces Using only FF-GPAC's basic units and their composition rules, it's possible to model the Lorenz Attractor example.}}{38}{figure.caption.34}% -\contentsline {figure}{\numberline {4.7}{\ignorespaces After \textit {createInteg}, this record is the final image of the integrator. The function \textit {initialize} gives us protecting against wrong records of the type \texttt {Parameters}, assuring it begins from the first iteration, i.e., $t_0$.}}{39}{figure.caption.35}% -\contentsline {figure}{\numberline {4.8}{\ignorespaces After \textit {readInteg}, the final floating point values is obtained by reading from memory a computation and passing to it the received parameters record. The result of this application, $v$, is the returned value.}}{40}{figure.caption.36}% -\contentsline {figure}{\numberline {4.9}{\ignorespaces The \textit {updateInteg} function only does side effects, meaning that only affects memory. The internal variable \texttt {c} is a pointer to the computation \textit {itself}, i.e., the computation being created references this exact procedure.}}{40}{figure.caption.37}% -\contentsline {figure}{\numberline {4.10}{\ignorespaces After setting up the environment, this is the final depiction of an independent variable. The reader $x$ reads the values computed by the procedure stored in memory, a second-order Runge-Kutta method in this case.}}{41}{figure.caption.38}% -\contentsline {figure}{\numberline {4.11}{\ignorespaces The Lorenz's Attractor example has a very famous butterfly shape from certain angles and constant values in the graph generated by the solution of the differential equations..}}{42}{figure.caption.39}% +\contentsline {figure}{\numberline {4.1}{\ignorespaces The integrator functions are essential to create and interconnect combinational and feedback-dependent circuits.}}{33}{figure.caption.30}% +\contentsline {figure}{\numberline {4.2}{\ignorespaces The developed DSL translates a system described by differential equations to an executable model that resembles FF-GPAC's description.}}{33}{figure.caption.31}% +\contentsline {figure}{\numberline {4.3}{\ignorespaces Because the list implements the \texttt {Traversable} typeclass, it allows this type to use the \textit {traverse} and \textit {sequence} functions, in which both are related to changing the internal behaviour of the nested structures.}}{34}{figure.caption.32}% +\contentsline {figure}{\numberline {4.4}{\ignorespaces A \textit {state vector} comprises multiple state variables and requires the use of the \textit {sequence} function to sync time across all variables.}}{35}{figure.caption.33}% +\contentsline {figure}{\numberline {4.5}{\ignorespaces Execution pipeline of a model.}}{35}{figure.caption.34}% +\contentsline {figure}{\numberline {4.6}{\ignorespaces Using only FF-GPAC's basic units and their composition rules, it's possible to model the Lorenz Attractor example.}}{38}{figure.caption.35}% +\contentsline {figure}{\numberline {4.7}{\ignorespaces After \textit {createInteg}, this record is the final image of the integrator. The function \textit {initialize} gives us protecting against wrong records of the type \texttt {Parameters}, assuring it begins from the first iteration, i.e., $t_0$.}}{39}{figure.caption.36}% +\contentsline {figure}{\numberline {4.8}{\ignorespaces After \textit {readInteg}, the final floating point values is obtained by reading from memory a computation and passing to it the received parameters record. The result of this application, $v$, is the returned value.}}{40}{figure.caption.37}% +\contentsline {figure}{\numberline {4.9}{\ignorespaces The \textit {updateInteg} function only does side effects, meaning that only affects memory. The internal variable \texttt {c} is a pointer to the computation \textit {itself}, i.e., the computation being created references this exact procedure.}}{40}{figure.caption.38}% +\contentsline {figure}{\numberline {4.10}{\ignorespaces After setting up the environment, this is the final depiction of an independent variable. The reader $x$ reads the values computed by the procedure stored in memory, a second-order Runge-Kutta method in this case.}}{41}{figure.caption.39}% +\contentsline {figure}{\numberline {4.11}{\ignorespaces The Lorenz's Attractor example has a very famous butterfly shape from certain angles and constant values in the graph generated by the solution of the differential equations..}}{42}{figure.caption.40}% \addvspace {10\p@ } -\contentsline {figure}{\numberline {5.1}{\ignorespaces During simulation, functions change the time domain to the one that better fits certain entities, such as the \texttt {Solver} and the driver. The image is heavily inspired by a figure in~\cite {Edil2017}.}}{43}{figure.caption.40}% -\contentsline {figure}{\numberline {5.2}{\ignorespaces Updated auxiliary types for the \texttt {Parameters} type.}}{45}{figure.caption.41}% -\contentsline {figure}{\numberline {5.3}{\ignorespaces Linear interpolation is being used to transition us back to the continuous domain..}}{48}{figure.caption.42}% -\contentsline {figure}{\numberline {5.4}{\ignorespaces The new \textit {updateInteg} function add linear interpolation to the pipeline when receiving a parametric record.}}{49}{figure.caption.43}% +\contentsline {figure}{\numberline {5.1}{\ignorespaces During simulation, functions change the time domain to the one that better fits certain entities, such as the \texttt {Solver} and the driver. The image is heavily inspired by a figure in~\cite {Edil2017}.}}{43}{figure.caption.41}% +\contentsline {figure}{\numberline {5.2}{\ignorespaces Updated auxiliary types for the \texttt {Parameters} type.}}{45}{figure.caption.42}% +\contentsline {figure}{\numberline {5.3}{\ignorespaces Linear interpolation is being used to transition us back to the continuous domain..}}{48}{figure.caption.43}% +\contentsline {figure}{\numberline {5.4}{\ignorespaces The new \textit {updateInteg} function add linear interpolation to the pipeline when receiving a parametric record.}}{49}{figure.caption.44}% \addvspace {10\p@ } -\contentsline {figure}{\numberline {6.1}{\ignorespaces With just a few iterations, the exponential behaviour of the implementation is already noticeable.}}{51}{figure.caption.45}% -\contentsline {figure}{\numberline {6.2}{\ignorespaces The new \textit {createInteg} function relies on interpolation composed with memoization. Also, this combination \textit {produces} results from the computation located in a different memory region, the one pointed by the \texttt {computation} pointer in the integrator.}}{57}{figure.caption.47}% -\contentsline {figure}{\numberline {6.3}{\ignorespaces The function \textit {reads} information from the caching pointer, rather than the pointer where the solvers compute the results.}}{58}{figure.caption.48}% -\contentsline {figure}{\numberline {6.4}{\ignorespaces The new \textit {updateInteg} function gives to the solver functions access to the region with the cached data.}}{59}{figure.caption.49}% -\contentsline {figure}{\numberline {6.5}{\ignorespaces Caching changes the direction of walking through the iteration axis. It also removes an entire pass through the previous iterations.}}{60}{figure.caption.50}% -\contentsline {figure}{\numberline {6.6}{\ignorespaces By using a logarithmic scale, we can see that the final implementation is performant with more than 100 million iterations in the simulation.}}{64}{figure.caption.53}% +\contentsline {figure}{\numberline {6.1}{\ignorespaces With just a few iterations, the exponential behaviour of the implementation is already noticeable.}}{51}{figure.caption.46}% +\contentsline {figure}{\numberline {6.2}{\ignorespaces The new \textit {createInteg} function relies on interpolation composed with memoization. Also, this combination \textit {produces} results from the computation located in a different memory region, the one pointed by the \texttt {computation} pointer in the integrator.}}{57}{figure.caption.48}% +\contentsline {figure}{\numberline {6.3}{\ignorespaces The function \textit {reads} information from the caching pointer, rather than the pointer where the solvers compute the results.}}{58}{figure.caption.49}% +\contentsline {figure}{\numberline {6.4}{\ignorespaces The new \textit {updateInteg} function gives to the solver functions access to the region with the cached data.}}{59}{figure.caption.50}% +\contentsline {figure}{\numberline {6.5}{\ignorespaces Caching changes the direction of walking through the iteration axis. It also removes an entire pass through the previous iterations.}}{60}{figure.caption.51}% +\contentsline {figure}{\numberline {6.6}{\ignorespaces By using a logarithmic scale, we can see that the final implementation is performant with more than 100 million iterations in the simulation.}}{64}{figure.caption.54}% \addvspace {10\p@ } -\contentsline {figure}{\numberline {7.1}{\ignorespaces Execution pipeline of a model.}}{66}{figure.caption.54}% -\contentsline {figure}{\numberline {7.2}{\ignorespaces Resettable counter in hardware, inspired by Levent's works~\cite {levent2000, levent2002}.}}{69}{figure.caption.55}% -\contentsline {figure}{\numberline {7.3}{\ignorespaces Diagram of \texttt {createInteg} primitive for intuition.}}{72}{figure.caption.56}% -\contentsline {figure}{\numberline {7.4}{\ignorespaces Results of FFACT are similar to the final version of FACT..}}{75}{figure.caption.57}% -\contentsline {figure}{\numberline {7.5}{\ignorespaces Comparison of the Lorenz Attractor Model between FFACT and a Simulink implementation~\cite {Simulink}.}}{76}{figure.caption.58}% -\contentsline {figure}{\numberline {7.6}{\ignorespaces Comparison of the Lorenz Attractor Model between FFACT and a Matlab implementation.}}{76}{figure.caption.59}% -\contentsline {figure}{\numberline {7.7}{\ignorespaces Comparison of the Lorenz Attractor Model between FFACT and a Mathematica implementation.}}{77}{figure.caption.60}% -\contentsline {figure}{\numberline {7.8}{\ignorespaces Comparison of the Lorenz Attractor Model between FFACT and a Yampa implementation.}}{77}{figure.caption.61}% +\contentsline {figure}{\numberline {7.1}{\ignorespaces Execution pipeline of a model.}}{66}{figure.caption.55}% +\contentsline {figure}{\numberline {7.2}{\ignorespaces Resettable counter in hardware, inspired by Levent's works~\cite {levent2000, levent2002}.}}{69}{figure.caption.56}% +\contentsline {figure}{\numberline {7.3}{\ignorespaces Diagram of \texttt {createInteg} primitive for intuition.}}{72}{figure.caption.57}% +\contentsline {figure}{\numberline {7.4}{\ignorespaces Results of FFACT are similar to the final version of FACT..}}{75}{figure.caption.58}% +\contentsline {figure}{\numberline {7.5}{\ignorespaces Comparison of the Lorenz Attractor Model between FFACT and a Simulink implementation~\cite {Simulink}.}}{76}{figure.caption.59}% +\contentsline {figure}{\numberline {7.6}{\ignorespaces Comparison of the Lorenz Attractor Model between FFACT and a Matlab implementation.}}{76}{figure.caption.60}% +\contentsline {figure}{\numberline {7.7}{\ignorespaces Comparison of the Lorenz Attractor Model between FFACT and a Mathematica implementation.}}{77}{figure.caption.61}% +\contentsline {figure}{\numberline {7.8}{\ignorespaces Comparison of the Lorenz Attractor Model between FFACT and a Yampa implementation.}}{77}{figure.caption.62}% \addvspace {10\p@ } \addvspace {10\p@ } \babel@toc {american}{}\relax diff --git a/doc/MastersThesis/thesis.toc b/doc/MastersThesis/thesis.toc index beb0bee..d65bee7 100644 --- a/doc/MastersThesis/thesis.toc +++ b/doc/MastersThesis/thesis.toc @@ -4,14 +4,14 @@ \contentsline {chapter}{\numberline {1}Introduction}{1}{chapter.1}% \contentsline {section}{\numberline {1.1}Contribution}{2}{section.1.1}% \contentsline {subsection}{\numberline {1.1.1}Executable Simulation}{3}{subsection.1.1.1}% -\contentsline {subsection}{\numberline {1.1.2}Formal Foundation}{4}{subsection.1.1.2}% -\contentsline {subsection}{\numberline {1.1.3}Conciseness}{5}{subsection.1.1.3}% -\contentsline {section}{\numberline {1.2}Outline}{6}{section.1.2}% +\contentsline {subsection}{\numberline {1.1.2}GPAC: inspiration for a Formal Model}{4}{subsection.1.1.2}% +\contentsline {subsection}{\numberline {1.1.3}Expressiveness and Conciseness}{6}{subsection.1.1.3}% +\contentsline {section}{\numberline {1.2}Outline}{7}{section.1.2}% \contentsline {chapter}{\numberline {2}Design Philosophy}{8}{chapter.2}% \contentsline {section}{\numberline {2.1}Shannon's Foundation: GPAC}{8}{section.2.1}% \contentsline {section}{\numberline {2.2}The Shape of Information}{10}{section.2.2}% \contentsline {section}{\numberline {2.3}Modeling Reality}{14}{section.2.3}% -\contentsline {section}{\numberline {2.4}Making Mathematics Cyber}{16}{section.2.4}% +\contentsline {section}{\numberline {2.4}Making Mathematics Cyber}{15}{section.2.4}% \contentsline {chapter}{\numberline {3}Effectful Integrals}{19}{chapter.3}% \contentsline {section}{\numberline {3.1}Uplifting the CT Type}{19}{section.3.1}% \contentsline {section}{\numberline {3.2}GPAC Bind I: CT}{22}{section.3.2}% @@ -40,14 +40,20 @@ \contentsline {section}{\numberline {7.4}Tweak IV: Fixing FACT}{71}{section.7.4}% \contentsline {section}{\numberline {7.5}Examples and Comparisons}{75}{section.7.5}% \contentsline {chapter}{\numberline {8}Conclusion}{78}{chapter.8}% -\contentsline {section}{\numberline {8.1}Final Thoughts}{78}{section.8.1}% -\contentsline {section}{\numberline {8.2}Future Work}{79}{section.8.2}% -\contentsline {subsection}{\numberline {8.2.1}Formalism}{79}{subsection.8.2.1}% -\contentsline {subsection}{\numberline {8.2.2}Extensions}{80}{subsection.8.2.2}% -\contentsline {subsection}{\numberline {8.2.3}Refactoring}{80}{subsection.8.2.3}% -\contentsline {chapter}{\numberline {9}Appendix}{82}{chapter.9}% -\contentsline {section}{\numberline {9.1}Literate Programming}{82}{section.9.1}% -\contentsline {chapter}{References}{84}{section*.62}% +\contentsline {section}{\numberline {8.1}Future Work}{79}{section.8.1}% +\contentsline {subsection}{\numberline {8.1.1}Formalism}{79}{subsection.8.1.1}% +\contentsline {subsection}{\numberline {8.1.2}Extensions}{79}{subsection.8.1.2}% +\contentsline {subsection}{\numberline {8.1.3}Refactoring}{80}{subsection.8.1.3}% +\contentsline {chapter}{\numberline {9}Appendix}{81}{chapter.9}% +\contentsline {section}{\numberline {9.1}Literate Programming}{81}{section.9.1}% +\contentsline {section}{\numberline {9.2}FFACT's Manual}{82}{section.9.2}% +\contentsline {subsection}{\numberline {9.2.1}Models}{82}{subsection.9.2.1}% +\contentsline {subsection}{\numberline {9.2.2}Solver}{82}{subsection.9.2.2}% +\contentsline {subsection}{\numberline {9.2.3}Simulation}{83}{subsection.9.2.3}% +\contentsline {subsection}{\numberline {9.2.4}Interpolation}{83}{subsection.9.2.4}% +\contentsline {subsection}{\numberline {9.2.5}Caching}{83}{subsection.9.2.5}% +\contentsline {subsection}{\numberline {9.2.6}Example}{84}{subsection.9.2.6}% +\contentsline {chapter}{References}{85}{section*.63}% \babel@toc {american}{}\relax \babel@toc {american}{}\relax \babel@toc {american}{}\relax diff --git a/doc/README.md b/doc/README.md new file mode 100644 index 0000000..93c0171 --- /dev/null +++ b/doc/README.md @@ -0,0 +1,101 @@ +# FFACT's Manual + +This is a concise and pragmatic manual on how to create and run simulations using `FFACT`. For a deeper and more detailed description +of the internals of the DSL, including a walkthrough via examples, please consult (and generate via `literate.sh`) either `GraduationThesis` (for `FACT`) or `MasterThesis` (for `FFACT`). + +## Models + +A simulation model is defined using `mdo-notation` (check [recursive do](https://ghc.gitlab.haskell.org/ghc/doc/users_guide/exts/recursive_do.html)) to describe a system of _differential equations_. The current version of `FFACT` only supports +continuous simulations, i.e., discrete or hybrid simulations are future work. Alongside the equations, one must provide _initial conditions_ for +each individual equation, such as the following: + +```haskell +lorenzModel :: Model [Double] +lorenzModel = mdo + x <- integ (sigma * (y - x)) 1.0 + y <- integ (x * (rho - z) - y) 1.0 + z <- integ (x * y - beta * z) 1.0 + let sigma = 10.0 + rho = 28.0 + beta = 8.0 / 3.0 + return $ sequence [x, y, z] +``` + +In this example, `lorenzModel` will return the state variables of interest via a list, hence the model having the type `Model [Double]`. +Recursive monadic bindings are possible due to `mdo`, which makes the description of a model in code closer to its mathematical counterpart. + +## Solver + +Solver-specific configurations, e.g., which numerical method should be used and with which _time step_, which solver stage should it start with, +are configured **separately** from the model and from executing a simulation. This sort of configuration details are set via a separate record, such as the following: + +```haskell +lorenzSolver = Solver { dt = 1, + method = RungeKutta2, + stage = SolverStage 0 + } +``` + +Available numerical methods: +- `Euler` +- `RungeKutta2` +- `RungeKutta4` + +## Simulation + +A model and a record with solver's configuration are some of the _arguments_ to a _driver function_. A driver function runs the simulation starting from 0 until +a provided timestamp (in seconds). Currently, `runCTFinal` outputs the final result of the system +at the provided final time and `runCT` outputs a **list** of intermediate values from the start +until the provided final time spaced by the time step within the solver's configuration. +The type signatures of these functions are the following (`Double` is the final time of choice): + +```haskell +runCTFinal :: Model a -> Double -> Solver -> IO a +runCT :: Model a -> Double -> Solver -> IO [a] +``` + +## Interpolation + +Both `FACT` and `FFACT` use **linear interpolation** to approximate results in requested timestamps that are not reachable via the chosen time step within +the solver's configuration. Driver functions automatically take care of detecting and running interpolations. +The type signature of the provided interpolation function (and probably future extensions) is the following: + +```haskell +interpolate :: CT Double -> CT Double +``` + +## Caching + +Both `FACT` and `FFACT` employ a **memoization strategy** for caching, in order to speed up the simulation execution. Without this, simulations recompute previously +computed values multiple times, due to the recursive nature of the numerical methods available. A table is saved in memory with already calculated values, and lookups +are done instead of triggering a new computation. +The type signature of the provided memoization function (and probably future extensions) is the following: + +```haskell +memo :: UMemo e => (CT e -> CT e) -> CT e -> CT (CT e) +``` + +The typeclass `UMemo` is provided custom typeclass. + +## Example + +Lorenz Attractor complete example: + +```haskell +lorenzModel :: Model [Double] +lorenzModel = mdo + x <- integ (sigma * (y - x)) 1.0 + y <- integ (x * (rho - z) - y) 1.0 + z <- integ (x * y - beta * z) 1.0 + let sigma = 10.0 + rho = 28.0 + beta = 8.0 / 3.0 + return $ sequence [x, y, z] + +lorenzSolver = Solver { dt = 1, + method = RungeKutta2, + stage = SolverStage 0 + } + +lorenz = runCTFinal lorenzModel 100 lorenzSolver +``` diff --git a/fact.cabal b/fact.cabal index a6a024c..3a15474 100644 --- a/fact.cabal +++ b/fact.cabal @@ -1,11 +1,5 @@ cabal-version: 1.12 --- This file has been generated from package.yaml by hpack version 0.35.2. --- --- see: https://github.com/sol/hpack --- --- hash: 38629f5b144697a3d779463747106f533252dca73ca44e2fe1e3338225eb8e66 - name: fact version: 0.1.0.0 description: Please see the README on GitHub at @@ -13,13 +7,11 @@ homepage: https://github.com/git@github.com:FP-Modeling/fact.git#readme bug-reports: https://github.com/git@github.com:FP-Modeling/fact.git/issues author: Eduardo Lemos Rocha maintainer: dudulr10@gmail.com -copyright: 2022 EduardoLR10 -license: MIT +copyright: 2025 EduardoLR10 license-file: LICENSE build-type: Simple extra-source-files: README.md - ChangeLog.md source-repository head type: git diff --git a/src/Benchmarks.hs b/src/Benchmarks.hs index c4d8a26..802ad9f 100644 --- a/src/Benchmarks.hs +++ b/src/Benchmarks.hs @@ -1,3 +1,42 @@ +-- Copyright (c) 2021-2025 Eduardo Lemos , Edil Medeiros +-- +-- All rights reserved. +-- +-- Redistribution and use in source and binary forms, with or without +-- modification, are permitted provided that the following conditions +-- are met: +-- +-- 1. Redistributions of source code must retain the above copyright +-- notice, this list of conditions and the following disclaimer. +-- +-- 2. Redistributions in binary form must reproduce the above copyright +-- notice, this list of conditions and the following disclaimer in the +-- documentation and/or other materials provided with the distribution. +-- +-- 3. Neither the name of the author nor the names of his contributors +-- may be used to endorse or promote products derived from this software +-- without specific prior written permission. +-- +-- THIS SOFTWARE IS PROVIDED BY THE AUTHORS ``AS IS'' AND +-- ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE +-- IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE +-- ARE DISCLAIMED. IN NO EVENT SHALL THE AUTHORS OR CONTRIBUTORS BE LIABLE +-- FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL +-- DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS +-- OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) +-- HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT +-- LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY +-- OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF +-- SUCH DAMAGE. + +-- | +-- Module : Benchmarks +-- Copyright : Copyright (c) 2025, Eduardo Lemos , Edil Medeiros +-- License : BSD3 +-- Maintainer : Eduardo Lemos Rocha +-- Stability : stable +-- Tested with: GHC 9.6.6 +-- | module Benchmarks where import Examples.ChemicalReaction diff --git a/src/CT.hs b/src/CT.hs index 316328b..57c3694 100644 --- a/src/CT.hs +++ b/src/CT.hs @@ -1,4 +1,5 @@ -- Copyright (c) 2009, 2010, 2011 David Sorokin +-- Copyright (c) 2021-2025 Eduardo Lemos , Edil Medeiros -- -- All rights reserved. -- @@ -31,11 +32,11 @@ -- | -- Module : CT --- Copyright : Copyright (c) 2009-2011, David Sorokin +-- Copyright : Copyright (c) 2025, Eduardo Lemos , Edil Medeiros -- License : BSD3 -- Maintainer : Eduardo Lemos Rocha -- Stability : stable --- Tested with: GHC 8.10.7 +-- Tested with: GHC 9.6.6 -- | {-# LANGUAGE FlexibleInstances #-} module CT diff --git a/src/Driver.hs b/src/Driver.hs index efc0ccf..586793c 100644 --- a/src/Driver.hs +++ b/src/Driver.hs @@ -1,3 +1,43 @@ +-- Copyright (c) 2009, 2010, 2011 David Sorokin +-- Copyright (c) 2021-2025 Eduardo Lemos , Edil Medeiros +-- +-- All rights reserved. +-- +-- Redistribution and use in source and binary forms, with or without +-- modification, are permitted provided that the following conditions +-- are met: +-- +-- 1. Redistributions of source code must retain the above copyright +-- notice, this list of conditions and the following disclaimer. +-- +-- 2. Redistributions in binary form must reproduce the above copyright +-- notice, this list of conditions and the following disclaimer in the +-- documentation and/or other materials provided with the distribution. +-- +-- 3. Neither the name of the author nor the names of his contributors +-- may be used to endorse or promote products derived from this software +-- without specific prior written permission. +-- +-- THIS SOFTWARE IS PROVIDED BY THE AUTHORS ``AS IS'' AND +-- ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE +-- IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE +-- ARE DISCLAIMED. IN NO EVENT SHALL THE AUTHORS OR CONTRIBUTORS BE LIABLE +-- FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL +-- DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS +-- OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) +-- HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT +-- LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY +-- OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF +-- SUCH DAMAGE. + +-- | +-- Module : Driver +-- Copyright : Copyright (c) 2025, Eduardo Lemos , Edil Medeiros +-- License : BSD3 +-- Maintainer : Eduardo Lemos Rocha +-- Stability : stable +-- Tested with: GHC 9.6.6 +-- | module Driver where import CT diff --git a/src/Examples/ChemicalReaction.hs b/src/Examples/ChemicalReaction.hs index 008c39c..a410bc8 100644 --- a/src/Examples/ChemicalReaction.hs +++ b/src/Examples/ChemicalReaction.hs @@ -1,3 +1,43 @@ +-- Copyright (c) 2009, 2010, 2011 David Sorokin +-- Copyright (c) 2021-2025 Eduardo Lemos , Edil Medeiros +-- +-- All rights reserved. +-- +-- Redistribution and use in source and binary forms, with or without +-- modification, are permitted provided that the following conditions +-- are met: +-- +-- 1. Redistributions of source code must retain the above copyright +-- notice, this list of conditions and the following disclaimer. +-- +-- 2. Redistributions in binary form must reproduce the above copyright +-- notice, this list of conditions and the following disclaimer in the +-- documentation and/or other materials provided with the distribution. +-- +-- 3. Neither the name of the author nor the names of his contributors +-- may be used to endorse or promote products derived from this software +-- without specific prior written permission. +-- +-- THIS SOFTWARE IS PROVIDED BY THE AUTHORS ``AS IS'' AND +-- ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE +-- IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE +-- ARE DISCLAIMED. IN NO EVENT SHALL THE AUTHORS OR CONTRIBUTORS BE LIABLE +-- FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL +-- DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS +-- OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) +-- HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT +-- LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY +-- OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF +-- SUCH DAMAGE. + +-- | +-- Module : Examples.ChemicalReaction +-- Copyright : Copyright (c) 2025, Eduardo Lemos , Edil Medeiros +-- License : BSD3 +-- Maintainer : Eduardo Lemos Rocha +-- Stability : stable +-- Tested with: GHC 9.6.6 +-- | module Examples.ChemicalReaction where import Driver diff --git a/src/Examples/HierarchicalLorenz.hs b/src/Examples/HierarchicalLorenz.hs index 4bf4b67..d6c12df 100644 --- a/src/Examples/HierarchicalLorenz.hs +++ b/src/Examples/HierarchicalLorenz.hs @@ -1,3 +1,42 @@ +-- Copyright (c) 2021-2025 Eduardo Lemos , Edil Medeiros +-- +-- All rights reserved. +-- +-- Redistribution and use in source and binary forms, with or without +-- modification, are permitted provided that the following conditions +-- are met: +-- +-- 1. Redistributions of source code must retain the above copyright +-- notice, this list of conditions and the following disclaimer. +-- +-- 2. Redistributions in binary form must reproduce the above copyright +-- notice, this list of conditions and the following disclaimer in the +-- documentation and/or other materials provided with the distribution. +-- +-- 3. Neither the name of the author nor the names of his contributors +-- may be used to endorse or promote products derived from this software +-- without specific prior written permission. +-- +-- THIS SOFTWARE IS PROVIDED BY THE AUTHORS ``AS IS'' AND +-- ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE +-- IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE +-- ARE DISCLAIMED. IN NO EVENT SHALL THE AUTHORS OR CONTRIBUTORS BE LIABLE +-- FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL +-- DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS +-- OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) +-- HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT +-- LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY +-- OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF +-- SUCH DAMAGE. + +-- | +-- Module : Examples.HierarchicalLorenz +-- Copyright : Copyright (c) 2025, Eduardo Lemos , Edil Medeiros +-- License : BSD3 +-- Maintainer : Eduardo Lemos Rocha +-- Stability : stable +-- Tested with: GHC 9.6.6 +-- | module Examples.HierarchicalLorenz where import Driver diff --git a/src/Examples/Lorenz.hs b/src/Examples/Lorenz.hs index 225e026..a4fbda1 100644 --- a/src/Examples/Lorenz.hs +++ b/src/Examples/Lorenz.hs @@ -1,3 +1,43 @@ +-- Copyright (c) 2021-2025 Eduardo Lemos , Edil Medeiros +-- +-- All rights reserved. +-- +-- Redistribution and use in source and binary forms, with or without +-- modification, are permitted provided that the following conditions +-- are met: +-- +-- 1. Redistributions of source code must retain the above copyright +-- notice, this list of conditions and the following disclaimer. +-- +-- 2. Redistributions in binary form must reproduce the above copyright +-- notice, this list of conditions and the following disclaimer in the +-- documentation and/or other materials provided with the distribution. +-- +-- 3. Neither the name of the author nor the names of his contributors +-- may be used to endorse or promote products derived from this software +-- without specific prior written permission. +-- +-- THIS SOFTWARE IS PROVIDED BY THE AUTHORS ``AS IS'' AND +-- ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE +-- IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE +-- ARE DISCLAIMED. IN NO EVENT SHALL THE AUTHORS OR CONTRIBUTORS BE LIABLE +-- FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL +-- DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS +-- OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) +-- HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT +-- LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY +-- OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF +-- SUCH DAMAGE. + +-- | +-- Module : Examples.Lorenz +-- Copyright : Copyright (c) 2025, Eduardo Lemos , Edil Medeiros +-- License : BSD3 +-- Maintainer : Eduardo Lemos Rocha +-- Stability : stable +-- Tested with: GHC 9.6.6 +-- | + {-# LANGUAGE RecursiveDo #-} module Examples.Lorenz where diff --git a/src/Examples/Mfix.hs b/src/Examples/Mfix.hs index 43d015c..0cc9b50 100644 --- a/src/Examples/Mfix.hs +++ b/src/Examples/Mfix.hs @@ -1,3 +1,43 @@ +-- Copyright (c) 2021-2025 Eduardo Lemos , Edil Medeiros +-- +-- All rights reserved. +-- +-- Redistribution and use in source and binary forms, with or without +-- modification, are permitted provided that the following conditions +-- are met: +-- +-- 1. Redistributions of source code must retain the above copyright +-- notice, this list of conditions and the following disclaimer. +-- +-- 2. Redistributions in binary form must reproduce the above copyright +-- notice, this list of conditions and the following disclaimer in the +-- documentation and/or other materials provided with the distribution. +-- +-- 3. Neither the name of the author nor the names of his contributors +-- may be used to endorse or promote products derived from this software +-- without specific prior written permission. +-- +-- THIS SOFTWARE IS PROVIDED BY THE AUTHORS ``AS IS'' AND +-- ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE +-- IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE +-- ARE DISCLAIMED. IN NO EVENT SHALL THE AUTHORS OR CONTRIBUTORS BE LIABLE +-- FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL +-- DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS +-- OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) +-- HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT +-- LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY +-- OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF +-- SUCH DAMAGE. + +-- | +-- Module : Examples.Mfix +-- Copyright : Copyright (c) 2025, Eduardo Lemos , Edil Medeiros +-- License : BSD3 +-- Maintainer : Eduardo Lemos Rocha +-- Stability : stable +-- Tested with: GHC 9.6.6 +-- | + {-# LANGUAGE RecursiveDo #-} module Examples.Mfix where diff --git a/src/Examples/Sine.hs b/src/Examples/Sine.hs index db06812..73b3b6e 100644 --- a/src/Examples/Sine.hs +++ b/src/Examples/Sine.hs @@ -1,3 +1,44 @@ +-- Copyright (c) 2021-2025 Eduardo Lemos , Edil Medeiros +-- +-- All rights reserved. +-- +-- Redistribution and use in source and binary forms, with or without +-- modification, are permitted provided that the following conditions +-- are met: +-- +-- 1. Redistributions of source code must retain the above copyright +-- notice, this list of conditions and the following disclaimer. +-- +-- 2. Redistributions in binary form must reproduce the above copyright +-- notice, this list of conditions and the following disclaimer in the +-- documentation and/or other materials provided with the distribution. +-- +-- 3. Neither the name of the author nor the names of his contributors +-- may be used to endorse or promote products derived from this software +-- without specific prior written permission. +-- +-- THIS SOFTWARE IS PROVIDED BY THE AUTHORS ``AS IS'' AND +-- ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE +-- IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE +-- ARE DISCLAIMED. IN NO EVENT SHALL THE AUTHORS OR CONTRIBUTORS BE LIABLE +-- FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL +-- DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS +-- OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) +-- HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT +-- LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY +-- OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF +-- SUCH DAMAGE. + +-- | +-- Module : Examples.Sine +-- Copyright : Copyright (c) 2025, Eduardo Lemos , Edil Medeiros +-- License : BSD3 +-- Maintainer : Eduardo Lemos Rocha +-- Stability : stable +-- Tested with: GHC 9.6.6 +-- | + +{-# LANGUAGE RecursiveDo #-} module Examples.Sine where import Driver @@ -19,10 +60,15 @@ sineModel = integZ <- createInteg 1 let y = readInteg integY z = readInteg integZ - kz = -1 updateInteg integY z - updateInteg integZ (kz * y) + updateInteg integZ (-y) return $ sequence [y, z] +sineModel2 :: Model [Double] +sineModel2 = + mdo y <- integ z 0 + z <- integ (-y) 1 + return $ sequence [y, z] + sine = runCTFinal sineModel 15 sineSolv diff --git a/src/Examples/Test.hs b/src/Examples/Test.hs index e4be2e7..b6cbab9 100644 --- a/src/Examples/Test.hs +++ b/src/Examples/Test.hs @@ -1,3 +1,43 @@ +-- Copyright (c) 2021-2025 Eduardo Lemos , Edil Medeiros +-- +-- All rights reserved. +-- +-- Redistribution and use in source and binary forms, with or without +-- modification, are permitted provided that the following conditions +-- are met: +-- +-- 1. Redistributions of source code must retain the above copyright +-- notice, this list of conditions and the following disclaimer. +-- +-- 2. Redistributions in binary form must reproduce the above copyright +-- notice, this list of conditions and the following disclaimer in the +-- documentation and/or other materials provided with the distribution. +-- +-- 3. Neither the name of the author nor the names of his contributors +-- may be used to endorse or promote products derived from this software +-- without specific prior written permission. +-- +-- THIS SOFTWARE IS PROVIDED BY THE AUTHORS ``AS IS'' AND +-- ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE +-- IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE +-- ARE DISCLAIMED. IN NO EVENT SHALL THE AUTHORS OR CONTRIBUTORS BE LIABLE +-- FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL +-- DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS +-- OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) +-- HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT +-- LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY +-- OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF +-- SUCH DAMAGE. + +-- | +-- Module : Examples.Test +-- Copyright : Copyright (c) 2025, Eduardo Lemos , Edil Medeiros +-- License : BSD3 +-- Maintainer : Eduardo Lemos Rocha +-- Stability : stable +-- Tested with: GHC 9.6.6 +-- | + {-# LANGUAGE RecordWildCards #-} {-# LANGUAGE RankNTypes #-} {-# LANGUAGE TupleSections #-} diff --git a/src/IO.hs b/src/IO.hs index 052f481..e0f11cb 100644 --- a/src/IO.hs +++ b/src/IO.hs @@ -1,3 +1,42 @@ +-- Copyright (c) 2021-2025 Eduardo Lemos , Edil Medeiros +-- +-- All rights reserved. +-- +-- Redistribution and use in source and binary forms, with or without +-- modification, are permitted provided that the following conditions +-- are met: +-- +-- 1. Redistributions of source code must retain the above copyright +-- notice, this list of conditions and the following disclaimer. +-- +-- 2. Redistributions in binary form must reproduce the above copyright +-- notice, this list of conditions and the following disclaimer in the +-- documentation and/or other materials provided with the distribution. +-- +-- 3. Neither the name of the author nor the names of his contributors +-- may be used to endorse or promote products derived from this software +-- without specific prior written permission. +-- +-- THIS SOFTWARE IS PROVIDED BY THE AUTHORS ``AS IS'' AND +-- ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE +-- IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE +-- ARE DISCLAIMED. IN NO EVENT SHALL THE AUTHORS OR CONTRIBUTORS BE LIABLE +-- FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL +-- DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS +-- OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) +-- HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT +-- LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY +-- OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF +-- SUCH DAMAGE. + +-- | +-- Module : IO +-- Copyright : Copyright (c) 2025, Eduardo Lemos , Edil Medeiros +-- License : BSD3 +-- Maintainer : Eduardo Lemos Rocha +-- Stability : stable +-- Tested with: GHC 9.6.6 +-- | module IO where import System.IO diff --git a/src/Integrator.hs b/src/Integrator.hs index 1177333..5d13033 100644 --- a/src/Integrator.hs +++ b/src/Integrator.hs @@ -1,3 +1,43 @@ +-- Copyright (c) 2009-2018 David Sorokin +-- Copyright (c) 2021-2025 Eduardo Lemos , Edil Medeiros +-- +-- All rights reserved. +-- +-- Redistribution and use in source and binary forms, with or without +-- modification, are permitted provided that the following conditions +-- are met: +-- +-- 1. Redistributions of source code must retain the above copyright +-- notice, this list of conditions and the following disclaimer. +-- +-- 2. Redistributions in binary form must reproduce the above copyright +-- notice, this list of conditions and the following disclaimer in the +-- documentation and/or other materials provided with the distribution. +-- +-- 3. Neither the name of the author nor the names of his contributors +-- may be used to endorse or promote products derived from this software +-- without specific prior written permission. +-- +-- THIS SOFTWARE IS PROVIDED BY THE AUTHORS ``AS IS'' AND +-- ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE +-- IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE +-- ARE DISCLAIMED. IN NO EVENT SHALL THE AUTHORS OR CONTRIBUTORS BE LIABLE +-- FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL +-- DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS +-- OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) +-- HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT +-- LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY +-- OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF +-- SUCH DAMAGE. + +-- | +-- Module : Integrator +-- Copyright : Copyright (c) 2025, Eduardo Lemos , Edil Medeiros +-- License : BSD3 +-- Maintainer : Eduardo Lemos Rocha +-- Stability : stable +-- Tested with: GHC 9.6.6 +-- | {-# LANGUAGE BangPatterns #-} {-# LANGUAGE RecursiveDo #-} module Integrator where diff --git a/src/Interpolation.hs b/src/Interpolation.hs index fd8da70..4dafa2a 100644 --- a/src/Interpolation.hs +++ b/src/Interpolation.hs @@ -1,3 +1,43 @@ +-- Copyright (c) 2009, 2010, 2011 David Sorokin +-- Copyright (c) 2021-2025 Eduardo Lemos , Edil Medeiros +-- +-- All rights reserved. +-- +-- Redistribution and use in source and binary forms, with or without +-- modification, are permitted provided that the following conditions +-- are met: +-- +-- 1. Redistributions of source code must retain the above copyright +-- notice, this list of conditions and the following disclaimer. +-- +-- 2. Redistributions in binary form must reproduce the above copyright +-- notice, this list of conditions and the following disclaimer in the +-- documentation and/or other materials provided with the distribution. +-- +-- 3. Neither the name of the author nor the names of his contributors +-- may be used to endorse or promote products derived from this software +-- without specific prior written permission. +-- +-- THIS SOFTWARE IS PROVIDED BY THE AUTHORS ``AS IS'' AND +-- ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE +-- IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE +-- ARE DISCLAIMED. IN NO EVENT SHALL THE AUTHORS OR CONTRIBUTORS BE LIABLE +-- FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL +-- DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS +-- OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) +-- HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT +-- LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY +-- OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF +-- SUCH DAMAGE. + +-- | +-- Module : Interpolation +-- Copyright : Copyright (c) 2025, Eduardo Lemos , Edil Medeiros +-- License : BSD3 +-- Maintainer : Eduardo Lemos Rocha +-- Stability : stable +-- Tested with: GHC 9.6.6 +-- | module Interpolation where import CT ( Parameters(solver, interval, time, iteration), CT ) diff --git a/src/Memo.hs b/src/Memo.hs index 39dccae..d55288c 100644 --- a/src/Memo.hs +++ b/src/Memo.hs @@ -1,3 +1,43 @@ +-- Copyright (c) 2009, 2010, 2011 David Sorokin +-- Copyright (c) 2021-2025 Eduardo Lemos , Edil Medeiros +-- +-- All rights reserved. +-- +-- Redistribution and use in source and binary forms, with or without +-- modification, are permitted provided that the following conditions +-- are met: +-- +-- 1. Redistributions of source code must retain the above copyright +-- notice, this list of conditions and the following disclaimer. +-- +-- 2. Redistributions in binary form must reproduce the above copyright +-- notice, this list of conditions and the following disclaimer in the +-- documentation and/or other materials provided with the distribution. +-- +-- 3. Neither the name of the author nor the names of his contributors +-- may be used to endorse or promote products derived from this software +-- without specific prior written permission. +-- +-- THIS SOFTWARE IS PROVIDED BY THE AUTHORS ``AS IS'' AND +-- ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE +-- IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE +-- ARE DISCLAIMED. IN NO EVENT SHALL THE AUTHORS OR CONTRIBUTORS BE LIABLE +-- FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL +-- DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS +-- OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) +-- HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT +-- LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY +-- OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF +-- SUCH DAMAGE. + +-- | +-- Module : Memo +-- Copyright : Copyright (c) 2025, Eduardo Lemos , Edil Medeiros +-- License : BSD3 +-- Maintainer : Eduardo Lemos Rocha +-- Stability : stable +-- Tested with: GHC 9.6.6 +-- | {-# LANGUAGE FlexibleContexts, FlexibleInstances, UndecidableInstances, ConstraintKinds, MonoLocalBinds #-} module Memo where diff --git a/src/Simulation.hs b/src/Simulation.hs index 79ab1cd..91d6bf7 100644 --- a/src/Simulation.hs +++ b/src/Simulation.hs @@ -1,3 +1,43 @@ +-- Copyright (c) 2009, 2010, 2011 David Sorokin +-- Copyright (c) 2021-2025 Eduardo Lemos , Edil Medeiros +-- +-- All rights reserved. +-- +-- Redistribution and use in source and binary forms, with or without +-- modification, are permitted provided that the following conditions +-- are met: +-- +-- 1. Redistributions of source code must retain the above copyright +-- notice, this list of conditions and the following disclaimer. +-- +-- 2. Redistributions in binary form must reproduce the above copyright +-- notice, this list of conditions and the following disclaimer in the +-- documentation and/or other materials provided with the distribution. +-- +-- 3. Neither the name of the author nor the names of his contributors +-- may be used to endorse or promote products derived from this software +-- without specific prior written permission. +-- +-- THIS SOFTWARE IS PROVIDED BY THE AUTHORS ``AS IS'' AND +-- ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE +-- IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE +-- ARE DISCLAIMED. IN NO EVENT SHALL THE AUTHORS OR CONTRIBUTORS BE LIABLE +-- FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL +-- DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS +-- OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) +-- HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT +-- LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY +-- OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF +-- SUCH DAMAGE. + +-- | +-- Module : Simulation +-- Copyright : Copyright (c) 2025, Eduardo Lemos , Edil Medeiros +-- License : BSD3 +-- Maintainer : Eduardo Lemos Rocha +-- Stability : stable +-- Tested with: GHC 9.6.6 +-- | module Simulation where import Types ( Iteration, TimeStep ) diff --git a/src/Solver.hs b/src/Solver.hs index b63ab54..0088605 100644 --- a/src/Solver.hs +++ b/src/Solver.hs @@ -1,3 +1,43 @@ +-- Copyright (c) 2009, 2010, 2011 David Sorokin +-- Copyright (c) 2021-2025 Eduardo Lemos , Edil Medeiros +-- +-- All rights reserved. +-- +-- Redistribution and use in source and binary forms, with or without +-- modification, are permitted provided that the following conditions +-- are met: +-- +-- 1. Redistributions of source code must retain the above copyright +-- notice, this list of conditions and the following disclaimer. +-- +-- 2. Redistributions in binary form must reproduce the above copyright +-- notice, this list of conditions and the following disclaimer in the +-- documentation and/or other materials provided with the distribution. +-- +-- 3. Neither the name of the author nor the names of his contributors +-- may be used to endorse or promote products derived from this software +-- without specific prior written permission. +-- +-- THIS SOFTWARE IS PROVIDED BY THE AUTHORS ``AS IS'' AND +-- ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE +-- IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE +-- ARE DISCLAIMED. IN NO EVENT SHALL THE AUTHORS OR CONTRIBUTORS BE LIABLE +-- FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL +-- DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS +-- OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) +-- HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT +-- LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY +-- OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF +-- SUCH DAMAGE. + +-- | +-- Module : Solver +-- Copyright : Copyright (c) 2025, Eduardo Lemos , Edil Medeiros +-- License : BSD3 +-- Maintainer : Eduardo Lemos Rocha +-- Stability : stable +-- Tested with: GHC 9.6.6 +-- | module Solver where import Types ( Iteration ) diff --git a/src/Types.hs b/src/Types.hs index 396747d..7f8142e 100644 --- a/src/Types.hs +++ b/src/Types.hs @@ -1,3 +1,42 @@ +-- Copyright (c) 2021-2025 Eduardo Lemos , Edil Medeiros +-- +-- All rights reserved. +-- +-- Redistribution and use in source and binary forms, with or without +-- modification, are permitted provided that the following conditions +-- are met: +-- +-- 1. Redistributions of source code must retain the above copyright +-- notice, this list of conditions and the following disclaimer. +-- +-- 2. Redistributions in binary form must reproduce the above copyright +-- notice, this list of conditions and the following disclaimer in the +-- documentation and/or other materials provided with the distribution. +-- +-- 3. Neither the name of the author nor the names of his contributors +-- may be used to endorse or promote products derived from this software +-- without specific prior written permission. +-- +-- THIS SOFTWARE IS PROVIDED BY THE AUTHORS ``AS IS'' AND +-- ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE +-- IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE +-- ARE DISCLAIMED. IN NO EVENT SHALL THE AUTHORS OR CONTRIBUTORS BE LIABLE +-- FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL +-- DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS +-- OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) +-- HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT +-- LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY +-- OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF +-- SUCH DAMAGE. + +-- | +-- Module : Types +-- Copyright : Copyright (c) 2025, Eduardo Lemos , Edil Medeiros +-- License : BSD3 +-- Maintainer : Eduardo Lemos Rocha +-- Stability : stable +-- Tested with: GHC 9.6.6 +-- | module Types where type TimeStep = Double