2.4 The Scala Programming Language
3.1.3 The NanoDSL: A Textual Language for Describing Experiments
decision for a textual concrete syntax was also based on discussions with the domain experts. A textual syntax is better suited for expressing mathematical expressions. Also, there are many tools for managing text files, e.g., for version control and comparison. We useXtextbecause it is specifically designed to create textual DSLs and their tooling. In
3.1. The NanoWorkbench – A Workbench for Experimental Physics 47 the following subsections we explain the NanoDSL’s domain-specific concepts, how it is described usingXtext, and present the language tooling generated from this description.
Concepts and Structure of the Language
An experiment description in simulation-driven nanostructure development is divided into four main parts: (1) a description of the structure itself, i.e., its material and its geometry, (2) the simulation parameters such as resolution and time, (3) placement and properties of electromagnetic sources, and (4) the specification of monitors which define what information is to be collected during simulation, e.g., a two-dimensional plane in the three-dimensional simulation space.
The domain experts’ typical approach to the description of the geometry of a photonic crystal is as follows: First, the parameters of a periodic lattice of holes are defined, and afterwards, modifications to that lattice are described. Thus, the starting point is always a flat cuboid which represents the membrane, and a lattice of holes within this cuboid.
The parameters for the lattice are defined as follows: First, the alignment of the holes is specified: either rectangular (90 degree) or hexagonal (60 degree). Next, the distance between the holes and their radii have to be defined. Finally, the number of holes is set by specifying a two-dimensional array. Fig. 3.5 shows the rectangular and hexagonal arrangement and the two main lattice parameters: hole radius (r) and hole distance (d).
Figure 3.5: Orthogonal (left) or hexagonal (right) lattice setup (from Schmidt, 2011) For the next step of the structure description, means for modifying the lattice of holes are provided. For convenience, the NanoDSL provides means to select and modify a single hole as well as a selection of lines or ranges of holes. The earlier defined array of holes serves as a two-dimensional coordinate system whose origin is located in the middle of the lattice. Each hole – being identified by its coordinates – can be deleted, moved or overwritten by another geometrical object. Furthermore, it is possible to add other geometrical objects, and to define different materials to alter the standard setup. Fig. 3.6 exemplifies several ways of modifying the lattice by deleting a selection of holes from it, and shows the concrete syntax for the corresponding operation in the NanoDSL.
In the simulation part, parameters of the simulation are specified, for instance, the simulation space can cover the whole nanostructure or only a selected region.
Further-48 Chapter 3. Model Synchronization in a Domain-Specific Workbench
Figure 3.6: Delete edit operations for modifying the lattice of holes (from Schmidt, 2011) more, the simulation time and the resolution of the simulation are defined. The settings made in the simulation part affect the resource consumption of the simulation the most.
The next part of the experiment description defines sources of electromagnetic pulses that are propagated within the photonic crystal. A source can be either a narrowband or a broadband pulse. Additionally, the position and direction of the pulse can be defined.
The last part defines monitors, which determine what data is to be collected during simulation. We identified three types of monitors: a box monitor which collects data in a given three-dimensional space, afrequency-domain field monitor which analyzes data over a given frequency spectrum, and apoint monitor which focuses on a single point.
Listing 3.1 shows the structure part of an experiment description in the NanoDSL’s concrete textual syntax. The described structure is the photonic crystal which we showed before in Fig. 3.1. The keywords of theNanoDSL’s textual syntax were defined according to the domain-specific vocabulary of the domain experts, for example, the cuboid rep-resenting the thin membrane is called aslab. There are no units used in the experiment description because they are either implicit – for instance, the standard length unit in that domain is nanometer – or they are explicitly defined globally for the complete model.
Describing the Language, Starting With the Concrete Syntax
As we explained in Sec. 2.2.2, for a metamodel-based language the metamodel is the pivotal artifact of the language description, and concrete syntax and semantics are defined with respect to the metamodel. For example, it is described how elements of the concrete syntax are mapped to elements of the abstract syntax.
Because Xtext is specialized on textual languages, their concrete textual syntax is usually described first, namely by a grammar, and then the metamodel is automatically generated from that grammar. We call this theconcrete-syntax-first approach. Listing. 3.2 shows a small part of the grammar which describes theNanoDSL’s concrete syntax, and which indirectly also describes theNanoDSL’s abstract syntax. The rules of the grammar are described in an EBNF-like grammar-description meta-language provided byXtext.
In Xtext’s grammar description language, the name of a non-terminal production rule
3.1. The NanoWorkbench – A Workbench for Experimental Physics 49 Listing 3.1: The structure part of an experiment description with the NanoDSL
1 SETUP { ... } // omitted here; contains project name etc.
2 STRUCTURE {
3 material GaP = 3.3 // the refraction index of gallium phosphide
4
5 Slab { // defining the cuboid representing the membrane
6 material = GaP // referencing the material defined above
7 thickness = 70.0
8 }
9
10 Lattice { // defining the lattice of holes
11 lattice_type = hexagonal // 60 degree alignment
12 lattice_size = (19,17)
13 lattice_distance = 209
14 hole_radius = 0.4 * 200
15 // modifications to the holes surrounding the cavity
16 overwrite region from (-4,1) to (4,-1) {
17 Cone { radiusGround = 65; radiusTop = 65 }
18 }
19 overwrite region from (-4,0) to (4,0) {
20 Cone { radiusGround = 55; radiusTop = 55 }
21 }
22 move (-4,0) { x_offset = -0.3 }
23 move (4,0) { x_offset = 0.3 }
24 // the actual cavity
25 delete horizontal line from (-2,0) to (2,0)
26 }
27 }
28 SIMULATION { ... }
29 SOURCES { ... }
30 MONITORS { ... }
starts with an uppercase letter (e.g. Model in line 1), and the rule’s body follows after a colon. As the most important difference to an EBNF grammar, non-terminals inside a rule’s body can be preceded by an identifier and a ‘=’ to indirectly define fields in the classes of the generated metamodel. In line 2, theModel rule refers to theSetupSec rule, and at the same time defines the fieldsetupSec in the generated metamodel class Model. A multi-valued field – and at the same time non-terminal repetition – is defined by (field+=Rule)+or(field+=Rule)*, respectively, depending on whether the field is allowed to be empty or not. Importantly, an abstract rule which only consists of alternative non-terminals, for example the Objects rule in lines 23–24, results in an abstract class in the metamodel that is inherited by the classes which represent the alternatives. Fig. 3.7 shows parts of the metamodel generated from the grammar. One can see that models which conform to this metamodel are graphs, e.g., classSlabcontains a non-containment reference to class Material. However, the containment relations form a spanning tree within this graph, with an instance of class Model being the root of the containment tree. This is enforced for EMF-based models in general, and for metamodels generated by Xtextin particular.
From the concrete syntax description and the metamodel generated from it, Xtext can automatically generate a rich-featured textual editor for the NanoDSL. Features
50 Chapter 3. Model Synchronization in a Domain-Specific Workbench Listing 3.2: A part of the grammar describing theNanoDSL’s concrete syntax
1 Model:
2 setupSec=SetupSec
3 structureSec=StructureSec
4 simulationSec=SimulationSec
5 sourceSec=SourceSec
6 monitorSec=MonitorSec;
7
8 SetupSec:
9 "SETUP" "{"
10 (values+=Instance)*
11 "project_name" "=" projectName=STRING
12 "}";
13
14 StructureSec:
15 "STRUCTURE" "{"
16 (material+=Material)*
17 (objects+=Objects)+
18 "}";
19
20 Material:
21 "material" name=ID "=" index=NUMBER;
22
23 Objects:
24 Slab | Lattice| Element;
25 26 Slab:
27 "Slab" "{"
28 (("position" "=" coordinate=Coordinate3D)
29 &("material" "=" material=[Material|ID])
30 &("thickness" "=" thickness=Calculation) )
31 "}";
provided by the editor include syntax highlighting, code completion, error highlighting and an outline view which supports code navigation (Fig 3.8).
3.1.4 Model Transformation: Code Generation and Multiple Views