Define System Architechture

[eak24]

We need to clearly lay out what this component will do. My expectations are that this will be able to generate both (with the help of the fusion templates) the construction/ fabrication drawings of the plant as found here. The Fusion form of Layouts is called drawings, and here is a tutorial: here. The other produced document will be made by filling in the technical document with variables to produce something like this. The last task of aide_document, perhaps, is to assemble a budget. We might want to make that a whole different team/repo.

[matanp]

hi ethan, can you clarify what you want with fusion templates? Are we supposed to be generating drawings and putting them into the report? or are we getting images from the draw subteam?

[eak24]

The draw team will not give you images. You need to generate these images using the Fusion API. However, that is far in the future. The initial goal is to create a function that can take a latex document/template and a JSON and replace all instances of a variable with the variable itself. For this, you'll need to define how variables will be identified in the text (you could employ your own latex extension/macro that has some command like \aide{variable} but I don't know more than that) and you can assume for now that the JSON has that variable and it is easy to find. Does that sound like a reasonable first step?

[eak24]

I had some additional thoughts. I think before we continue coding, it would be nice to develop a google drawing that lays out how the various components of AIDE Document might play together, much like the overall AIde google drawing I presented at the beginning.

My initial thoughts on AIDE document are:

• This is essentially a markup language processor. The markup is written in the template, and can refer directly to plant components. Then our processor can insert the various injections directly into the document. We don't need to build the processor itself. That should be handled by some Latex processor. Instead, we need to extend the processor to accept these AIDE-specific commands. The other side of the coin is to extract the relative variables and expose them to this Latex-processor plugin. I don't know what this interface would look like, but I can imagine a special resources file that holds all the available plant variables in a latex-plugin-readable file format (probably CSV). This way there is a clear distinction between the Latex-component of the project and the Python component. Think about how this injection system could be extended to images. Perhaps the image is yet another value in the CSV that points straight to the local path of the image (either generated during the draw stage and handed off by the draw team or an image that comes with the package, like a general picture of one of the plants. Nothing in this should be AIDE-specific. I should be able to supply AIDE Document with any collection of photos and variable - value pairs, and AIDE document should give me the Latex handles to dynamically expose those variable's values in my markup.

The architecture drawing should propose large-level components of the Document package. Think of it as the Document- zoomed in part of the overall AIDE diagram. It should answer the following equations:

• What major sub-packages are needed? What are the vague boundaries and responsibilities of those sub-packages?
• How will the sub-packages generate the final document?
• How does data flow throughout the system?
• How does the Document package call external get calls from GUI? How does it send the result back? I would love to work on this with y'all. I recommend starting a google drawing and sharing me. I can make comments and suggestions.

[matanp]

Here is our draw document

https://docs.google.com/a/cornell.edu/drawings/d/1KudRQDT9GUF4GrYHp4_e4gnnPHMiAQGUW_rgc_TZ108/edit?usp=sharing

[matanp]

new link https://docs.google.com/a/cornell.edu/drawings/d/1GeeBO_IWdfD37bqwtXc1Ue8wrP2hBddeEwFGURTDJwg/edit?usp=sharing

[eak24]

This is a good start of an information flow diagram. The goal is to now see how that translates to the particular modules and packages that will make up Document. This should explain proposed internal and external interfaces with example function calls. The goal is to define a rough API that will enable y'all to work simultaneously without stepping on one another's toes.

Thoughts on the diagram:

• I don't think document should touch fusion. If anything, aide_draw can supply you with renderings of certain components, and you can put those in. but don't talk to Fusion. Ideally document should run with the inputs of: json, folder with images, folder with templates. And that is it.
• I think you could do all the find and replace pretty easily through Latex. This could be a latex plugin. I recommend learning how to make one of those. I'm thinking when someone is writing a template, they will be able to inject variable values and images with code that looks like: \aide_variable{plant.floc.wall.length} and \aide_image{images/renderings/floc_side_view.png}

[matanp]

That all sounds good, I will work to make everything more concrete and figure out what packages and such we want. To confirm, does you saying not to touch Fusion mark a change in the process? In a previous comment on this thread you said "The draw team will not give you images. You need to generate these images using the Fusion API. "