Representing MEP Systems as Graph Data for Rapid Simulation and Analysis

WILL REYNOLDS: OK, let's go. So hello, everyone. So thank you for coming to my class on "Representing MEP systems as graph data for rapid simulation and analysis." Sorry about the long title.

So my name is Will Reynolds. So I work for Hoare Lee, which is the UK'S largest MEP consultancy. We have 10 offices in the UK and 2 offices in the Middle East. So Hoare Lee is mainly MEP. We don't have any architecture or any structural groups. So it's mostly MEP and some specialist groups as well.

So I actually started Hoare Lee 13 years ago. So at that point, it was mainly at document control, so I was automating processes with AutoCAD and uploading things to extranets.

So I saw a lot of potential at that time for automating those processes. So then Revit quickly came onto the scene, and I started building addins for Revit as well, so things like data links, automatic generating sheets and views, all those kinds of things.

And an interesting one we did was with Radiance. So we exported the geometry from Revit to Radiance. And we did the backwards Ray Tracing in Radiance and brought that data back into Revit and displayed it as points in the Revit model with the visualization framework.

So I'm going to talk to you today about graph data. This is something that I've become quite enthusiastic about. I can't really show it because I'm British, so it doesn't really come across. But yeah, I am quite keen on it.

So the more work I do with it, the more potential I see for it. So hopefully, at the end of this session, you will share some of my enthusiasm for it.

Here's when the clicker decides not to work. So you've seen this and that already. I've already explained most those points. My contact details are there. They'll be available at the end anyway, so we can move on from that one.

So the agenda-- so what am I going to go through today? I'm going to start off with a brief explanation on graph data. So what is graph data? Then I'm going to go on to an explanation about why it's useful in MEP systems.

And then I'm going to go through a practical example of how to apply it at the design stage. So that's when we have a Revit model. I'm going to touch on some very brief examples on using graph data in the construction stage and the occupation stage as well, and then some questions at the end. So if you have any questions, please remember them or write them down. I'll be throwing some sweets, chocolates, out to the audience for any questions asked at the end.

Hey, excellent. OK, so when I was going through my presentation with my partner, the first thing she thought graph data was was charts and graphs. But of course, as some of you know, it's not about charts and graphs. It is about connections. It's all about connections.

So it has Nodes, and each note is connected by an edge. So then each node can have multiple properties. And the edge has multiple properties and has multiple labels as well. So a label is the type of node that it is. And properties are metadata that's embedded in the node.

And then the edges themselves also have multiple properties. But the edges only have one type. So if you want to represent multiple types, then you use multiple edges.

And also, edges can be directional. So in that example below, so Jim is wearing size nine Nike shoes. So a directional relationship because Jim wears the shoes, and the shoes don't wear Jim.

So essentially, graph data is a database. But it doesn't require a rigid schema. So you don't have to build your tables in advance. You don't have to know anything about your data structure. You don't have to build entity relationships upfront. You can do that all on the fly.

So then with that, it is highly optimized for graph traversal. And it's incredibly efficient at querying complex related data. So you could have millions of nodes and edges in your graph database, and it would still perform optimally when you run your queries against your data.

So graph data is actually extensively used in a lot of other industries. You will be familiar with social networks. So of course, it's used by Twitter. Facebook, Microsoft, and Google are using it to an extent. And the other industries it's used in is the financial industry. It's used quite sensibly for fraud detection. And it's also used in IT operations, representing data networks. And it's used in AI and machine learning.

So I'm going to go for a very simple MEP example just to give you an idea of how it would work for MEP systems. So we have one single space. And in that space, we generally have an extract and a supply system with air flow into and out of that space. And then those systems generally connect to a piece of equipment, which could be an air handling unit. And that piece of equipment vents and pulls in air from the outside.

So that is concepts which you might write down on a whiteboard or something. And that can be represented directly in the graph data.

So how is this useful for MEP? So moving on from that example, so MEP systems wouldn't be systems without connections. So water flow through pipes, that's all connections. Drainage system is connections. Airflow connections, electrical flow connections, and essentially all of these systems are energy flow, which it can be-- which is also connections.

And then thinking more abstractly about movement, occupancy and moving through spaces, how people move from one space to another, for instance, the doors that they go through, that is also actually connections. So connections are of primary concern in MEP systems, so it makes them an excellent fit for graph data.

So I'm going to give you a quick sneak preview of what's to come. We have some bullet points to follow after this. So hopefully, this will provide some interest before I hit those bullet points. So let's just play this one.

[MUSIC PLAYING]

OK, so don't worry if you missed some bits of that. It moved a bit too quickly. I'm going to come back to some of the principles on how I got there.

So the bullet points-- so the advantages of using graph data in MEP systems. Well, the first thing is, as I alluded to earlier is, how you think about the design and the way in which models in your graph data can be the same. So this allows you to focus on the design and not the intricacies of the software you might be using.

And ultimately, it makes it easy to convey your designs to others. So once it stores in the graph data, you can just show that to others, and they can interrogate that data and understand the systems you're trying to represent.

So another thing, more importantly, is it also enables you to convey your designs to machines. So that enables things like machine learning to read your graph data, perform analysis on those systems, and draw their own conclusions from it. And also, with that data, it scales in unison with the project.

So you might start off with a concept design. And then as you go through the design and add more detail to your graph data, the graph data will scale. So you can add more nodes in, more information into the data all the way from the concept design to the construction and occupation stage.

So a bit more about the concept design-- so another key point is you can create systems and connect them up before they exist in any Revit model. And you can use calculations of your choice on that graph data.

And then also, you can modularize your system. So you might have standard diagrams or standard schematics of plant equipment, standard building types, standard designs. You can represent that in the graph data and use that across several projects with any projects that requires their assistance.

Then what about the geometric context? That's another important thing to consider. So how does the graph data capture that?

Well, you could have a feature extraction stage, which just takes out the most significant features from the geometry and ignores the insignificant features which aren't required for the calculations that you're going to use.

So in that example, we have one space, and it's bounded by another space. And there's a surface in between which is on this wall And then that is all of the data you need for any kind of fabric loss calculation, is just the area of the surface and information about the wall that it's on. So you can capture that data directly in the graph database.

So what about versioning? Say, you are going to have multiple versions of the same information, how does the graph data capture that?

Well, in this example, we have one space. And that space is actually present in two different models-- version 1 and version 2. And that's represented by these two elements-- element 1, element 2. And the ID of those elements in that model is represented by these ID numbers on the Realized By relationship of the edge.

And then you might have IFCs, or you might have a derivative model produced by the automation API. So you have these two purpose models here and an IS_OF relationship. So from the derivative model, you can find the space. And from the space, you can find the two models that it exists in.

So how would you use that for analysis and simulation? Well, the key parts is that it's easy to query the data. So I'm going to show you some examples using Cypher. And you'll see how easy it is to extract data from the database. And with the feature extraction stage, complex geometry becomes simpler.

And so then if you have any simulation algorithms, they might not need to continually pass the geometry, because the feature extraction stage has already given enough information for their analysis. So other software such as IES, TAS, Sefaira, and Open Studio could read that graph data and write their simulation data back into it.

And you could reuse graph data from previous projects. So where you might have run simulations against previous projects, you can use those again in additional projects that use the same information.

So here you go. How can it be practically applied? So I'm going to go for a practical demo. I'm going to explain a bit about the architecture I've chosen. So the graph database is Neo4j.

So I've chosen that one mainly because it was in the top three results in Google. But it also actually has a very-- it gives quite a mature product, and it has a very-- well, it's about the community, and it's in the continuous [INAUDIBLE] at the moment. So that sort of space moves actually very quickly. Neo4j has been around for, I think, three, four years. And that's a long time for technology these days.

So I'm using Node.js to run the application logic and serve up the web interface for the browser. And I'm hosting both of these in Docker. So the reason I've chosen Docker is it makes it incredibly easy to test and deploy your apps. It makes it extremely easy to bring up your instances and push into any hosting service which you want to use. So in this case, I've used Microsoft Azure.

So the reason behind that is it's used extensively in my company, so I might as well use that. And I know that AWS is an Autodesk partner. And so you could easily do this in AWS as well, or any other cloud service, really.

So I'm using the Revit API to convert the models to graph data, and I'm pushing that data back via Node.js to Neo4j. And then I'm using the Autodesk Forge data management and derivative and view API. So it generates the viewers from the Revit model.

So practical implementation-- so I'm going to go through four steps, the first of which is setting up Neo4j and the .NET and JavaScript drivers which are available for it. And then I'm going to go through converting a Revit model to graph data and the various techniques that you can use to do that. And then, finally, I'm going to go through some visualizations and analysis of that graph data, and then a brief information on how to write data back to Revit.

So setting up Neo4j, so as I mentioned, using Docker, it's incredibly easy. So once you've installed Docker, you just run those two commands. So docker pull downloads the Neo4j image, and then just run it locally. It's just that command there and the ports that it uses.

And then you just point your browser at that location. And then your graph is ready to go. So it's incredibly easy. So Docker can be stored on Windows and Linux. I'm pretty sure it can be stored on Mac as well. I'm not sure on that. I have to check.

But yeah, so once you've got your database set up, you want to write to it. So you can obtain your .NET and JavaScript Neo4j drivers using the manager of your choice. We have .NET, NuGet, and you can use Neo4j/Client for that, with Node.js as an NPM. And it's this install neodes, which is a wrapper around the Neo4j driver. It just adds some extra functionality.

So then an option is that you might want to push your image to the cloud. So I'm not going to go into detail on that, because that would be an entire class in itself. There's various options for doing that. So I've actually used Azure Container. So if you want to learn any more on that, just let me know, and I can go through how I did that.

So the algorithms and the techniques for reading the event model and pushing it to Neo4j-- so if the circuits, ducts, pipes, the cable trays, I've actually just followed the connectors. And each time I hit an element, I push that element to the database. And I also push the spaces and the levels the element is on, push that data into database. And with that algorithm, if we're hitting the elements, I've already paused. I don't want to go back into that, because that would just send me into an infinite loop. So ignore elements that you've already visited.

And then the traversal algorithm itself, I designed it as iterative rather than recursive. Because of the connections you follow through, you're going to quickly hit the stack limit, because you go through several different connectors. So that it's iterative.

And I also made it a two-stage process. So I made it push the data in in-memory graph first. And once that's done, it pushes that data to the Neo4j database.

So this could all be performed in Dynamo. You would need some custom nodes. I had a search for any Dynamo nodes which does it. I didn't find any yet. You could do a bit of Python or C#. If anybody is interested in Dynamo nodes for this, let me know. I'd be very happy to build some nodes for that.

So a practical example of this is getting on from the middle video that we saw. So I'm going to go over to our web app that we built for this. It's going to be the right one. So this is coming from all the information that's in the graph database.

So I'm going to go into Projects. I'm going to go into the Model. So it brings up the model. So this is the Western transit shed in London, which happens to be our London office. So that's quite a simple building. Actually, it's a simple design example.

So the first thing I'm going to show you is the electrical system. So this is the Cypher query for returning all of the electrical systems. It's fairly short. So just hit the Play button, and that brings up our graph. I can actually move that and expand that.

So this is the entire electrical system, well, that's modeled for this building. It doesn't actually include the entire system, because you haven't modeled it all. It's just the information that's been modeled. But if you click on the back there, it will highlight-- yeah, it's supposed to bring up the information in the model.

Let's try exiting your panel. OK, that took a bit of time. But it should be more responsive than that But as you select stuff, it highlights it behind. So this is the incoming panel for the building, which flows onto circuit L23. So this distribution panel, which then goes to these two circuits, this one has all the [INAUDIBLE] on it. And this one has all the sockets on it. So as you click on those, it highlights them in the model.

So then what if you wanted to know the cable tray between two spaces? Well, there is a query for and it looks like this. Again, it's fairly short. Once you get familiar with Cypher, it's quite a verbose language. But it's quite easy to read, I think.

So you hit that. Right. So you hit All Highlight in the model. Right, let's hit Refresh. And it's quite important that it shows it in the model, because that was kind of what I'm trying to illustrate. So let's try that again.

So let's go. I'm going to show you in the cable try between two spaces. There we go. That's what it's supposed to do. All right, so let's just move into that model. So you see that. That's the insides. It's the cable tray between these two spaces.

But what if you wanted to know the shortest route in the cable tray between these two spaces? Well, there's a query for that as well. So Neo4j natively has a way of doing this, but it doesn't take into account weights.

So I've included a addin for Neo4j for the Epoch extension. So that enables us to find the shortest distance between two spaces. Argh, damn it. So as we click on here, it shows us that is the shortest distance between the two spaces. And you can follow the graph along.

So mechanical systems-- so remember, if you want to know the ducts between two spaces, there's a query for that as well. I'm going to hit Refresh because it's not working. Ducts between two spaces. All right, work. Oh, it's carrying on. I would say it worked fine. And anyhow, it's playing up now.

So we want mechanical. So let's do these from-- so we're going to go from space to the AHU. So we're going to find the duct path from the space to the AHU, which serves that space.

Anyway, there we go. Maybe before I hit this, it's going to work. So actually, I double-clicked. Let's try that again. Space 2H here, go. So I click on the space, and it highlights all of the elements that are in that space.

Let's try and find the other space. There should be another one in there. Is it really? Oh, maybe not. All right, it's AHU. That's why. So that's the air handling unit. Oh, it's done it. OK, just took a while.

So that's the entire duct run from that space to the air handling unit. So what I wanted to find, the shortest run for the LTHW circuits from the radiators, as there's a query for that one. So that's it.

So that's the boiler, and so it runs up the pipe run, all the way back to the radiator. I wish it would show the run. But yeah, it's supposed to show the-- in the model, it would show the route when you click on the space there, but it's not working at the moment.

So what about spaces? So for the space boundaries, So this query gives us all of the boundaries for this space. So this is between the reception room and the conference room. These are the walls, so there's a wall there. Can you see that?

And there's another wall here, and there's another wall-- there's a door there. So and each of these boundaries has the area, which is just down there, which you can't quite see. But all of the data is in there about the area of intersection between those two spaces on the surface.

So what if you wanted to know the boundaries to the outside? So we have a query for that. So this shows us all the boundaries from the breakout area to any outside areas. So we have a surface area which is a window, a surface area which is this wall here, and a surface area which is the floor, and another wall. And this one is the roof.

So that's all of the surfaces, and the surfaces themselves only have the intersecting area of the space. They don't include the entire area. It's just the area which intersects between those two areas. OK, so that's what I wanted to show you for that bit.

So I showed you electrical systems, and that's the simple query for returning the entire electrical system sets from the DB panels to the circuits to the final elements which connect to those circuits.

And then I showed you the mechanical systems. So that's a duct. That's a query for ducts from room to another room. So that's from Room 0101 to Room 0102.

And the terminals are between those two spaces. So that might be useful for acoustic analysis if you wanted to figure out any crosstalk between those two spaces. And then surfaces between two rooms. There's a Cypher query for that.

So what about the geometric extraction stage? So I'm going to touch on this briefly. So how did I figure out the rounding errors between these spaces?

I actually used brute force ray trace method. There's various other ways of doing it, but essentially, I took each boundary. I converted it into a grid of points. And I projected a ray from those points and found out everything that intersected. So if it intersected a window, I knew that was a window intersection. If it intersected another wall, I knew that that was another wall between those two spaces.

And then there's an aggregation stage where I added up all of those intersections and then calculated the total area. So then I also grouped the rays by the direction they were facing in. So if we had two different parts of the wall, but they're both facing in the same direction, that would add up to the same surface. So actually, if you want to know any more information about how I did that, just let me know, and I can go through how I did it.

So visualizing and analyzing the data-- so in terms of the Forge Viewer and the way it was supposed to work, because you kept on things and it showed you what was visible, so I just did that by matching up the unique ID, which is returned by a Forge Viewer. So you get an ExternalID, which is returned by the Forge Viewer, and a unique ID which was stored in the graph database. So just match those up and hide them in the Forge Viewer.

So visualizing and analyzing the data-- so I'm going to break out to Power Bi. So I created a customer query. So yes, the important thing I should mention is that Cypher queries can return tables, as well as the nodes themselves. They can return tabulated data. And Cypher has aggregation and math functions built into it.

So let's have a look at the Power Bi query. So this is one I did with a much larger model. In this one, there was 100,000 nodes. So it's telling us the total model element count between two different versions of the model.

So in the first model, it had 14K. And then the subsequent model, which was released later, had 25K. Total elements were 205% change. Don't do the math on that, because I know that's slightly wrong. It must be something to do with the rounding.

So we can filter here for the spaces. This is all the data that's been derived from the graph database. So I'm going to go for a particular room which I know shows us some reasonably good information, which is 2C01. There it is. So I can filter down to a particular space, and I could find out the element changes within that space, broken down by the category and the total elements.

And maybe slightly more interestingly, for the space boundaries themselves, we might build some Sankey diagrams. We use this as just an example of how the space data can be used for visualizations. So this is just showing the boundaries between two different spaces or more than one or more than two, several spaces, and the areas which bound those spaces and which ones have common boundaries.

So that's the space boundaries in this Power Bi. So what was I going to move on after that? Let's just get back into the PowerPoint. So this is the first thing you need for that. So I went through spaceCount verification. So you can also verify elements that are fully connected. And you can visualize heating and cooling those as well.

So simulations-- this was a bonus slide which I wasn't going to include initially, because I didn't have anything working for it. But I've got some Cypher queries which I'm just going to run through very quickly, which is on this one. And let's close that.

So the first one, so for every single space, I set a design temperature of 21, as in this case it was degrees centigrade. So that was a simple query. And then I set the environment information. So I set that with a design temperature of 18 degrees centigrade.

So then after that, I wanted to set the delta. So for every single surface, I want to figure out what is the temperature delta for that surface. So that was the Cypher query for that. So it finds every boundary, and it finds what's on either side and just deducts the two. So that returns the services.

And then I wanted to find out the fabric loss for those spaces. And that is just made up of multiplying the area of intersection of the heat transfer coefficient and the design temp delta, which we just added in the previous stage. So that gives us sort of a-- it tells us of our fabric losses.

And then I want to add those up. So for every single space, I want to add up what is the total fabric loss. So that's a query for that. So that, for every single space, it gives us the sum of the fabric loss, which I think is in watts. And I'm not actually an engineer, but from the [INAUDIBLE] that I've given us, I think that was in watts.

So that's a very simple way of illustrating how the analysis can be performed directly on the graph data. So that was simulations.

So writing the graph data back-- so I've cheated a bit here. So I actually ran out of time. I was working on this for three months. It's been an intensive three months.

But I'm going to refer you to Jeremy Tammik's excellent example on how to do this. So I think he was using a Mongo database, but in this case, we're just changing that for a Neo4j database.

And one of the key advantages here of using Neo4j is that you can easily build in a change management system if you want to. So you could have an Accept or Reject methodology. So you could have a node, and you can have some information on that node that says, accept these changes in the Revit model. Or you could have information that says, do not reject these changes from the Revit model. So that could all be represented in the graph data.

So at Hoare Lee, we actually built a system for generating schematics. So what we do is we have a configurator. And we put some information in that configurator, and it builds a schematic for us. So all that data that you see on the left-hand pane, we can store that in the graph database. So that's the amount of boilers that we have and some other information about their primary and secondary interfaces and things-- CHPs and all sorts of mechanical things. So you can still [INAUDIBLE] databases from that. Then we can build a schematic directly. And later on, when we come to actually inserting those elements in the model, we can relate that data to the Revit elements as well.

So example using construction-- so one of the bugbears of fabrication parts is that they don't include the original calculations. And there's no way of finding flow rates with those. With the graph data, you can connect the fabrication parts to the original design elements. Or you can run those calculations on the graph data directly.

So example use in occupation-- so at this stage, you might have some sensor data. You might have some IoT data in place. So you can associate your IoT data or your sensor points to the actual elements in the model which they're sensing. So that could be spaces. It could be temperatures in pipes and in ductwork. So you can relate it all back to the original elements.

So if you have your graph data, which includes the concept stage as well, you can relate your design all the way back from your end use data, all the way through the design stages, to your concept design stage information. So you can feed that performance information to that design, which can inform your future designs.

So agenda revisited-- so to start, I covered a bit about what graph data is. So hopefully, you saw that it was simple, yet powerful. And then I went into why its use of systems. So hopefully, you saw that it was a perfect fit for MEP systems. And then I went through to pathway examples which hopefully showed some enormous potential. So the information I showed you was quite early in terms of the development that we've done. But hopefully, you maybe have some of your own thoughts on how you could apply it.

Then the next stage will be the questions. So if I could have a show of hands, who might be considering using graph data for any of their work or application ability? OK, that's good. We have quite a good uptake on the--

So there are some resources on learning. Actually, what I wanted to ask as well is, how many people would be considering using Dynamo for graph data? Excellent. OK. So I will consider building some nodes for Dynamo.

So those are the resources. There's two free ebooks from Neo4j, so online courses from LinkedIn and Coursera and MyGithub repository. I'm going to put the Power Bi template query for that on there. And I can post as much open source stuff as I can on there as well. And then it's information about the client packages which you can use.

So you've arrived. We're early to the questions a bit. So are there any questions? Yep.

AUDIENCE: Now, you've heard of jumped over the park. How difficult is it to take a Revit model and extract the data and put it into the graph database?

WILL REYNOLDS: Our graph database-- yeah, so that took me three months to do. So as was mentioned, the Dynamo, I suppose it is fairly tricky. So actually, the trickiest part is the geometry extraction. In terms of turning the connections of ducts and pipes to graph data, that's quite easy, because in the Revit model, that's all connected up anyway, almost in a graph data structure. So if you're just interested in that data, it's quite easy to get that out to Neo4j.

Yep, so I'm going to throw you a chocolate. Do you want chocolate? There you go. Yeah. Duck.

AUDIENCE: [INAUDIBLE]

[LAUGHTER]

WILL REYNOLDS: Oh, it's short. All right.

AUDIENCE: [INAUDIBLE] really cool step--

WILL REYNOLDS: Thank you.

AUDIENCE: --of trying to take an already [INAUDIBLE] model and to graph data [INAUDIBLE]. Or you have a model, and you add elements and spaces and kind of do your analysis, like you mentioned. Can you expand on what you've done there?

WILL REYNOLDS: Well, I've done the concept stage. So the question is, expound on information about what I've done in the concept stage and about connecting up spaces. So it was a good question. I haven't actually done it a lot.

So what I showed you was the design stage and extracting information from the Revit model. So yeah, that's something that I want to do more on, but I think, definitely, that is where the main potential is, is including that information before you have the design in your Revit model. Thank you.

Chocolate? Fudge? Oh, sorry. That was a bad one. Another one? Yeah.

AUDIENCE: So when the rest of my company works in Revit, this would be a good adaptation for them. I unfortunately work in an AutoCAD-based typing package [INAUDIBLE]. As soon as I can get connected with information out of the database for that, is there any reason why I couldn't use the same database to ask questions of that nature?

WILL REYNOLDS: Yeah, exactly. No, there's no reason. So it depends on how you can-- so you say you used AutoCad and another package?

AUDIENCE: AutoCAD-based, but I have a backend database that I can [INAUDIBLE].

WILL REYNOLDS: So yeah, so you just need, essentially, a converter. And you'd need to-- which would write to the Neo4j database. So it depends very much on that database and how the data is structured in there. But there is no reason why you couldn't do it, really.

AUDIENCE: Thank you.

WILL REYNOLDS: OK. Yep.

AUDIENCE: So I'm a pretty heavy Dynamo user, and this is kind of over my head [INAUDIBLE]. It looks like it's mainly query-based [INAUDIBLE] push back [INAUDIBLE] from the nodes back into the model.

WILL REYNOLDS: So that is an application implementation. So you can definitely query data. You can run analysis that changes the data directly. But in terms of reading it back, you'll need to write some in-- and I don't know whatever system you're using-- to take that data and then write it back to whatever model you have.

So if that was what we'd done with it-- it's just as easy to push data in as it is to pull data out. So when you're pushing data in, you're reading your model. And then when you're putting data out, again, you're just writing the model. So essentially, it's the same process, only in reverse. So it's just as easy to write data back.

I think, for you, a sweet as well. I should be a better aim for this one.

AUDIENCE: All right, slightly lower.

WILL REYNOLDS: There we go. So any more questions? Yeah.

AUDIENCE: And then you mentioned also pushing data into other analysis software, right?

WILL REYNOLDS: Yeah.

AUDIENCE: I asked [INAUDIBLE].

WILL REYNOLDS: That was a definite you could. I mean, I know that, particularly with Open Studio, the internal object model for that is a graph data anyway, I think. And then the APIs for that are pretty good, very open. So that is definitely a possibility. And that is something that I'm actually looking into next. So I'm aware of that but haven't actually any practical examples of that.

If you're going to get in touch, I will let you know how we get on with that and share as much as I can with you.

AUDIENCE: Cool.

WILL REYNOLDS: OK.

Any more questions? Cool. And with that, please complete the class evaluation on the AU app. That's my class ID and some contact information. Thank you.

[APPLAUSE]