This folder contains the actual LDD simulation code. To facilitate development,
we give a briefe description of the files.
we give a brief description of the files. As the code has been written with
readability in mind, we only highlight certain methods. Other methods should be
pretty self explanatory.
## `LDDsimulation.py`
If you want to read the code, this is where you should
start.
This file defines the core and soul of the LDD simulation code.
It defines the class `LDDsimulation` that contains methods to setup the
simulation and run it. Each usecase file in `../Usecases` essentially
simulation and run it.
Each usecase file in `../Usecases` essentially
sets up an instance of this class and defines
all parameters needed by the `LDDsimulation.set_parameters(kwrgs**)` function
which gets called by the `main()` of each usecase (more precisely by
`helpers.run_simulation()`).
The `LDDsimulation.initialise()` method calls several functions that initialise
all subdomains, interfaces, meshes, markerfunctions, solution files and so on.
The `LDDsimulation.run()` method implements the timestepping and calls the solver, the `LDDsimulation.LDDsolver(**kwrgs)` method. Some postprocessing is implemented here to calculate some errors and part of the write out to disk
happens here.
The `LDDsolver` methods implements the L-iteration loop for each new timesten as well as the loop over the subdomains. The stopping criterion is implemented here aswell.
If you want to implement parallelisation, this is where it needs to happen.
Some attempts have been made to do this, but time was running short.
Some commented out code can be found here which might or might not be usefull for attempting to parallelise the code.
## `domainPatch.py`
This file contain the class definition of the `domainPatch` class which is the main data structure of the LDD simulation code.
The programming paradigm was:
_Each subdomain contains all information need and is completely independent of other subdomains._
All information means:
- the model. Each subdomain not only knows which model it assumes, it also provides the methods to construct the linear form that is given to the linear solver. This is done in the `governing_problem(*kwrgs)` method.
This has been done because the L-linearised form is considered the discretised model.
Methods in charge of communicating dofs to interfaces for exchange of information with neighbours is also implemente in this class.
- the model data: All material parameters and fucntions.
- meshes and markes: Each subdomain holds their own submesh of the global mesh including dof maps etc.
- interfaces and boundaries: Each subdomain knows which parts of the boundary are outer boundaries or interfaces to other subdomains. Interface objects are also available to each subdomain, so that communication of dofs can happen the the interface objects. (See `class boundary_and_ineterface`).
- function spaces and functions: Each subdomain stores their functionspaces as well as functions in which to store iterates.
We briefly highlight some of the methods:
-`governing_problem(*kwrgs)`:
## `boundary_and_interface.py`
...
...
@@ -35,7 +66,7 @@ the simulation class.
This was done in an attempt to tidy the usecases and have a central place in which to define data functions.
New relative permeabilites and pc-S relationships must be specified here and
the corresponding generator functions
`generate_relative_permeability_dicts` and `generate_Spc_dicts` need to be adjusted accordingly.
`generate_relative_permeability_dicts` and `generate_Spc_dicts` need to be adjusted accordingly.
