# Contents of /trunk/doc/user/escript.tex

Revision 6721 - (show annotations)
Wed Sep 26 05:58:38 2018 UTC (6 months, 3 weeks ago) by aellery
File MIME type: application/x-tex
File size: 85047 byte(s)
getNumpy now supports complex Data. I have also added a new section to the documentation (3.2.11) that describes how the getNumpy function works.


 1 2 %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% 3 % Copyright (c) 2003-2018 by The University of Queensland 4 5 % 6 % Primary Business: Queensland, Australia 7 % Licensed under the Apache License, version 2.0 8 9 % 10 % Development until 2012 by Earth Systems Science Computational Center (ESSCC) 11 % Development 2012-2013 by School of Earth Sciences 12 % Development from 2014 by Centre for Geoscience Computing (GeoComp) 13 % 14 %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% 15 16 \chapter{The \escript Module}\label{ESCRIPT CHAP} 17 18 \section{Concepts} 19 \escript is a \PYTHON module that allows you to represent the values of 20 a function at points in a \Domain in such a way that the function will 21 be useful for the Finite Element Method (FEM) simulation. It also 22 provides what we call a function space that describes how the data is 23 used in the simulation. Stored along with the data is information 24 about the elements and nodes which will be used by the domain (e.g. \finley). 25 26 \subsection{Function spaces} 27 In order to understand what we mean by the term 'function space', 28 consider that the solution of a partial differential 29 equation\index{partial differential equation} (PDE) is a function on a domain 30 $\Omega$. When solving a PDE using FEM, the solution is 31 piecewise-differentiable but, in general, its gradient is discontinuous. 32 To reflect these different degrees of smoothness, different function spaces 33 are used. 34 For instance, in FEM, the displacement field is represented by its values at 35 the nodes of the mesh, and so is continuous. 36 The strain, which is the symmetric part of the gradient of the displacement 37 field, is stored on the element centers, and so is considered to be 38 discontinuous. 39 40 A function space is described by a \FunctionSpace object. 41 The following statement generates the object \var{solution_space} which is 42 a \FunctionSpace object and provides access to the function space of 43 PDE solutions on the \Domain \var{mydomain}: 44 45 \begin{python} 46 solution_space=Solution(mydomain) 47 \end{python} 48 The following generators for function spaces on a \Domain \var{mydomain} are commonly used: 49 \begin{itemize} 50 \item \var{Solution(mydomain)}: solutions of a PDE 51 \item \var{ReducedSolution(mydomain)}: solutions of a PDE with a reduced 52 smoothness requirement, e.g. using a lower order approximation on the same 53 element or using macro elements\index{macro elements} 54 \item \var{ContinuousFunction(mydomain)}: continuous functions, e.g. a temperature distribution 55 \item \var{Function(mydomain)}: general functions which are not necessarily continuous, e.g. a stress field 56 \item \var{FunctionOnBoundary(mydomain)}: functions on the boundary of the domain, e.g. a surface pressure 57 \item \var{DiracDeltaFunctions(mydomain)}: functions defined on a set of points 58 \item \var{FunctionOnContact0(mydomain)}: functions on side $0$ of a discontinuity 59 \item \var{FunctionOnContact1(mydomain)}: functions on side $1$ of a discontinuity 60 \end{itemize} 61 In some cases under-integration is used. For these cases the user may use a 62 \FunctionSpace from the following list: 63 \begin{itemize} 64 \item \var{ReducedFunction(mydomain)} 65 \item \var{ReducedFunctionOnBoundary(mydomain)} 66 \item \var{ReducedFunctionOnContact0(mydomain)} 67 \item \var{ReducedFunctionOnContact1(mydomain)} 68 \end{itemize} 69 In comparison to the corresponding full version they use a reduced number of 70 integration nodes (typically one only) to represent values. 71 72 \begin{figure} 73 \centering 74 \scalebox{0.97}{\includegraphics{EscriptDiagram1}} 75 \caption{\label{ESCRIPT DEP}Dependency of function spaces in \finley. 76 An arrow indicates that a function in the \FunctionSpace at the starting point 77 can be interpolated to the \FunctionSpace of the arrow target. 78 All function spaces above the dotted line can be interpolated to any of 79 the function spaces below the line. See also \Sec{SEC Projection}.} 80 \end{figure} 81 82 The reduced smoothness for a PDE solution is often used to fulfill the 83 Ladyzhenskaya-Babuska-Brezzi condition~\cite{LBB} when solving saddle point 84 problems\index{saddle point problems}, e.g. the Stokes equation. 85 A discontinuity\index{discontinuity} is a region within the domain across 86 which functions may be discontinuous. 87 The location of a discontinuity is defined in the \Domain object. 88 \fig{ESCRIPT DEP} shows the dependency between the types of function spaces 89 in \finley (other libraries may have different relationships). 90 91 The solution of a PDE is a continuous function. Any continuous function can 92 be seen as a general function on the domain and can be restricted to the 93 boundary as well as to one side of a discontinuity (the result will be 94 different depending on which side is chosen). Functions on any side of the 95 discontinuity can be seen as a function on the corresponding other side. 96 97 A function on the boundary or on one side of the discontinuity cannot be seen 98 as a general function on the domain as there are no values defined for the 99 interior. For most PDE solver libraries the space of the solution and 100 continuous functions is identical, however in some cases, for example when 101 periodic boundary conditions are used in \finley, a solution fulfills periodic 102 boundary conditions while a continuous function does not have to be periodic. 103 104 The concept of function spaces describes the properties of functions and 105 allows abstraction from the actual representation of the function in the 106 context of a particular application. For instance, in the FEM context a 107 function of the \Function type (written as \emph{Function()} in \fig{ESCRIPT DEP}) 108 is usually represented by its values at the element center, 109 but in a finite difference scheme the edge midpoint of cells is preferred. 110 By changing its function space you can use the same function in a Finite 111 Difference scheme instead of Finite Element scheme. 112 Changing the function space of a particular function will typically lead to 113 a change of its representation. 114 So, when seen as a general function, a continuous function which is typically 115 represented by its values on the nodes of the FEM mesh or finite difference 116 grid must be interpolated to the element centers or the cell edges, 117 respectively. Interpolation happens automatically in \escript whenever it is 118 required\index{interpolation}. The user needs to be aware that an 119 interpolation is not always possible, see \fig{ESCRIPT DEP} for \finley. 120 An alternative approach to change the representation (=\FunctionSpace) is 121 projection\index{projection}, see \Sec{SEC Projection}. 122 123 \subsection{\Data Objects} 124 In \escript the class that stores these functions is called \Data. 125 The function is represented through its values on \DataSamplePoints where 126 the \DataSamplePoints are chosen according to the function space of the 127 function. 128 \Data class objects are used to define the coefficients of the PDEs to be 129 solved by a PDE solver library and also to store the solutions of the PDE. 130 131 The values of the function have a rank which gives the number of indices, 132 and a \Shape defining the range of each index. 133 The rank in \escript is limited to the range 0 through 4 and it is assumed 134 that the rank and \Shape is the same for all \DataSamplePoints. 135 The \Shape of a \Data object is a tuple (list) \var{s} of integers. 136 The length of \var{s} is the rank of the \Data object and the \var{i}-th 137 index ranges between 0 and $\var{s[i]}-1$. 138 For instance, a stress field has rank 2 and \Shape $(d,d)$ where $d$ is the 139 number of spatial dimensions. 140 The following statement creates the \Data object \var{mydat} representing a 141 continuous function with values of \Shape $(2,3)$ and rank $2$: 142 \begin{python} 143 mydat=Data(value=1, what=ContinuousFunction(myDomain), shape=(2,3)) 144 \end{python} 145 The initial value is the constant 1 for all \DataSamplePoints and all 146 components. 147 148 \Data objects can also be created from any \numpy array or any object, such 149 as a list of floating point numbers, that can be converted into 150 a \numpyNDA\cite{NUMPY}. 151 The following two statements create objects which are equivalent 152 to \var{mydat}: 153 \begin{python} 154 mydat1=Data(value=numpy.ones((2,3)), what=ContinuousFunction(myDomain)) 155 mydat2=Data(value=[[1,1], [1,1], [1,1]], what=ContinuousFunction(myDomain)) 156 \end{python} 157 In the first case the initial value is \var{numpy.ones((2,3))} which generates 158 a $2 \times 3$ matrix as an instance of \numpyNDA filled with ones. 159 The \Shape of the created \Data object is taken from the \Shape of the array. 160 In the second case, the creator converts the initial value, which is a list of 161 lists, into a \numpyNDA before creating the actual \Data object. 162 163 For convenience \escript provides creators for the most common types 164 of \Data objects in the following forms (\var{d} defines the spatial 165 dimensionality): 166 \begin{itemize} 167 \item \code{Scalar(0, Function(mydomain))} is the same as \code{Data(0, Function(myDomain),(,))}\\ 168 (each value is a scalar), e.g. a temperature field 169 \item \code{Vector(0, Function(mydomain))} is the same as \code{Data(0, Function(myDomain),(d,))}\\ 170 (each value is a vector), e.g. a velocity field 171 \item \code{Tensor(0, Function(mydomain))} equals \code{Data(0, Function(myDomain), (d,d))}, 172 e.g. a stress field 173 \item \code{Tensor4(0,Function(mydomain))} equals \code{Data(0,Function(myDomain), (d,d,d,d))}, 174 e.g. a Hook tensor field 175 \end{itemize} 176 Here the initial value is 0 but any object that can be converted into 177 a \numpyNDA and whose \Shape is consistent with \Shape of the \Data object to 178 be created can be used as the initial value. 179 180 \Data objects can be manipulated by applying unary operations (e.g. cos, sin, 181 log), and they can be combined point-wise by applying arithmetic operations 182 (e.g. +, - ,* , /). 183 We emphasize that \escript itself does not handle any spatial dependencies as 184 it does not know how values are interpreted by the processing PDE solver library. 185 However \escript invokes interpolation if this is needed during data manipulations. 186 Typically, this occurs in binary operations when the arguments belong to 187 different function spaces or when data are handed over to a PDE solver library 188 which requires functions to be represented in a particular way. 189 190 The following example shows the usage of \Data objects. Assume we have a 191 displacement field $u$ and we want to calculate the corresponding stress field 192 $\sigma$ using the linear-elastic isotropic material model 193 \begin{eqnarray}\label{eq: linear elastic stress} 194 \sigma_{ij}=\lambda u_{k,k} \delta_{ij} + \mu ( u_{i,j} + u_{j,i}) 195 \end{eqnarray} 196 where $\delta_{ij}$ is the Kronecker symbol and 197 $\lambda$ and $\mu$ are the Lam\'e coefficients. The following function 198 takes the displacement \var{u} and the Lam\'e coefficients \var{lam} and \var{mu} 199 as arguments and returns the corresponding stress: 200 \begin{python} 201 from esys.escript import * 202 def getStress(u, lam, mu): 203 d=u.getDomain().getDim() 204 g=grad(u) 205 stress=lam*trace(g)*kronecker(d)+mu*(g+transpose(g)) 206 return stress 207 \end{python} 208 The variable \var{d} gives the spatial dimensionality of the domain on which 209 the displacements are defined. 210 The \code{kronecker(d)} call, returns the Kronecker symbol with indices $i$ and $j$ running 211 from 0 to \var{d}-1. 212 The \var{grad(u)} call, requires the displacement field \var{u} to be in 213 the \var{Solution} or \ContinuousFunction. 214 The result \var{g} as well as the returned stress will be in the \Function. 215 If, for example, \var{u} is the solution of a PDE then \code{getStress} might 216 be called in the following way: 217 \begin{python} 218 s=getStress(u, 1., 2.) 219 \end{python} 220 However \code{getStress} can also be called with \Data objects as values for 221 \var{lam} and \var{mu} which, for instance in the case of a temperature 222 dependency, are calculated by an expression. 223 The following call is equivalent to the previous example: 224 \begin{python} 225 lam=Scalar(1., ContinuousFunction(mydomain)) 226 mu=Scalar(2., Function(mydomain)) 227 s=getStress(u, lam, mu) 228 \end{python} 229 % 230 The function \var{lam} belongs to the \ContinuousFunction but with \var{g} the 231 function \var{trace(g)} is in the \Function. 232 In the evaluation of the product \var{lam*trace(g)} we have different function 233 spaces (on the nodes versus in the centers) and at first glance we have incompatible data. 234 \escript converts the arguments into an appropriate function space according 235 to \fig{ESCRIPT DEP}. 236 In this example that means \escript sees \var{lam} as a function of the \Function. 237 In the context of FEM this means the nodal values of \var{lam} are 238 interpolated to the element centers. 239 The interpolation is automatic and requires no special handling. 240 241 \begin{figure} 242 \centering 243 \includegraphics{EscriptDiagram2} 244 \caption{\label{Figure: tag}Element Tagging. A rectangular mesh over a region 245 with two rock types {\it white} and {\it gray} is shown. 246 The number in each cell refers to the major rock type present in the cell 247 ($1$ for {\it white} and $2$ for {\it gray}).} 248 \end{figure} 249 250 \subsection{Tagged, Expanded and Constant Data} 251 Material parameters such as the Lam\'e coefficients are typically dependent on 252 rock types present in the area of interest. 253 A common technique to handle these kinds of material parameters is 254 \emph{tagging}\index{tagging}, which uses storage efficiently. 255 \fig{Figure: tag} shows an example. In this case two rock types {\it white} 256 and {\it gray} can be found in the domain. 257 The domain is subdivided into triangular shaped cells. 258 Each cell has a tag indicating the rock type predominantly found in this cell. 259 Here $1$ is used to indicate rock type {\it white} and $2$ for rock type {\it gray}. 260 The tags are assigned at the time when the cells are generated and stored in 261 the \Domain class object. To allow easier usage of tags, names can be used 262 instead of numbers. These names are typically defined at the time when the 263 geometry is generated. 264 265 The following statements show how to use tagged values for \var{lam} as shown 266 in \fig{Figure: tag} for the stress calculation discussed above: 267 \begin{python} 268 lam=Scalar(value=2., what=Function(mydomain)) 269 insertTaggedValue(lam, white=30., gray=5000.) 270 s=getStress(u, lam, 2.) 271 \end{python} 272 In this example \var{lam} is set to $30$ for those cells with tag {\it white} 273 (=$1$) and to $5000$ for cells with tag {\it gray} (=$2$). 274 The initial value $2$ of \var{lam} is used as a default value for the case 275 when a tag is encountered which has not been linked with a value. 276 The \code{getStress} method does not need to be changed now that we are using tags. 277 \escript resolves the tags when \var{lam*trace(g)} is calculated. 278 279 This brings us to a very important point about \escript. 280 You can develop a simulation with constant Lam\'e coefficients, and then later 281 switch to tagged Lam\'e coefficients without otherwise changing your \PYTHON script. 282 In short, you can use the same script for models with different domains and 283 different types of input data. 284 285 There are three main ways in which \Data objects are represented internally -- 286 constant, tagged, and expanded. 287 In the constant case, the same value is used at each sample point while only a 288 single value is stored to save memory. 289 In the expanded case, each sample point has an individual value (such as for the solution of a PDE). 290 This is where your largest data sets will be created because the values are 291 stored as a complete array. 292 The tagged case has already been discussed above. 293 Expanded data is created when specifying \code{expanded=True} in the \Data 294 object constructor, while tagged data requires calling the \member{insertTaggedValue} 295 method as shown above. 296 297 Values are accessed through a sample reference number. 298 Operations on expanded \Data objects have to be performed for each sample 299 point individually. 300 When tagged values are used, the values are held in a dictionary. 301 Operations on tagged data require processing the set of tagged values only, 302 rather than processing the value for each individual sample point. 303 \escript allows any mixture of constant, tagged and expanded data in a single expression. 304 305 \subsection{Saving and Restoring Simulation Data} 306 \Data objects can be written to disk files with the \member{dump} method and 307 read back using the \member{load} method, both of which use the 308 \netCDF\cite{NETCDF} file format. 309 Use these to save data for checkpoint/restart or simply to save and reuse data 310 that was expensive to compute. 311 For instance, to save the coordinates of the data points of a 312 \ContinuousFunction to the file \file{x.nc} use 313 \begin{python} 314 x=ContinuousFunction(mydomain).getX() 315 x.dump("x.nc") 316 mydomain.dump("dom.nc") 317 \end{python} 318 To recover the object \var{x}, and you know that \var{mydomain} was an \finley 319 mesh, use 320 \begin{python} 321 from esys.finley import LoadMesh 322 mydomain=LoadMesh("dom.nc") 323 x=load("x.nc", mydomain) 324 \end{python} 325 Obviously, it is possible to execute the same steps that were originally used 326 to generate \var{mydomain} to recreate it. However, in most cases using 327 \member{dump} and \member{load} is faster, particularly if optimization has 328 been applied. 329 If \escript is running on more than one \MPI process \member{dump} will create 330 an individual file for each process containing the local data. 331 In order to avoid conflicts the \MPI processor 332 rank is appended to the file names. 333 That is instead of one file \file{dom.nc} you would get 334 \file{dom.nc.0000}, \file{dom.nc.0001}, etc. 335 You still call \code{LoadMesh("dom.nc")} to load the domain but you have to 336 make sure that the appropriate file is accessible from the corresponding rank, 337 and loading will only succeed if you run with as many processes as were used 338 when calling \member{dump}. 339 340 The function space of the \Data is stored in \file{x.nc}. 341 If the \Data object is expanded, the number of data points in the file and of 342 the \Domain for the particular \FunctionSpace must match. 343 Moreover, the ordering of the values is checked using the reference 344 identifiers provided by the \FunctionSpace on the \Domain. 345 In some cases, data points will be reordered so be aware and confirm that you 346 get what you wanted. 347 348 A more flexible way of saving and restoring \escript simulation data 349 is through an instance of the \class{DataManager} class. 350 It has the advantage of allowing to save and load not only a \Domain and 351 \Data objects but also other values\footnote{The \PYTHON \emph{pickle} module 352 is used for other types.} you compute in your simulation script. 353 Further, \class{DataManager} objects can simultaneously create files for 354 visualization so no extra calls to \code{saveVTK} etc. are needed. 355 356 The following example shows how the \class{DataManager} class can be used. 357 For an explanation of all member functions and options see the class reference 358 Section \ref{sec:datamanager}. 359 \begin{python} 360 from esys.escript import DataManager, Scalar, Function 361 from esys.finley import Rectangle 362 363 dm = DataManager(formats=[DataManager.RESTART, DataManager.VTK]) 364 if dm.hasData(): 365 mydomain=dm.getDomain() 366 val=dm.getValue("val") 367 t=dm.getValue("t") 368 t_max=dm.getValue("t_max") 369 else: 370 mydomain=Rectangle() 371 val=Function(mydomain).getX() 372 t=0. 373 t_max=2.5 374 375 while t$\var{maxval} the value \var{maxval} is used. 1376 1377 Now we produce our new \Data object: 1378 1379 \begin{python} 1380 result=interpolateTable(sine_table, x[0], minval, step, toobig) 1381 \end{python} 1382 Any values which interpolate to larger than \var{toobig} will raise an 1383 exception. You can switch on boundary checking by adding 1384 \code{check_boundaries=True} to the argument list. 1385 1386 Now consider a 2D example. We will interpolate from a plane where$\forall x,y\in[0,9]:(x,y)=x+y\cdot10$. 1387 1388 \begin{python} 1389 from esys.escript import whereZero 1390 table2=[] 1391 for y in range(0,10): 1392 r=[] 1393 for x in range(0,10): 1394 r.append(x+y*10) 1395 table2.append(r) 1396 xstep=(maxval-minval)/(10-1) 1397 ystep=(maxval-minval)/(10-1) 1398 1399 xmin=minval 1400 ymin=minval 1401 1402 result2=interpolateTable(table2, x2, (xmin, ymin), (xstep, ystep), toobig) 1403 \end{python} 1404 1405 We can check the values using \function{whereZero}. 1406 For example, for$x=0$: 1407 \begin{python} 1408 print(result2*whereZero(x[0])) 1409 \end{python} 1410 1411 Finally let us look at a 3D example. Note that the parameter tuples should be 1412$(x,y,z)$but that in the interpolation table,$x$is the innermost dimension. 1413 \begin{python} 1414 b=Brick(n,n,n) 1415 x3=b.getX() 1416 toobig=1000000 1417 1418 table3=[] 1419 for z in range(0,10): 1420 face=[] 1421 for y in range(0,10): 1422 r=[] 1423 for x in range(0,10): 1424 r.append(x+y*10+z*100) 1425 face.append(r) 1426 table3.append(face); 1427 1428 zstep=(maxval-minval)/(10-1) 1429 1430 zmin=minval 1431 1432 result3=interpolateTable(table3, x3, (xmin, ymin, zmin), 1433 (xstep, ystep, zstep), toobig) 1434 \end{python} 1435 1436 1437 \subsubsection{Non-uniform Interpolation} 1438 Non-uniform interpolation is also supported for the one dimensional case. 1439 \begin{python} 1440 Data.nonuniformInterpolate(in, out, check_boundaries) 1441 Data.nonuniformSlope(in, out, check_boundaries) 1442 \end{python} 1443 1444 Will produce a new \Data object by mapping the given \Data object through the user-defined function 1445 specified by \texttt{in} and \texttt{out}. 1446 The \ldots Interpolate version gives the value of the function at the specified point and the 1447 \ldots Slope version gives the slope at those points. 1448 The check_boundaries boolean argument specifies what the function should do if the \Data object contains 1449 values outside the range specified by the \texttt{in} parameter. 1450 If the argument is \texttt{False}, then those datapoints will be interpolated to the value of the edge 1451 they are closest to (or assigned a slope of zero). 1452 If the argument is \texttt{True}, then an exception will be thrown if out of bounds values are detected. 1453 Note that the values given by the \texttt{in} parameter must be monotonically increasing. 1454 1455 \noindent For example:\\ 1456 If \texttt{d} contains the values \texttt{\{1,2,3,4,5\}}, then 1457 \begin{python} 1458 d.nonuniformInterpolate([1.5, 2, 2.8, 4.6], [4, 5, -1, 1], False) 1459 \end{python} 1460 would produce a \Data object containing \texttt{\{4, 5, -0.7777, 0.3333, 1\}}.\\ 1461 A similar call to \texttt{nonuniformSlope} would produce a \Data object containing \texttt{\{0, 2, 1.1111, 1.1111, 0\}}. 1462 % 1463 % 1464 % We will interpolate a surface such that the bottom 1465 % edge is the sine curve described above. 1466 % The amplitude of the curve decreases as we move towards the top edge. 1467 % Our interpolation table will have three rows: 1468 % 1469 % \begin{python} 1470 % st=numpy.array(sine_table) 1471 % table=[st, 0.5*st, 0*st] 1472 % \end{python} 1473 % % 1474 % The use of \numpy and multiplication here is just to save typing. 1475 % 1476 % % result2=x1.interpolateTable(table, 0, 0.55, x0, minval, step, toobig) 1477 % \begin{python} 1478 % result=interpolateTable(table, x (minval,0), (0.55, step), toobig) 1479 % \end{python} 1480 % 1481 % In the 2D case the start and step parameters are tuples$(x,y)$. 1482 % By default, if a point is specified which is outside the boundary, then 1483 % \var{interpolateTable} will operate as if the point was on the boundary. 1484 % Passing \code{check_boundaries=True} will lead to the rejection of any points 1485 % outside the boundaries by \var{interpolateTable}. 1486 % 1487 % This method can also be called with three dimensional tables and \Data objects. 1488 % Tuples should be ordered$(x,y,z)$. 1489 1490 \subsection{The \var{DataManager} Class} 1491 \label{sec:datamanager} 1492 1493 The \var{DataManager} class can be used to conveniently add checkpoint/restart 1494 functionality to \escript simulations. 1495 Once an instance is created \Data objects and other values can be added and 1496 dumped to disk by a single method call. 1497 If required the object can be set up to also save the data in a format suitable 1498 for visualization. 1499 Internally the \var{DataManager} interfaces with \weipa for this. 1500 1501 \begin{classdesc}{DataManager}{formats=[RESTART], work_dir=".", restart_prefix="restart", do_restart=\True} 1502 initializes a new \var{DataManager} object which can be used to save, 1503 restore and export simulation data in a number of formats. 1504 All files and directories saved or restored by this object are located 1505 under the directory specified by \var{work_dir}. 1506 If \var{RESTART} is specified in \var{formats}, the \var{DataManager} will 1507 look for directories whose name starts with \var{restart_prefix}. 1508 In case \var{do_restart} is \True, the last of these directories is used 1509 to restore simulation data while all others are deleted. 1510 If \var{do_restart} is \False, then all of those directories are deleted. 1511 The \var{restart_prefix} and \var{do_restart} parameters are ignored if 1512 \var{RESTART} is not specified in \var{formats}. 1513 \end{classdesc} 1514 1515 \noindent Valid values for the \var{formats} parameter are: 1516 \begin{memberdesc}[DataManager]{RESTART} 1517 enables writing of checkpoint files to be able to continue simulations 1518 as explained in the class description. 1519 \end{memberdesc} 1520 \begin{memberdesc}[DataManager]{SILO} 1521 exports simulation data in the \SILO file format. \escript must have 1522 been compiled with \SILO support for this to work. 1523 \end{memberdesc} 1524 \begin{memberdesc}[DataManager]{VISIT} 1525 enables the \VisIt simulation interface which allows connecting to and 1526 interacting with the running simulation from a compatible \VisIt client. 1527 \escript must have been compiled with \VisIt (version 2) support and the 1528 version of the client has to match the version used at compile time. 1529 In order to connect to the simulation the client needs to have access and 1530 load the file \file{escriptsim.sim2} located under the work directory. 1531 \end{memberdesc} 1532 \begin{memberdesc}[DataManager]{VTK} 1533 exports simulation data in the \VTK file format. 1534 \end{memberdesc} 1535 1536 \noindent The \var{DataManager} class has the following methods: 1537 \begin{methoddesc}[DataManager]{addData}{**data} 1538 adds \Data objects and other data to the manager. Calling this method does 1539 not save or export the data yet so it is allowed to incrementally add data 1540 at various points in the simulation script if required. 1541 Note, that only a single domain is supported so all \Data objects have to 1542 be defined on the same one or an exception is raised. 1543 \end{methoddesc} 1544 1545 \begin{methoddesc}[DataManager]{setDomain}{domain} 1546 explicitly sets the domain for this manager. 1547 It is generally not required to call this method directly. 1548 Instead, the \var{addData} method will set the domain used by the \Data 1549 objects. 1550 An exception is raised if the domain was set to a different domain before 1551 (explicitly or implicitly). 1552 \end{methoddesc} 1553 1554 \begin{methoddesc}[DataManager]{hasData}{} 1555 returns \True if the manager has loaded simulation data for a restart. 1556 \end{methoddesc} 1557 1558 \begin{methoddesc}[DataManager]{getDomain}{} 1559 returns the domain as recovered from a restart. 1560 \end{methoddesc} 1561 1562 \begin{methoddesc}[DataManager]{getValue}{value_name} 1563 returns a \Data object or other value with the name \var{value_name} that 1564 has been recovered after a restart. 1565 \end{methoddesc} 1566 1567 \begin{methoddesc}[DataManager]{getCycle}{} 1568 returns the export cycle, i.e. the number of times \var{export()} has been 1569 called. 1570 \end{methoddesc} 1571 1572 \begin{methoddesc}[DataManager]{setCheckpointFrequency}{freq} 1573 sets the frequency with which checkpoint files are created. This is only 1574 useful if the \var{DataManager} object was created with at least one other 1575 format next to \var{RESTART}. The frequency is 1 by default which means 1576 that checkpoint files are created every time \var{export()} is called. 1577 Unlike visualization output, a simulation checkpoint is usually not 1578 required at every time step. Thus, the frequency can be decreased by 1579 calling this method with$\var{freq}>1$which would then create restart 1580 files every \var{freq} times \var{export()} is called. 1581 \end{methoddesc} 1582 1583 \begin{methoddesc}[DataManager]{setTime}{time} 1584 sets the simulation time stamp. This floating point number is stored in 1585 the metadata of exported data but not used by \var{RESTART}. 1586 \end{methoddesc} 1587 1588 \begin{methoddesc}[DataManager]{setMeshLabels}{x, y, z=""} 1589 sets labels for the mesh axes. These are currently only used by the \SILO 1590 exporter. 1591 \end{methoddesc} 1592 1593 \begin{methoddesc}[DataManager]{setMeshUnits}{x, y, z=""} 1594 sets units for the mesh axes. These are currently only used by the \SILO 1595 exporter. 1596 \end{methoddesc} 1597 1598 \begin{methoddesc}[DataManager]{setMetadataSchemaString}{schema, metadata=""} 1599 sets metadata namespaces and the corresponding metadata. These are 1600 currently only used by the \VTK exporter. 1601 \var{schema} is a dictionary that maps prefixes to namespace names, e.g.\\ 1602 \code{\{"gml": "http://www.opengis.net/gml"\}} and \var{metadata} is a 1603 string with the actual content which will be enclosed in \var{} 1604 tags. 1605 \end{methoddesc} 1606 1607 \begin{methoddesc}[DataManager]{export}{} 1608 executes the actual data export. Depending on the \var{formats} parameter 1609 used in the constructor all data added by \var{addData()} is written to 1610 disk (\var{RESTART,SILO,VTK}) or made available through the \VisIt 1611 simulation interface (\var{VISIT}). 1612 At least the domain must be set for something to be exported. 1613 \end{methoddesc} 1614 1615 \subsection{Saving Data as CSV} 1616 \label{sec:savedatacsv} 1617 \index{saveDataCSV}\index{CSV} 1618 For simple post-processing, \Data objects can be saved in comma separated 1619 value (\emph{CSV}) format. 1620 If \var{mydata1} and \var{mydata2} are scalar data, the command 1621 \begin{python} 1622 saveDataCSV('output.csv', U=mydata1, V=mydata2) 1623 \end{python} 1624 will record the values in \file{output.csv} in the following format: 1625 \begin{verbatim} 1626 U, V 1627 1.0000000e+0, 2.0000000e-1 1628 5.0000000e-0, 1.0000000e+1 1629 ... 1630 \end{verbatim} 1631 1632 The names of the keyword parameters form the names of columns in the output. 1633 If the data objects are over different function spaces, then \var{saveDataCSV} 1634 will attempt to interpolate to a common function space. 1635 If this is not possible, then an exception is raised. 1636 1637 Output can be restricted using a scalar mask as follows: 1638 \begin{python} 1639 saveDataCSV('outfile.csv', U=mydata1, V=mydata2, mask=myscalar) 1640 \end{python} 1641 This command will only output those rows which correspond to to positive 1642 values of \var{myscalar}. 1643 Some aspects of the output can be tuned using additional parameters: 1644 \begin{python} 1645 saveDataCSV('data.csv', refid=True, append=True, sep=' ', csep='/', mask=mymask, e=mat1) 1646 \end{python} 1647 1648 \begin{itemize} 1649 \item \var{refid} -- specifies that the output should include the reference IDs of the elements or nodes 1650 \item \var{append} -- specifies that the output should be written to the end of an existing file 1651 \item \var{sep} -- defines the separator between fields 1652 \item \var{csep} -- defines the separator between components in the header 1653 line. For example between the components of a matrix. 1654 \end{itemize} 1655 % 1656 The above command would produce output like this: 1657 \begin{verbatim} 1658 refid e/0/0 e/1/0 e/0/1 e/1/1 1659 0 1.0000000000e+00 2.0000000000e+00 3.0000000000e+00 4.0000000000e+00 1660 ... 1661 \end{verbatim} 1662 1663 Note that while the order in which rows are output can vary, all the elements 1664 in a given row always correspond to the same input. 1665 1666 \subsection{Converting \Data to a Numpy Array} 1667 \label{sec:getnumpy} 1668 \index{getNumpy}\index{GN} 1669 \Data objects can be converted into a numpy structured array. 1670 If \var{mydata1} and \var{mydata2} are scalar \Data, then the command 1671 \begin{python} 1672 a,b = getNumpy(U=mydata1, V=mydata2) 1673 \end{python} 1674 will return two structured ndarrays with the names '\emph{U}' and '\emph{V}'. 1675 \begin{verbatim} 1676 a['U'] = [1.0000000e+0, 2.0000000e-1, ... 1677 b['V'] = [2.0000000e+0, 3.0000000e-1, ... 1678 \end{verbatim} 1679 1680 Up to five \Data objects can be passed to \var{getNumpy} at the time. These objects can be scalar, vector or tensor \Data objects. The names of the keyword parameters form the names of the returned arrays. 1681 If the data objects are over different function spaces, then \var{getNumpy} 1682 will attempt to interpolate to a common function space. 1683 If this is not possible, then an exception is raised. 1684 1685 Output can be restricted using a scalar mask as follows: 1686 \begin{python} 1687 a,b,c = getNumpy(U=mydata1, V=mydata2, W=mydata3, mask=myscalar) 1688 \end{python} 1689 This command will only output those rows which correspond to to positive 1690 values of \var{myscalar}. 1691 1692 Note that while the order in which output rows are output can vary, all the elements 1693 in a given row always correspond to the same input. 1694 1695 1696 \subsection{The \Operator Class} 1697 The \Operator class provides an abstract access to operators built 1698 within the \LinearPDE class. \Operator objects are created 1699 when a PDE is handed over to a PDE solver library and handled 1700 by the \LinearPDE object defining the PDE. The user can gain access 1701 to the \Operator of a \LinearPDE object through the \var{getOperator} 1702 method. 1703 1704 \begin{classdesc}{Operator}{} 1705 creates an empty \Operator object. 1706 \end{classdesc} 1707 1708 \begin{methoddesc}[Operator]{isEmpty}{fileName} 1709 returns \True is the object is empty, \False otherwise. 1710 \end{methoddesc} 1711 1712 \begin{methoddesc}[Operator]{resetValues}{} 1713 resets all entries in the operator. 1714 \end{methoddesc} 1715 1716 \begin{methoddesc}[Operator]{solve}{rhs} 1717 returns the solution \var{u} of: operator * \var{u} = \var{rhs}. 1718 \end{methoddesc} 1719 1720 \begin{methoddesc}[Operator]{of}{u} 1721 applies the operator to the \Data object \var{u}, i.e. performs a matrix-vector 1722 multiplication. 1723 \end{methoddesc} 1724 1725 \begin{methoddesc}[Operator]{saveMM}{fileName}\index{Matrix Market} 1726 saves the object to a Matrix Market format file with name \var{fileName}, see 1727 \url{http://math.nist.gov/MatrixMarket} 1728 \end{methoddesc} 1729 1730 \section{Physical Units} 1731 \escript provides support for physical units in the SI system\index{SI units} 1732 including unit conversion. So the user can define variables in the form 1733 \begin{python} 1734 from esys.escript.unitsSI import * 1735 l=20*m 1736 w=30*kg 1737 w2=40*lb 1738 T=100*Celsius 1739 \end{python} 1740 In the two latter cases a conversion from pounds\index{pounds} and degrees 1741 Celsius\index{Celsius} is performed into the appropriate SI units \emph{kg} 1742 and \emph{Kelvin}. 1743 In addition, composed units can be used, for instance 1744 \begin{python} 1745 from esys.escript.unitsSI import * 1746 rho=40*lb/cm**3 1747 \end{python} 1748 defines the density in the units of pounds per cubic centimeter. 1749 The value$40$will be converted into SI units, in this case kg per cubic 1750 meter. Moreover unit prefixes are supported: 1751 \begin{python} 1752 from esys.escript.unitsSI import * 1753 p=40*Mega*Pa 1754 \end{python} 1755 The pressure \var{p} is set to 40 Mega Pascal. Units can also be converted 1756 back from the SI system into a desired unit, e.g. 1757 \begin{python} 1758 from esys.escript.unitsSI import * 1759 print(p/atm) 1760 \end{python} 1761 can be used print the pressure in units of atmosphere\index{atmosphere}. 1762 1763 The following is an incomplete list of supported physical units: 1764 1765 \begin{datadesc}{km} 1766 unit of kilometer 1767 \end{datadesc} 1768 1769 \begin{datadesc}{m} 1770 unit of meter 1771 \end{datadesc} 1772 1773 \begin{datadesc}{cm} 1774 unit of centimeter 1775 \end{datadesc} 1776 1777 \begin{datadesc}{mm} 1778 unit of millimeter 1779 \end{datadesc} 1780 1781 \begin{datadesc}{sec} 1782 unit of second 1783 \end{datadesc} 1784 1785 \begin{datadesc}{minute} 1786 unit of minute 1787 \end{datadesc} 1788 1789 \begin{datadesc}{h} 1790 unit of hour 1791 \end{datadesc} 1792 1793 \begin{datadesc}{day} 1794 unit of day 1795 \end{datadesc} 1796 1797 \begin{datadesc}{yr} 1798 unit of year 1799 \end{datadesc} 1800 1801 \begin{datadesc}{gram} 1802 unit of gram 1803 \end{datadesc} 1804 1805 \begin{datadesc}{kg} 1806 unit of kilogram 1807 \end{datadesc} 1808 1809 \begin{datadesc}{lb} 1810 unit of pound 1811 \end{datadesc} 1812 1813 \begin{datadesc}{ton} 1814 metric ton 1815 \end{datadesc} 1816 1817 \begin{datadesc}{A} 1818 unit of Ampere 1819 \end{datadesc} 1820 1821 \begin{datadesc}{Hz} 1822 unit of Hertz 1823 \end{datadesc} 1824 1825 \begin{datadesc}{N} 1826 unit of Newton 1827 \end{datadesc} 1828 1829 \begin{datadesc}{Pa} 1830 unit of Pascal 1831 \end{datadesc} 1832 1833 \begin{datadesc}{atm} 1834 unit of atmosphere 1835 \end{datadesc} 1836 1837 \begin{datadesc}{J} 1838 unit of Joule 1839 \end{datadesc} 1840 1841 \begin{datadesc}{W} 1842 unit of Watt 1843 \end{datadesc} 1844 1845 \begin{datadesc}{C} 1846 unit of Coulomb 1847 \end{datadesc} 1848 1849 \begin{datadesc}{V} 1850 unit of Volt 1851 \end{datadesc} 1852 1853 \begin{datadesc}{F} 1854 unit of Farad 1855 \end{datadesc} 1856 1857 \begin{datadesc}{Ohm} 1858 unit of Ohm 1859 \end{datadesc} 1860 1861 \begin{datadesc}{K} 1862 unit of degrees Kelvin 1863 \end{datadesc} 1864 1865 \begin{datadesc}{Celsius} 1866 unit of degrees Celsius 1867 \end{datadesc} 1868 1869 \begin{datadesc}{Fahrenheit} 1870 unit of degrees Fahrenheit 1871 \end{datadesc} 1872 1873 \noindent Supported unit prefixes: 1874 1875 \begin{datadesc}{Yotta} 1876 prefix yotta =$10^{24}$1877 \end{datadesc} 1878 1879 \begin{datadesc}{Zetta} 1880 prefix zetta =$10^{21}$1881 \end{datadesc} 1882 1883 \begin{datadesc}{Exa} 1884 prefix exa =$10^{18}$1885 \end{datadesc} 1886 1887 \begin{datadesc}{Peta} 1888 prefix peta =$10^{15}$1889 \end{datadesc} 1890 1891 \begin{datadesc}{Tera} 1892 prefix tera =$10^{12}$1893 \end{datadesc} 1894 1895 \begin{datadesc}{Giga} 1896 prefix giga =$10^9$1897 \end{datadesc} 1898 1899 \begin{datadesc}{Mega} 1900 prefix mega =$10^6$1901 \end{datadesc} 1902 1903 \begin{datadesc}{Kilo} 1904 prefix kilo =$10^3$1905 \end{datadesc} 1906 1907 \begin{datadesc}{Hecto} 1908 prefix hecto =$10^2$1909 \end{datadesc} 1910 1911 \begin{datadesc}{Deca} 1912 prefix deca =$10^1$1913 \end{datadesc} 1914 1915 \begin{datadesc}{Deci} 1916 prefix deci =$10^{-1}$1917 \end{datadesc} 1918 1919 \begin{datadesc}{Centi} 1920 prefix centi =$10^{-2}$1921 \end{datadesc} 1922 1923 \begin{datadesc}{Milli} 1924 prefix milli =$10^{-3}$1925 \end{datadesc} 1926 1927 \begin{datadesc}{Micro} 1928 prefix micro =$10^{-6}$1929 \end{datadesc} 1930 1931 \begin{datadesc}{Nano} 1932 prefix nano =$10^{-9}$1933 \end{datadesc} 1934 1935 \begin{datadesc}{Pico} 1936 prefix pico =$10^{-12}$1937 \end{datadesc} 1938 1939 \begin{datadesc}{Femto} 1940 prefix femto =$10^{-15}$1941 \end{datadesc} 1942 1943 \begin{datadesc}{Atto} 1944 prefix atto =$10^{-18}$1945 \end{datadesc} 1946 1947 \begin{datadesc}{Zepto} 1948 prefix zepto =$10^{-21}$1949 \end{datadesc} 1950 1951 \begin{datadesc}{Yocto} 1952 prefix yocto =$10^{-24}$1953 \end{datadesc} 1954 1955 \section{Utilities} 1956 The \class{FileWriter} class provides a mechanism to write data to a file. 1957 In essence, this class wraps the standard \PYTHON \class{file} class to write 1958 data that are global in \MPI to a file. In fact, data are written on the 1959 processor with \MPI rank 0 only. It is recommended to use \class{FileWriter} 1960 rather than \class{open} in order to write code that will run with and without 1961 \MPI. It is safe to use \class{open} under \MPI to \emph{read} data which are 1962 global under \MPI. 1963 1964 \begin{classdesc}{FileWriter}{fn\optional{,append=\False, \optional{createLocalFiles=\False}})} 1965 Opens a file with name \var{fn} for writing. If \var{append} is set to \True 1966 data are appended at the end of the file. 1967 If running under \MPI, only the first processor (rank==0) will open the file 1968 and write to it. 1969 If \var{createLocalFiles} is set each individual processor will create a file 1970 where for any processor with rank$> 0\$ the file name is extended by its rank. 1971 This option is normally used for debugging purposes only. 1972 \end{classdesc} 1973 1974 \vspace{1em}\noindent The following methods are available: 1975 \begin{methoddesc}[FileWriter]{close}{} 1976 closes the file. 1977 \end{methoddesc} 1978 \begin{methoddesc}[FileWriter]{flush}{} 1979 flushes the internal buffer to disk. 1980 \end{methoddesc} 1981 \begin{methoddesc}[FileWriter]{write}{txt} 1982 writes string \var{txt} to the file. Note that a newline is not added. 1983 \end{methoddesc} 1984 \begin{methoddesc}[FileWriter]{writelines}{txts} 1985 writes the list \var{txts} of strings to the file. 1986 Note that newlines are not added. 1987 This method is equivalent to calling \var{write()} for each string. 1988 \end{methoddesc} 1989 \begin{memberdesc}[FileWriter]{closed} 1990 this member is \True if the file is closed. 1991 \end{memberdesc} 1992 \begin{memberdesc}[FileWriter]{mode} 1993 holds the access mode. 1994 \end{memberdesc} 1995 \begin{memberdesc}[FileWriter]{name} 1996 holds the file name. 1997 \end{memberdesc} 1998 \begin{memberdesc}[FileWriter]{newlines} 1999 holds the line separator. 2000 \end{memberdesc} 2001 2002 \noindent The following additional functions are available in the \escript 2003 module: 2004 \begin{funcdesc}{setEscriptParamInt}{name,value} 2005 assigns the integer value \var{value} to the internal Escript parameter 2006 \var{name}. This should be considered an advanced feature and it is generally 2007 not required to call this function. One parameter worth mentioning is 2008 \var{name}="TOO_MANY_LINES" which affects the conversion of \Data objects to a 2009 string. If more than \var{value} lines would be created, a condensed format is 2010 used instead which reports the minimum and maximum values and general 2011 information about the \Data object rather than all values. 2012 \end{funcdesc} 2013 2014 \begin{funcdesc}{getEscriptParamInt}{name} 2015 returns the current value of internal Escript parameter \var{name}. 2016 \end{funcdesc} 2017 2018 \begin{funcdesc}{listEscriptParams}{a} 2019 returns a list of valid Escript parameters and their description. 2020 \end{funcdesc} 2021 2022 \begin{funcdesc}{getMPISizeWorld}{} 2023 returns the number of \MPI processes in use in the \env{MPI_COMM_WORLD} 2024 process group. If \MPI is not used 1 is returned. 2025 \end{funcdesc} 2026 2027 \begin{funcdesc}{getMPIRankWorld}{} 2028 returns the rank of the current process within the \env{MPI_COMM_WORLD} 2029 process group. If \MPI is not used 0 is returned. 2030 \end{funcdesc} 2031 2032 \begin{funcdesc}{MPIBarrierWorld}{} 2033 performs a barrier synchronization across all processes within the 2034 \env{MPI_COMM_WORLD} process group. 2035 \end{funcdesc} 2036 2037 \begin{funcdesc}{getMPIWorldMax}{a} 2038 returns the maximum value of the integer \var{a} across all processes within 2039 \env{MPI_COMM_WORLD}. 2040 \end{funcdesc} 2041 2042 \section{Lazy Evaluation of Data} 2043 \label{sec:lazy} 2044 Constant and Tagged representations of Data are relatively small but Expanded\footnote{Separate values stored for each point of the FunctionSpace.} are larger and 2045 will not entirely fit in CPU cache. 2046 2047 Escript's lazy evaluation features record operations performed on Data objects but do not actually carry them out until the Data is resolved''. 2048 2049 Consider the following code: 2050 \begin{python} 2051 from esys.escript import * 2052 from esys.dudley import Rectangle 2053 x=Rectangle(3,3) 2054 x=Rectangle(3,3).getX() 2055 c=Data((1.5, 1), x.getFunctionSpace()) 2056 t=Data(((1,1),(0,1)), x.getFunctionSpace()) 2057 t.tag() 2058 \end{python} 2059 2060 The variables \var{c}, \var{t}, \var{x} are stored as \texttt{constant}, \texttt{tagged} and \texttt{expanded} Data respectively. 2061 Printing those variables will show the values stored (or if we were to use a larger Rectangle, a summary). 2062 2063 \begin{python} 2064 v = matrix_mult(t,x) + c 2065 print(v.isExpanded()) 2066 print(v) 2067 \end{python} 2068 2069 Will output \texttt{True} followed by all of the values for \var{v}. 2070 Now we'll introduce lazy evaluation: 2071 2072 \begin{python} 2073 xx = x.delay() 2074 print(xx.isExpanded(), xx.isLazy()) 2075 print(x.isExpanded(), x.isLazy()) 2076 print(xx) 2077 \end{python} 2078 2079 The first print will show that \var{xx} is not considered to be expanded'', while the second print shows that \var{x} is unaffected. 2080 The last print will produce something like: 2081 \begin{python} 2082 Lazy Data: [depth=0] E@0x55ed512ad760 2083 \end{python} 2084 The \texttt{E} before the \verb|@| shows that this lazy Data is wrapping expanded'' Data. 2085 Calling \texttt{.delay()} on constant or tagged Data results in \verb|C@...| and \verb|T@...| respectively. 2086 2087 If an input to an operation is lazy, then the result will be lazy as well\footnote{Matrix inverse is an exception to this.}: 2088 \begin{python} 2089 res = matrix_mult(t,-xx) + c 2090 print(res) 2091 \end{python} 2092 Will produce: 2093 \begin{python} 2094 Lazy Data: [depth=3] (prod(T@0x..., neg(E@...)) + C@0x...) 2095 \end{python} 2096 Depth indicates the largest number of operators from the top of the expression to the bottom. 2097 2098 To actually find the value of this lazy Data object, we need to resolve it: 2099 \begin{python} 2100 res.resolve() 2101 \end{python} 2102 Note that \texttt{resolve()} doesn't return a new object, but transforms the object it is called on. 2103 Printing, \var{res} now will show the values at each point. 2104 2105 \subsection{Lazyness and non-expanded Data} 2106 While it is possible to call delay on constant or tagged Data, escript will not build expressions consisting solely of such Data. 2107 \begin{python} 2108 cx=c.delay() 2109 res=cx+cx 2110 print(res) 2111 \end{python} 2112 would output: 2113 \begin{python} 2114 Lazy Data: [depth=0] C@0x55ed512cc7c0 2115 # Not 2116 Lazy Data: [depth=1] (C@0x... + C@0x...) 2117 \end{python} 2118 2119 2120 \subsection{When to resolve} 2121 2122 You are never \emph{required} to manually resolve lazy Data in \texttt{escript}. 2123 Any operations which need the actual values of an expression will either 2124 \begin{itemize} 2125 \item compute the values without resolving the whole Data object at once (solvers assembling FEM matrices) 2126 \item resolve the data automatically (everthing else) 2127 \end{itemize} 2128 2129 \noindent Escript will automatically resolve lazy Data: 2130 \begin{enumerate} 2131 \item If a matrix inversion operation is applied to the Data. 2132 \item If the expression tree becomes too deep\footnote{At time of writing, this threshold is somewhat arbitrarily set at \texttt{depth>9}, but this is configurable.}. 2133 \end{enumerate} 2134 Note, the second point is important when writing loops like this: 2135 \begin{python} 2136 # x is initial guess 2137 while err > tol: 2138 construct PDE coefficients involving x 2139 solve PDE 2140 calculate err 2141 update x 2142 \end{python} 2143 2144 After a few iterations of the loop, \var{x} may be something like \texttt{x=F(F(F(F(originalX))))}. 2145 So it will probably be better to \texttt{resolve} \var{x} at the end of each loop iteration. 2146 Alternatively, if \var{x} is included in many expressions in the loop, it may be better to resolve it earlier. 2147 2148 \subsection{Options for using lazy evaluation} 2149 2150 There are two ways to enable lazy evaluation: 2151 \begin{enumerate} 2152 \item Any escript script can make use of lazy evaluation by \texttt{delay()}-ing one of its expanded Data variables. 2153 Any expressions including that delayed variable (directly or indirectly) will be lazy until resolved. 2154 \item Setting the \texttt{AUTOLAZY} parameter for \texttt{escript} to \texttt{1}. 2155 In this case, most escript operation which would normally produce extended Data, will produce lazy Data instead. 2156 In general, this option is not recommended for two reasons: 2157 \begin{itemize} 2158 \item AUTOLAZY uses the \texttt{setEscriptParamInt()} which is not guaranteed to have continued support. 2159 \item Making everything lazy instead of just more complex objects is not likely to give significant efficiency improvements. 2160 \end{itemize} 2161 \end{enumerate} 2162 2163 \subsection{When to use lazy evaluation?} 2164 Exactly when using lazy evaluation will be more efficient is still an open question. 2165 When the objects being manipulated are large (eg 4-Tensors in Drucker-Prager), significant memory and runtime improvements can be achieved. 2166 See~\cite{lazyauspdc}. 2167 2168 Our best advice is to experiment with it. 2169 2170

## Properties

Name Value
svn:eol-style native
svn:keywords Author Date Id Revision

 ViewVC Help Powered by ViewVC 1.1.26