Closed kynan closed 13 years ago
Encapsulating the FLuidity-specific bits in a class sounds eminently sensible to me.
Each frontend needs to implement
InputParser
overriding the parse
methodUflEquation
The input parser returns an object of type UflEquation
(or of a subclass thereof), which is the only thing passed from stage to stage in the pipeline up to the final backend AST unparser. For input format with multiple equations per input file as is the the case for flml a list of objects is returned and the pipeline fed separately with each of these.
The pipeline stages input parser and string preprocessor are frontend specific, backend AST generator and backend AST unparser are backend specific.
class InputParser:
def parse(self, filename):
pass
class UflEquation:
name = ""
code = ""
namespace = {}
frontend_ast = None
objects = None
dag = None
backend_ast = None
class FluidityEquation(UflEquation):
solves = None
state = None
states = None
On the grounds of being able to use MCFC to generate code conforming to UFC from FEniCS (plain) UFL input we need to determine what part of the MCFC pipeline we designed is specific to Fluidity as the application and our custom UFL execution environment.
All pipeline stages only dealing with the kernel (and not how it is called) i.e. frontend AST generator to IR DAG Partitioner should be independent of the both the frontend and the backend. The first and last two stages are specific to Fluidity as the application. The first two create the specific execution environment, the last two use Fluidity specific properties to generate the kernel calling code.
A possible solution is encapsulating all Fluidity specific functionality in a class
FluidityEquation
derived from a common base classUflEquation
. This could be used as a container holding attributes s.a.name
,namespace
,environment
etc. and being passed from one pipeline stage to the next. Each pipeline stage would modify certain attributes of this container.