Towards a formal
description of models and
workflows
Heinz A Preisig
Process Systems Engineering @ Chemical Engineering
NTNU, Trondheim, Norway
MoDeNa - FP7 ++
Computational engineering
The vision that we can predict the behaviour of
●
●
●
●
a material
a product
a process
a procedure
Materials project US : properties of over 80,000
materials and screened 25,000 of these for Li-ion
batteries ...
We can compute:
●
●
●
molecule structures based on quantum mechanic concepts
coarse-grained elements of the material in the geometrical space
compute behaviours of fluids in complex geometries
but
●
the machines are not big / fast enough
Multi-scale modelling:
Oignon approach
electronic
atomistic
microscopic
mesoscopic
macroscopic
device
-_ -_
length scale
time scale
2-3 order of magnitude per
step
Multi-scale modelling:
scale integration → surrogates
macroscopic
device
mesoscopic
& surrogate
for lower scales
length scale
time scale
2-3 order of magnitude per
step
Formulation of the mathematical
problem
object - plant, process,
material ..
problem domain:
- design
- operations
- phys props.
- structure
- mech props.
mimiced behaviour:
mathematical model
mathematical
problem
Formulation of the numerical
problem
mathematical
problem
instantiation
specific problem
numerical
problem
Finding the solution
numerical
problem
solution
Solvers:
- equation solvers
- integrators
- root solvers
- optimisers
- ….
instantiation
Current : vertical integration
For each specific problem:
● model (may be default)
● model manipulation (often not)
● instantiation (main effort)
● numerical problem (implied)
● solver instantiation (usually default)
● solution (often as number or graph)
Target structure
●
●
●
The core model is in the centre
All other models are derived
Activities form a whirlpool
○ enable interactions between paths
○ enable direct comparisons
○ enable linking sequences of activities
Models are central
Models from models from models...
Model-centered view
● Model is the centre of all activities
● Specific models are all derived from a mother model
● The mother model is derived from a generic model
● Generic model is captured in an ontology
What is an ontology
...and information science, an ontology is a formal
representation of knowledge as a set of concepts
within a domain, and the relationships between those
concepts. It is used to reason about the entities within
that domain, and may be used to describe the domain. In
theory, an ontology is a ''formal, explicit specification
of a shared conceptualisation''. An ontology provides a
shared vocabulary, which can be used to model a domain
-- that is, the type of objects and/or concepts that
exist, and their properties and relations.
(source: WikiPedia)
What are ontologies
● a formal representation of knowledge
● as a set of concepts within a domain
● relationships between those concepts
● formal, explicit specification of a shared
conceptualisation
● provides a common vocabulary
Ontologies - new ?
no more like
generating a more modern, better looking chair
Wish-list: model-based engineering
Something to:
● assemble models
build, modify & maintain
● Define my problem
● Solve my problem
● Evaluate solution
● Carry information to the next problem
Wish : Workbench →
IDE for computer-based engineering
● Ontology editor - context specific
● Graphical modelling editor → network models
● Assumptions implementation
○ Split of topologies
○ Model reduction to eliminate states
● Mathematical problem definition
● Instantiation tool
● Solver wizard
● Solver instantiation tool
● Analysis tool
○ Graphics tool for visualisation
○ Statistical analysis
● Factory tool
Constructing first section of the IDE
attribute editor
model assembler
appearance editor
graph editor
attributes
automaton editor
item info
equation editor
rules editor
structure info
rules
context editor
equations
model lib
task
rules
library
Wish-item:
Domain specific model ontology
Construct:
● network models
● basic principles (conservation → dynamics)
● augment with
○ transport, kinetic, geometry, definitions,
transformations, energy surfaces, potentials, EOS,...
● information must be build in lower-triagonal form:
start with graph & keep on adding one piece of
information at the time that may be a function of the
others
→ consistent model ontology
Ontology structure
chem eng macroscopic I
[base model]
● Graph = (nodes, arcs)
● attributes characterising nodes and arcs
● equations using attributes as index sets
○ lower triagonal, bipartite
○ superstructure (choose from alternative where
appropriate)
Ontology
list of node attributes
type
1
2
3
4
nature
physical
information
morphology
distributed
lumped
dot
dynamics
constant
dynamic
event-dynamic
token
mass
energy
momentum
information
phase
gas
liquid
solid
user spec
species
A
B
C
D
Ontology
arc attributes
type
1
2
3
4
nature
physical
information
directionality
uni-directional
bi-directional
token
mass
energy
momentum
information
mechanism
heat
vol work
mech work
el work
phase
gas
liquid
solid
user spec
species
A
B
C
D
Ontology structure
chem eng macroscopic II
[simulation]
● conditions (intensive state of the reservoirs)
● initial conditions for all dynamic parts
● time interval
● solver
● solver parameters
● solution
Ontology
equipment design
[design]
● criterion
● model as constraint
● set of conditions
● solver
● solver parameters
● solution
Equation ontology
Adding control
Wish-item:
Graphical model editor
Model assembly tool:
● support for hierarchical graph construction
○ hierarchical refinement
○ saving/loading of sub-models (complete/incomplete)
○ top-down & bottom up design
● plug-in domain-specific ontology
● adds user-interface behaviour
● adds graphic component appearance
● integrates with
○ model library
○ model reduction tool
Wish-item:
Model simplification
@ assumptions
● time-scale / length-scale assumptions
○ small/large capacity
○ small/large transfer
○ small/large transposition
● method: mostly singular perturbation
@ model reduction methods
● mathematical procedures
● method: builds on mainly superposition on ext quant.
@ automatic - only method control
Math
Order-of-magnitude assumptions
● singular perturbation → leads to equilibrium condition
● small / large capacities
B
A
● null space on fast network eliminates
A
○ fast flow
○ fast reaction
● separation of networks into fast and slow networks
○ may be done for different conserved quantities
separately
■ topology splitting
A
B
■ topology overlap
A+B
Workflows
● There is an ANSI/ISA-88 standard for unit process that
can be used as template for a task
● Tasks defines
○ numerical problems
■ instantiated model == model plus all data
■ solver and its instantiation
○ output structure and target storage
● workflow control == automaton
○ current state + input/condition
→ next action, next state
Factory: stand-alone target app
Design
● domain specific model ontology
● network model
● mathematical model
● problem instantiation - including all data
● solver
● solver instantiation @ GUI
● compile and slice instantiated model @ GUI
● assemble process/problem specific application
Result : stand-alone application with GUI
Factory: multi-physics task
Design
● all model ontologies
● all network models
● define problem @ GUI
● overall multi-physics model as network → workflows
● allocate resources for each task → generate script
● execute script
● provide results for analysis
Issue of distributed computing
●
●
●
●
generating the script (above)
large data sets (transfer data or program)
availability of programs (licences)
exception handling
○ computation error (diverging solution, zero devide…)
○ wrong solution
○ solution not feasible
○ too large / too slow
○ …
● very large dimensionality
○ are they necessary ?
○ control ?
○ adaptation ?
Thermo factory realisation
chosen chemical
system
e
v
a
l
u
a
t
o
r
c
o
d
e
data base
- experimental
- computational
approximate
properties &
derivatives
differentiation
EOS_1
EOS_1
g
e
n
U|H|G
Legendre
A
Conclusion
Main issue:
● split model generation from
○ assembling
○ coding
○ evaluation
● derive all models from a mother model
○ through adding assumptions
○ reducing model using algebra
● model libraries of finished and partial models
Conclusion
● Workbench for modelling
○ assemble individual network model
○ link network models
○ factory for stand-alone apps and multi-physics
scripts
● Software farms … ?
● Central computing centres … ?
● Distributed computing … ?
Current work:
generic multi-scale ontology
Objective or question:
Do we have
a hand-full of concepts
that cover the whole model space ?
●
●
●
●
●
Mass balance
Hamiltonian
Behaviour theory - port-Hamiltonian systems
Time-scale and length scale assumptions
Stochastic / particle vs macro / field