Solver/CGS architecture changes: Request for comment

Here's the place for discussion related to coding in FreeCAD, C++ or Python. Design, interfaces and structures.
Forum rules
Be nice to others! Respect the FreeCAD code of conduct!
User avatar
DeepSOIC
Veteran
Posts: 7896
Joined: Fri Aug 29, 2014 12:45 am
Location: used to be Saint-Petersburg, Russia

Re: Solver/CGS architecture changes: Request for comment

Post by DeepSOIC »

DeepSOIC wrote:Looks like redirectParams is never actually called from anywhere, and may be deleted together with all this bool and the relevant mess in Geo.cpp. Doh!.
Unfortunately, I'm wrong here. Ditching it is a bless, but impossible. Qt creator failed to find its usages, but the compiler... is quite a bit more comprehensive. Oops!
User avatar
bejant
Veteran
Posts: 6075
Joined: Thu Jul 11, 2013 3:06 pm

Re: Solver/CGS architecture changes: Request for comment

Post by bejant »

DeepSOIC wrote:it becomes even worse than on the notebook when I use a debug build. It is slow as a dead cow.
Yes. From this post:
viewtopic.php?f=3&t=4651&start=10#p36513
Of course, my experience is that debug is a factor 10 slower
If you don't want to read through that whole thread here's the condensed version:
viewtopic.php?f=3&t=4651&start=110#p46481
viewtopic.php?f=3&t=4651&start=110#p46491
User avatar
DeepSOIC
Veteran
Posts: 7896
Joined: Fri Aug 29, 2014 12:45 am
Location: used to be Saint-Petersburg, Russia

Re: Solver/CGS architecture changes: Request for comment

Post by DeepSOIC »

git commit 9e3fa8c8de0f49c0ef3c978e015eb905358dbdd9
AngleViaPoint: using it instead of via line tangency

* replaced the helper construction line for ellipse-to-ellipse and
similar tangency with a point. Using tangent-via-point there
* deleted tangency via line for point-to-point on
(oops! forgot to complete the commit message after having been interrupted by a finished build)
... on ellipse-arc combinations.
I'm very unproductive today :cry: Anyway...

I have 4 ways to do the fixing of tangency type. I struggle to make a decision.
1. Append the mess in ConstraintPyImp.cpp with more variants of float/int last parameter. What used to be a mess is slowly becoming an epic mess. Precalculate the type of tangency in gui routines and pass the last parameter indicating the type of tangency to be created. (I've almost done that, but than undone the changes).
(-) repetition of internal/external detection code
(-) messy, unclear
(+) type of tangency is controllable from python scripting
2. Same as 1, but use constraint name to indicate the type of tangency. Like "....addConstraint('Tangent:External', blah, blah, blah)"
(-) repetition of internal/external detection code
(+-) clear(but blows up the code even more than 1)
(+) type of tangency is controllable from python scripting
3. Don't touch the mess in ConstraintPyImp.cpp. Supply the type of tangency later by a call to "%s.setDatum(blah,blah)".
(-) repetition of internal/external detection code
(-) extra dummy call to solve()
(+) no extra mess in PyImp.
(-) type of tangency is almost uncontrollable from python scripting (setDatum will work, but flipping the tangency once it's solved causes solver lockup)
4. Decide on the type of tangency in SketchObject::addConstraint.
(+) less repetition of internal/external detection code
(+) may lock down existing sketches automatically (I'm not sure it will)
(-) no other constraint does that yet. Can it work??
(-) type of tangency is almost uncontrollable from python scripting (setDatum will work, but flipping the tangency once it's solved usually causes solver lockup)
(+) may remove the need to handle undefined case (datum==0) in sketch.cpp. Investigation is needed.

4 can be combined with 1 or 2.

OK, as soon as I wrote that down here, I see. Option 4 is the best if it is possible, so I should try that one.. Tomorrow.

And another hard decision. Should the constraint datum hold +1/-1/0 or +pi/2 / -pi/2 / 0 for tangency external/internal/undefined? holding the angle would allow gradual flipping of tangency to avoid solver lockup, but it will look funny if another angle is put in. Holding the angle is simpler codewise.

I welcome opinions, but I probably will decide myself anyway.
User avatar
DevJohan
Posts: 41
Joined: Sun Jul 13, 2014 2:36 pm
Location: Stockholm, Sweden

Re: Solver/CGS architecture changes: Request for comment

Post by DevJohan »

Just a quick one regarding the name:

+5: SketchGCS ( because it's the sketch we solve )
+4: Plane/Flat GCS ( Because it is an in plane problem )
+3: GCS2D ( same as above, but 2D )
+2: FreecadSketcherCGS ( I think we should think of this as a part of FreeCAD and not a external library thus making FreeCAD superfluous, and it's in the Sketcher workbench but it is the Sketch we solve.)
+1 FreeCADGCS ( So we added CAD, isn't it part of FreeCAD )

I don't really want to consider this a vote but an argument. Name is not that important but it's always nice to know what to call things. My main point is I think we should consider this to be written specifically for FreeCAD and in this context drop the reference to the program itself. If someone wants to refer to this functionality in FreeCAD they should refer to it as FreeCAD's *whatever we decide to call it*.

I only use the Draft module to do ugly hacks and don't know it very well. Is there any reason one would use 2D Constraints in Draft or is any decedent of freegcs a sketcher/partdesign specific functionality?

BTW, I think Abdullahs eclipse constraints are now ported to my modified framework. I've begun to pull in DeepSOICs work. Regarding the efficiency of the code, having the error-functions documented and ready would facilitate improving the code performance wise a whole lot.

Cheers,
Johan
jmaustpc
Veteran
Posts: 11207
Joined: Tue Jul 26, 2011 6:28 am
Location: Australia

Re: Solver/CGS architecture changes: Request for comment

Post by jmaustpc »

DevJohan wrote:My main point is I think we should consider this to be written specifically for FreeCAD and in this context drop the reference to the program itself. If someone wants to refer to this functionality in FreeCAD they should refer to it as FreeCAD's *whatever we decide to call it*.
Good point, I agree, now. :)

One point though it should be "sketcher' not "sketch", to keep the naming consistent with the workbench and it other current components, like some icons, that contain the prefix "sketcher" in their name.
DevJohan wrote:I only use the Draft module to do ugly hacks and don't know it very well. Is there any reason one would use 2D Constraints in Draft or is any decedent of freegcs a sketcher/partdesign specific functionality?
At one time there was a discussion about adding 3d capabilities to sketches/constraints, from memory Ickby was one of those involved in the discussion. I think the main use case at time was in creating a path for a Part Sweep.

Assembly uses constraints but as far as I know they have nothing to do with sketcher constraints.
User avatar
NormandC
Veteran
Posts: 18587
Joined: Sat Feb 06, 2010 9:52 pm
Location: Québec, Canada

Re: Solver/CGS architecture changes: Request for comment

Post by NormandC »

jmaustpc wrote:Assembly uses constraints but as far as I know they have nothing to do with sketcher constraints.
This is off topic, but I believe for the Assembly WB they should be called "relationships" so not to confuse them with sketcher constraints.
ickby
Veteran
Posts: 3116
Joined: Wed Oct 05, 2011 7:36 am

Re: Solver/CGS architecture changes: Request for comment

Post by ickby »

At one time there was a discussion about adding 3d capabilities to sketches/constraints, from memory Ickby was one of those involved in the discussion. I think the main use case at time was in creating a path for a Part Sweep.
I still have this idea, but based on the assembly solver as it works in 3d anyway. But this is quite some time in the future...
abdullah
Veteran
Posts: 4935
Joined: Sun May 04, 2014 3:16 pm
Contact:

Re: Solver/CGS architecture changes: Request for comment

Post by abdullah »

normandc wrote:
jmaustpc wrote:Assembly uses constraints but as far as I know they have nothing to do with sketcher constraints.
This is off topic, but I believe for the Assembly WB they should be called "relationships" so not to confuse them with sketcher constraints.
+1
abdullah
Veteran
Posts: 4935
Joined: Sun May 04, 2014 3:16 pm
Contact:

Re: Solver/CGS architecture changes: Request for comment

Post by abdullah »

DeepSOIC wrote:Another comment on slot commit: it is already in master. I just don't know how to get rid of it.
In this I can help. This is your previous work - slot + your latest commit:

https://github.com/abdullahtahiriyo/Fre ... master.git
* [new branch] DeepSOIC_on_Ellipse_allsquahed_minus_slot
abdullah
Veteran
Posts: 4935
Joined: Sun May 04, 2014 3:16 pm
Contact:

Re: Solver/CGS architecture changes: Request for comment

Post by abdullah »

DevJohan wrote:I don't really want to consider this a vote but an argument. Name is not that important but it's always nice to know what to call things. My main point is I think we should consider this to be written specifically for FreeCAD and in this context drop the reference to the program itself. If someone wants to refer to this functionality in FreeCAD they should refer to it as FreeCAD's *whatever we decide to call it*.
Ok. So we strip FC from the naming, and keep a differentiating name within the FreeCAD project. I like it. :)

SketchCGS or SketcherCGS meet this criteria. I am not a native speaker, and to me Sketch or Sketcher is irrelevant. The Sketcher creates Sketches and the Solver solves the constraints of an Sketch. Potato-Potato tomato-tomato.

Without that logic is the Plane/FlatGCS, that is also among the favourites.

I think we can limit to one of those 4. Anyone else playing the naming game? :lol:
DevJohan wrote:BTW, I think Abdullahs eclipse constraints are now ported to my modified framework. I've begun to pull in DeepSOICs work. Regarding the efficiency of the code, having the error-functions documented and ready would facilitate improving the code performance wise a whole lot.
Easy question. Gods of the Wiki of FreeCAD, May I ask Thee for a place is thy Wiki for Solver documentation? (sure I got one of the forms wrong :lol: )
DeepSOIC wrote:And another hard decision. Should the constraint datum hold +1/-1/0 or +pi/2 / -pi/2 / 0 for tangency external/internal/undefined? holding the angle would allow gradual flipping of tangency to avoid solver lockup, but it will look funny if another angle is put in. Holding the angle is simpler codewise.
What is the problem of having the parameter coded in the value field of Constraint (datum), The UI detects tangency by detecting Index3==GeoUndef, python should be able to do the same, at least in the original, the parameters are sent in an ordered logic. Solver should be able to detect tangency by the same principle... Of course I am basing this argumentation in the fact that you code it as an AngleViaPoint constraint, not as a Tangency one.

UI should be able to interpret that when an AngleViaPoint having index3=GeoUndef, a Tangency Icon has to be drawn. Does this collide with any other part of your code? Similarly, if you would like to show a specific datum edition dialog box, you could do it (select internal/external/undefined).

BTW, you asked a while ago and I failed to reply (I forgot). The problem with the angle in the UI that is always positive can be fixed for an Angle via Point in the UI editing dialog. This makes sense in your constraint because does not show a relational (any 45 degrees between geometries) but absolute (+45 is +45 from first element to second element and -45 is -45 from first element to second element an nothing else, am I wrong?).

Let me know if you want more input from me.
Post Reply