aguaclara / aide Goto Github PK
View Code? Open in Web Editor NEWAguaClara Infrastructure Design Engine - a software tool that designs AguaClara water treatment plants and their components.
License: MIT License
AguaClara Infrastructure Design Engine - a software tool that designs AguaClara water treatment plants and their components.
License: MIT License
We've completed our first report for the summer - you can read it here.
You can also navigate to it in this repo, under reports/
.
We've finished our 2nd draft of our Summer Research Report: it can be found here or in our reports
folder.
Create google docs with nicely formatted ABOUT descriptions of how to use each Smart Component.
Then upload the pdf to Onshape. Here is a great example.
@ethan92429 In order to implement your solution of having aide call aide_gui, we would have to have the F360 command (from the aide Add In) to run the palette_gui Add In, which would be nearly impossible.
So we have aide and palette_gui addin code folders within the API/AddIns folder on our computers, and within the aide AddIn code, we would have to import the palette_gui code to run the palette_gui AddIn. However, we can't do from .. import palette_gui
(essentially going up two levels in the file system) because python doesn't allow it. Furthermore, we can't just put the palette_gui folder within the aide folder because F360 must run addins from the API/AddIns, not within any subfolders.
One workaround could be to hard code an absolute path to the palette_gui folder to import, but I want to avoid doing that.
Because of this, would it just be easier to have the user open up the palette_gui and then have the gui run all of aide's stuff?
Here is a forum post (from our good friend Marshal!) which says that it's impossible to run AddIns/Scripts from Scripts; I'm assuming that the same goes for running AddIns/Scripts from AddIns and their Commands.
const configurationStringDefault = '\\\"{"my_parameter_id": "my_value"}\\\"';
Thus when that input isn't used it causes an errror.This is a reminder to comment and finish the LFOM code and validate the full lifecycle.
Automate the creation of design specifications for the LFOM
In the field it's often difficult to balance the counterweight and float. To avoid this, we could add masses to all the parts/materials in the CDC parts studio and calculate the exact masses needed for the counterweight and float.
Hey @IanCullings, we've finished our final report for the summer; you can find it here, or in the reports/
folder in our repository.
After working with the Fusion 360 API for a while, I still think that combining the functionality of aide and aide_gui would be the best way to integrate all of our modules. By that, I mean that aide_gui (which would reasonably be renamed to aide) will gather user inputs, then subsequently call aide_design/draw/document while passing those inputs as parameters. Combining the two would allow us to both avoid the shortcomings of the F360 API and more easily add functionality in the future.
I ran minimal tests on as many of the following ideas as I could, but let me know if anything seems out of place and I'll retest it.
As is currently planned out in the ReadMe's MVP1, running aide_gui will return the location of the YAML containing the gathered user inputs. This can't be done for the following reasons:
None
if a return value isn't given immediately.These problems stem from the fact that F360 add-ins use event handlers, so let's see what happens when we play around with them.
Instead of having aide_gui return the user inputs, I tried having it trigger an event that would notify aide that the user inputs had been written to a YAML. As seen in aide.py and aide_gui.py, event handlers for add-ins are stored in a globally declared handlers
list. In order for this to work, we'll need for aide and aide_gui to be able to "share" this list, either by having aide_gui return its handlers
to aide, or by aide passing its handlers
as a parameter when calling aide_gui.run
.
Having aide_gui return its handlers
won't work for similar reasons to why aide_gui can't simply return the location user inputs:
handlers
can't be returned at the end of aide_gui.run
because by that point, only one event handler (ShowPaletteCommandCreated
) will be appended. There are two others that are needed for aide_gui to work (ShowPaletteCommandExecute
and MyHTMLEvent
), and with aide_gui.run
pushed off of the call stack, there's no way to return those other handlers to aide.handlers
can't be returned after two or three handlers are appended because Python will get "impatient" and just return None
.notify
functions for each event only act within the add-in where they're called (aide_gui in this case), and because they're called from the backend of F360, we can't manually call them from aide.Having aide pass its handlers
list to aide_gui would require the list to be passed it through each of the handlers' __init__(self)
and notify(self, args)
functions so that it gets appended to. This isn't possible, because the F360 backend expects for there to only be the provided self
and args
(in notify
) parameters to be passed and throws an exception when more are given. Even if we managed to get all of the handlers successfully appended, there's still no way for us to get them back to aide for the above reasons.
Overall, the current system of aide being the master controller forces us to use the F360 API in a way that it's not designed for. There should only be one add-in running at a time, rather than an add-in within an add-in.
We discussed the idea that we would want to make aide modular so that each module could be self-contained, and that modules shouldn't reference one another. If we make aide_gui the controller, we can maintain this modularity while still being able to run each module after the preceding module is done.
Here's some pseudocode for how this would look, based off of the current state of aide_gui.py:
def run():
showPalette()
def showPalette():
HTMLEvents.beginHandling()
DesignEvents.beginHandling()
DrawDocEvents.beginHandling()
def HTMLEventHandler():
navigate_gui()
if HTMLEvent is user_input:
write(user_input, yaml_path)
DesignEvent.execute()
def DesignEventHandler():
# NOTE: The location of the design repository and its associated files can be stored in the YAML.
aide_design(yaml_path)
DrawDocEvent.execute()
def DrawDocEventHandler():
aide_draw(yaml_path)
aide_document(yaml_path)
Combining aide and aide_gui would make it much easier to convey when each part of the design process is finished by displaying a different page when each module is being run. Additionally, it would make for an overall better experience for the user when they can see what aide is doing at the moment.
At the end of the semester, we should review and unify all the variable naming schemes used throughout the MVP. For example, some places abbreviations are written all uppercase, like JSON
, but others they are written Json
. In our code, this would look like hlBOD
vs HLbod
.
backwash siphon pipe
valves for tee
update entrance tank
instancing/patterning
debug
sed channel?
This is the angled mold that creates the slot. The mold should be drawn based on the sed tank design because the mold varies depending on the floc properties and temperature.
The Mathcad file and Python code which design the Hydrodoser or CDC are not entirely functional, so I'll have to finalize that logic and then work with students to get it transferred into FeatureScript
Create a scrum tutorial or mock scrum to help new students understand how they should work
Given the standardized parameter names in this file, I'd like to propose a way to assign these names to both our F360 model parameters and our Design code.
Suppose we have the following (abbreviated) hierarchy within a design:
\floc #assembly
\entTank #subassembly
\wall #component
thickness #parameter
Within F360, we would label the parameter as each level of hierarchy, separated by underscores (floc_entTank_wall_thickness). That way, when we break the links when combining components into larger assemblies, we will always know exactly where each parameter came from.
Within Design, we could have the same kind of hierarchy with our folders and Python files. We could have a .py file fro each subassembly, and then each component/parameter would be a global variable (if constant), or a function otherwise (with this example, floc.entTank.wall.thickness
).
This is a fair bit more verbose than our current naming conventions, and changing our current parameters would be no small task, but I think this would prevent us from ever needing to change our variable names due to using the same component/parameter name in different assemblies.
floors
stairs
mates on components relative to floor positioning
This simple Smart Tank will serve as an example of how Smart Components are assembled and how inputs are passed to subcomponents. This entire file can be copied when starting new Smart Components or the code can be copied.
Add demonstration of multiple sub components being controlled by a plant level part studio.
I've been thinking about how we can improve upon the current structure of the AIDE subteam and where we're headed in the coming academic year. Here are some ideas I have:
Upon cleaning out the AIDE GDrive folder (which was pretty messy), I realized that the vast majority of our organizational tools can be ported over to the functionality in Github: issues for to-do's, discussion boards for status updates, etc. I think the GDrive folder should only be used for:
Everything else should go in AIDE repositories, wikis, or AIDE teams' discussion boards. The benefit of this is that it reduces the amount of maintaining we'll have to do, and it will make AIDE team members more comfortable with using Github - something they'll inevitably have to do in their future careers.
AIDE members almost always fall into one of two skill sets: CAD-ing and coding. There's definitely no expectation that team members should switch between those two skill sets. As such, AIDE Template should remain as a discrete (sub-)sub-team within AIDE.
But instead of having sub-teams that each specialize in a single AIDE module, I believe we should have general coding teams that can work on any module necessary. This could take the form of 2-3 coding teams (called AIDE Code A/B/C, or perhaps something that doesn't imply a hierarchy ๐), such that each team's members are working together for the entire semester. These coding teams wouldn't be tied down to a single AIDE module, and instead would have the freedom to switch between working on different modules.
To resolve some of the above drawbacks, we should actively build coherence of AIDE as a centralized subteam, rather than a bunch of sub-sub-teams. When I first joined AIDE, I didn't quite understand why I was doing what I was doing, and as a result, our work was confused and we sometimes had to backtrack. The first priority for AIDE in a given semester is that each team member understands:
When new members join, they should be required to complete both the AguaClara Tutorial and the AIDE Tutorial. There's a lot of knowledge in the AguaClara Tutorial that would be useful for AIDE members, especially with using Git and Github. I'm working on improving both tutorials to ease new members into the AIDE workflow.
It's also important that the subteam's leadership is actively interacting with team members so that they know someone to turn to when they run into problems. For this, we could hold monthly team meetings - similar to the current leadership meetings, but with more involvement (as AIDE is so large, I don't expect everyone to be able to attend, but at least one person from each team should).
To facilitate teams switching between different modules/problems, we should have "pivots": meetings in which one team teaches another team about what they've accomplished with their module, and provides tips on how to continue. These pivots will continually build on the team members' understanding of AIDE.
There are about 15 weeks from when new AguaClara team members join to the final presentations - we'll have to plan wisely. A possible schedule:
Instead of leaving the entire source distributions (sdists) of the packages for our dependencies, we should instead be trying to run a local pip install on the user's computer. See this forum post for more information on our progress.
The feature script pipe database and the part studio pipe library should get their data from a single source. I really like the idea of having a pipe data base in a CSV file. That database could presumably be used to by the pipe library for drawing pipes and could be accessed by featurescript for getting dimensions needed for design. This would be more elegant than using superderive to access the pipe library to extract a pipe dimension.
Here is a nice data source https://www.gfps.com/country_US/en_US/lightbox/pvc-cpvc-tech/metric/metric-dimensions.html. The research IT team is currently working to create a pipe class in python. We could use a common data source for both python and FS.
There are two approaches to obtaining all of the pipe dimensions. One approach is to use equations to define the ID (based on SDR) and the other approach is to include the ID in the database. One reason to include the ID in the database is that the actual IDs are less than that calculated using SDR because the SDR specifies a minimum wall thickness. If we move to a CSV for the data source then the ID for SDR pipes should be in the csv file rather than calculated.
Ensure the following tests are complete:
guitar
lever arm/float
the Onshape Drawing team needs an easy way to see the output of the HDF and to be able to check to see if the values are being calculated correctly.
pipes underneath
pipes connecting constant head box
Create all functions needed for HDF
Verify that siphon design fixes premature leaking observed at Gracias.
Set expert inputs to produce design that is very similar to Gracias design
The OStaRS filter colab sheet is ready for conversion to FeatureScript
One of the goals for AIDE is to add functionality for generating completed documentation on building and maintaining the plant. As per @monroews's request, we will be reviving the work of AIDE Document (and this repo) and tying it directly to the functionality of AIDE.
Documentation templates (from which completed documentation will be generated) will take on the form of RST files, due to RST's ability to render LaTeX equations. Hopefully, we will be able to add images from Onshape 3D models and insert them directly into these doc templates. Click here to download an example documentation template in Spanish.
Looking to the future, my vision is that the aguaclara
package will remain as it is currently - a library of functions for water treatment research and design code. AIDE (which will reside in this repo) will become a GUI-based application (run either locally or in an online web application), and will be a nexus between the aguaclara
design code, a documentation engine, and Onshape.
@oliver-leung Since we've made the aguaclara repo that holds all the design files, is it necessary to have this repo?
Need to finish the Python code for the entrance tank
Filter will be enclosed in a pipe. Most of the hydraulic algorithms are identical to 12-60 L/s
The input box is unresponsive when I click on it. I can't reply to anything either
Make sure this form collects at least the following:
Required
In the latest version of aide_render, I made a render_lfom() function that takes in an lfom yaml (right now supporting only the flow rate variable, Q) and returns the design YAML. Please incorporate this into the aide main loop. If you need to save the output as a yaml file, make sure to specify the yaml_path_out keyword argument.
To clarify, this is the function you'll be calling with the flow rate input. From there, this function will run and produce a design output. That design output will then be read by aide_draw. Please pip install aide_render and try to run the render_lfom() function. It should be well documented.
The build function brings in
Apply PST architecture all the way down
A declarative, efficient, and flexible JavaScript library for building user interfaces.
๐ Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. ๐๐๐
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google โค๏ธ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.