From: Dawn Thomas <thedawnthomas@gm...>  20090320 02:39:15

Hi Kanzure, I was wondering about the "explicit constraints" in particular. What does this mean, and can anyone give me an example of another CAD > software package that implements that, or how it would be used, or > something? Also, what about this "Math Virtual Machine", what does > this /mean/? So, presumably, users would type up some sort of > mathematical expression which would state/specify constraints? When > I've used parametric CAD systems before, I never had to do that or > I've never seen those options but it's entirely possible that it's > very important and something that I should know about. Now take two spheres and you might want to guarantee that they are always perfectly tangent to each other  that'd be an explicit constraint. Or consider just the one sphere and say that you want to require that the sphere always have a radius between 1 meter and 12 meters  another explicit constraint. Those constraints, whether implicit or explicit are a series of expressions that associate with and refer to geometric entities. The MVM he refers to there is a system for evaluation those expressions and constraints. This is pretty common in most CAD systems where you can fully/under/over constrain a given model. Some even give you a convenient little red light / green light to let you know when you're fully constrained. Implicit constraints as Sean explained are basically constraints implicit in the definition of each primitive. It might be simple like perpendicularity, parallelism, equality etc. to more complex cases (tgc for instance) Explicit constraints are effectively 1. constraints between primitives ( variables of primitives : radius of sphere == radius of a cone for instance) or 2. constraints between variables of the same primitive (consider a cone whose volume is fixed : height is dependent on its radius squared) These two cases can be unified into saying constraints between "Variables" which are not necessarily involved in the definition of the geometry. Regarding MathVM : Our idea of constraint expression is to support a large spectrum of mathematical expressions in defining the constraints. This is a very critical part of the actual utility of constraints since otherwise we would be limiting the type of constraints defineable. For this purpose we could take various approaches. Lazy functions seem to be a good bet. The idea is that the solver would call the MathVM to evaluate the constraint expressions while traversing the hypergraph modifying the state of the constraints. If you have used CATIA for instance using f(x) tool u can specify quite advanced expressions between primitive parameters. It has been many years since I've worked with the boost library. > However, recently I have been working in the Automated Design Lab here > at the University of Texas at Austin, on projects involving generative > grammars and graph grammars for mechanical engineering problems. For > instance, some of the recent work is in the automated design and > optimization of gear trains; another fellow works on linkage design, > and another on product disassembly sequencing. > Regarding BGL: My primary thoughts were the advantages of not having to recode various traversal alorithms and boost being a very good container library in a sense it is a very sensible approach to code reuse. Spirit and Phoenix libraries are very helpful in terms of parsing of the expressions i mentioned above. There's a few classes there for the representation of graphs. The way > that graph grammars work is by searchandreplace, more or less. Each > grammar rule has a lefthand side and a righthand side. The lefthand > side represents a subgraph that it should 'match', and the righthand > side is the replacement. So, there's a 'ruleset' for different > domains a ruleset consists of a list of different grammar rules. A > ruleset exists for linkages, for product disassembly, gears, > electronic filter circuits, etc., and maybe one will be implemented > for parametric constraints? The way that this works is that a 'seed > graph' (input) is given, and then it's recursion over the list of > possible rules that apply to it, and for each one that matches, that's > a branch that is taken, and the branches are explored either in a > breadthfirst manner or depthfirst manner, until there's no more > manipulations possible to the graph, at which point you have a list of > solutions to the original problem. Now, I'm not entirely sure about > explicit constraints and weird grammar notations for constraints, so > that's partly why I asked that question previously :) so that I might > be able to see whether or not GraphSynth code (as opposed to the boost > library) would be appropriate here. > > GraphSynthrelated references full bibliography (in BibTeX): > http://heybryan.org/books/Manufacturing/campbell/bibliography/campbell.bib > Regarding Graphsynth, regarding the query about the conditional constraints, your suggestion was to specify the same in the Grammar. Let me just restate the case here: Vertices : A, B, C, D ,E and F Constraints: 1. A perp B 2. C perp. D 3. E perp. F if A perp. B and C perp. D else E parallel F I am wonering whether by that you meant specifying a ruleset ( hope i am not messing up on Graphsynth terminology here) specifying if you find A perp. B and C perp. D make E perp. F. But there maybe other parts in the graph ( say X perp. Y and Z perp. W which need to be connected in a similar way to T perp. U) What I am trying to say is , don't you think the arc object definition as per the xml here( http://www.me.utexas.edu/~adl/graphsynth/graphs.htm ) is insufficient to take into consideration such cases. Could you share the xml and ruleset for the above case if it is possible ? My idea is that the designgraph should be completely able to reprsent the particular design with the ruleset there being to do the actual "Evaluation" and "Generation". Am I wrong in this regard? Also regarding an example of a logical constraint ( see again tgc implicit constraint 4), though i feel this might be reprsentable in Graphsynth. A pattern based search for constraints and associated graph reduction based solutions is very effective for various applications as graphsynth shows with its breadth. But do you think it has any clear advantages in terms of geometrical constraint modeling ? Also, are there any results on the scalability ? Compared to various discrete problems ( circuitry for instance or linkages ) performance is going to be a major issuing when searching a large solution space. I understand that you are comfortable with Graphsynth. But do you think it would have any significant advantages over 1. brlcad coding our own solver ( not transforming graphsynth code for instance) 2. utilization of some generic constraint solvers like minion. 3. utilization of geometric constraint solvers. > > presentations: http://heybryan.org/~bbishop/docs/repo/presentations/<http://heybryan.org/%7Ebbishop/docs/repo/presentations/>; > (older files are better, and I sincerely apologize for the pptx file > format some I've been able to convert to ODP, however) > > maybe this presentation would be most helpful: > > http://heybryan.org/~bbishop/docs/repo/presentations/Wed3KurtogluCampbellFrom%20BlackBox%20To%20Component%20Selection.odp<http://heybryan.org/%7Ebbishop/docs/repo/presentations/Wed3KurtogluCampbellFrom%20BlackBox%20To%20Component%20Selection.odp>; > > ** Relevant diagrams ** > > seed graph example > > http://heybryan.org/~bbishop/docs/repo/20081211/20081211_waterlifting.gxml<http://heybryan.org/%7Ebbishop/docs/repo/20081211/20081211_waterlifting.gxml>; > > screenshot of that example in GraphSynth > > http://heybryan.org/~bbishop/docs/repo/20081211/20081211_waterlifting.png.PNG<http://heybryan.org/%7Ebbishop/docs/repo/20081211/20081211_waterlifting.png.PNG>; > [Offtopic: Interesting :) Are these energy based constraints ? What are the coloured edges ] > One idea that I suggested to 'madant' over IRC yesterday was the idea > of representing constraint problems as a seed graph in GraphSynth by > having two types of nodes those nodes which represent an object in > BRLCAD's dot g database, and those nodes which represent the type of > constraint (parallel, perpendicular, etc.). So, any two nodes that are > connected by a node of label 'parallel_$unique_ID' would be required > to be parallel, and then some other labels would specify the xyz > coordinates (or something), which means the graph for two > perpendicular objects constrained to one two dimensions would be > "objectA <> perpendicular_1 <> objectB" (in reality, there's more > than two dimensions to deal with). The work that would need to be done > is a ruleset for manipulating those graphs by recognizing the > scenarios of perpendicularity and parallelism, and other types of > constraints, and consequently find all possible ways of solving those > constraints which I suspect will probably involve a subset of matrix > math rules or vector math rules. Refer to the example i mentioned above. > And again, the idea would be that > GraphSynth would go through the recognizechooseapply loop and > automatically generate all possible solutions to the original > constraints/seed graph, and then spit out those solutions to > {something} (which I need some clarification on, like I said maybe a > user would select from a command line which option to use to solve the > constraints problem when resizing, or something?) How about some user > case stories? That would be amazingly helpful. I suspect this code > would be implemented and integrated as the backend constraints > solution engine, but I'm also open to the idea of gluing it together > with shell or command line utilities depending on how exactly it's > supposed to work when seamlessly integrated (just to make sure I > understand completely). In terms of the user interface the scenario I am visualizing is ( eg. say a sphere is constrained in relation with a box : lets say there are three variables which are presently not constrained enough : Radius of the sphere, point of tangency ( considering the constraint is that the spehere and box touch each other tangentially). The user could be shown a slider for instance showing the spectrum of radii possible as well as (two sliders?) for the position of tangency. Now selection of any one of these might completely constrain the objects : Selection of a radius for instance might if the centre of the sphere is already constrained, Or selection of the xcoordinate for the point of tangency ( It may not in which case the y coordinate might be constrained and again request the user for the radius) ) http://heybryan.org/bioreactor/membraneless_filtration/20081125_gnuplot.png > > http://heybryan.org/bioreactor/membraneless_filtration/20081215_brlcad.png > > http://heybryan.org/bioreactor/membraneless_filtration/20081216_spiral_generator_2.png > > http://heybryan.org/bioreactor/membraneless_filtration/20081216_spiral_generator_2_other_issue.png > > http://heybryan.org/bioreactor/membraneless_filtration/20081216_spiral_generator_works.png > http://heybryan.org/bioreactor/membraneless_filtration/20090122.png > http://heybryan.org/bioreactor/membraneless_filtration/20090201.png > onehalf the physical object: > > http://heybryan.org/bioreactor/membraneless_filtration/20090318_spiral.jpg > neat ;) hope this helps, sincerely yours,  Dawn Thomas " the strength to change what i can, the inability to accept what i can't, and the incapacity to tell the difference" 