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.
User avatar
sgrogan
Posts: 5588
Joined: Wed Oct 22, 2014 5:02 pm

Re: Solver/CGS architecture changes: Request for comment

Postby sgrogan » Wed Nov 19, 2014 9:30 pm

FreeCADGCS :D
User avatar
DeepSOIC
Posts: 7301
Joined: Fri Aug 29, 2014 12:45 am
Location: Saint-Petersburg, Russia

Re: Solver/CGS architecture changes: Request for comment

Postby DeepSOIC » Wed Nov 19, 2014 9:53 pm

planeGCS, flatGCS (describes the actual functionality very well)
abdullah
Posts: 3174
Joined: Sun May 04, 2014 3:16 pm

Re: Solver/CGS architecture changes: Request for comment

Postby abdullah » Thu Nov 20, 2014 5:55 am

logari81 wrote:Hi, it seems that you have a quite established idea of what you are aiming at. So your questions appear to be rather rhetorical. In any case if you want my honest opinion:
I very much appreciate you taking some of your scarce free time to comment in here. Thank you very much for this. I never ask rethorical questions, so I really appreciate your honesty in the replies.

Unfortunately, I do not have an established idea of what I want. I try to solve problems. I implement code, ask for different opinions, ask for guidance and at the end there is a result that is as good as my (average) abilities and the quality of the feedback and guidance.

I do not intend to overload you back with more questions that I have the time to pose and you, unfortunately, do not currently have the time to reply.

I will shortly comment on 1-3, just to show my view after your input, so that others in the community can correct me where wrong.

1- It seems that more input is positive on that the solver objects provide a normal. So it seems the way to move forward.

2- If we decide that each geometry defines a normal direction, then I would go for a polymorphic implementation, for sure. The main reason would be: Uniform treatment of pointers (execution time type determination through base class virtual functions). I might agree that a "simple" problem like this does not require it, but this does not mean that having it would not provide advantages. I know no disadvantage of it.

3- Ok, 1 and 2 were for DeepSOIC, 3 is for me. Interpreting your words I believe that you would define a circle, for example the one of the major axis, and then a transformation constraint that might be something like the Eccentricity. Honestly, my brain is too small as to envision if such a approach would work uniformely for all the constraints and could be put into practice with only that additional constraint. But a second question would be: would such approach be flexible enough to cover all other cases, hyperbola, parabola, beziers? If it would, then my decision may be suboptimal, but is the best I could arrive with my abilities and the guidance of the community.
logari81 wrote: Since it seems that you have time and motivation for pushing this forward I suggest that you fork freegcs choosing a new name and implementing your changes. Please don't merge your changes before you do the renaming because it may cause confusion if I release the current version of freegcs as an independent library.
I think you know how it works. Sometimes you have time and sometimes you have not. There are more names in the code and github than the 3 founders that are no longer very active. We had time available, some other (or maybe us again) will have it in some months and the project keeps growing. You did a remarkable contribution to FC and I am very thankful for it. Thanks to you I have an sketcher to work with. I would like to think that others would be thankful when they need an ellipse and it is there because I contributed so that they can have it.

That is a more than reasonable request. I think we can change the name (Werner already proposed, so I guess that is a yes from his side).
logari81 wrote:I wish you good luck with the rest.

P.S. if I was you, I would prefer to invest my free time in fixing the poor dof counting performance, which is easy to fix and affects users very much.
Thanks!! I hope we take right enough decisions :)

I have taken a look to the "dof counting". There are some ideas in Assembly for selection of the initial solution, so that the matrix is better conditioned and the DOF calculation via rank more accurate. I plan to work there...
abdullah
Posts: 3174
Joined: Sun May 04, 2014 3:16 pm

Re: Solver/CGS architecture changes: Request for comment

Postby abdullah » Thu Nov 20, 2014 6:18 am

ABOUT THE NEW LIBRARY NAME
=========================

OpenCGS is taken:
https://github.com/roubo/openGCS/blob/master/README.md

LibreGCS seems to be available.

FreeCADCGS is also available.

DeepGCS c'mmon do not be so egocentric it is not only yours, I have a share, and logari81 still has like the 90% of the shares !!! :lol:

I would go either with LibreCGS or FreeCADCGS. Because it is not a separated library anyway, I would go with FreeCADCGS. This would also want to indicate that is an own library (of FreeCAD) and that the decision making lies within FC community. Of course someone can fork it for external use, but then (s)he is the one to provide the new name :-)

WAY FORWARD OF FreeCADCGS (or whatever name we choose)
==================================================

I propose:
1. We need a moment in time to do the conversion of naming to FreeCADCGS (or whatever). Logari is not comfortable with my InternalAlignment, so I think it makes sense that I start by doing the renaming, so that FreeCGS is at no time "infected" with my code. This is something I can do (Werner please drop a line if you agree that I do it). Because DeepSOICs work is based on the ellipse implementation, he should benefit from my change.
2. I would propose to have a thread open in the developer's corner regarding changes in Solver/CGS architecture (can be this one), so that we can discuss any change as a community in there. I think it is very important because some of us work in the solver, others in the creation of new elements, dof counting, multithreading, and some work may collide with other.
3. Coding decisions:
I will propose that after the Ellipse is pushed into master, we start pushing individual commits for individual changes (polymorphic architecture, then introduction of the normal method, implementing the bits needed in Vector2D so that we do not have a copy in the solver, ...)

What do you think?
User avatar
sgrogan
Posts: 5588
Joined: Wed Oct 22, 2014 5:02 pm

Re: Solver/CGS architecture changes: Request for comment

Postby sgrogan » Thu Nov 20, 2014 1:09 pm

abdullah wrote:There are more names in the code and github than the 3 founders that are no longer very active.
I don't think that came across as you intended
User avatar
DevJohan
Posts: 41
Joined: Sun Jul 13, 2014 2:36 pm
Location: Stockholm, Sweden

Re: Solver/CGS architecture changes: Request for comment

Postby DevJohan » Thu Nov 20, 2014 2:30 pm

Hi Everyone,

It's been some time since I had the time to "play" with the code. I have done some work seperate from the current freecgs which i called freecgs_EXP or something along those lines. My initial idea was to speed up the solver, make it run in a seperate thread and also in the long run implement expressions for the solver to allow named variables.

I've added the freecgs_EXP as a seperate folder along freecgs and make a widget which displays the runtime of the solver. My intention was/is to keep the functionality of freecgs as a reference when testing the new code. The freecgs_EXP is largly refactored and the calculations of gradients is calculated for all dependent variables at a time instead of calculating the derivative of one dependent variable at a time. This does not speed up the solver though since solving the newton steps is the real beast timewise.

When it comes to polymorphism I believe it to be necessary. Today freecgs uses pointers heavily, everything is pointers, and in this case pointers is kind of the hard way of implementing polymorphism.

Looking forward to the discussions.

Cheers,
Johan
logari81
Posts: 654
Joined: Mon Jun 14, 2010 6:00 pm

Re: Solver/CGS architecture changes: Request for comment

Postby logari81 » Thu Nov 20, 2014 4:00 pm

Hi DevJohan,

I have actually reviewed your refactoring and I like most of your changes. I hadn't realized that you vecorized the calculation of gradients, but it is great that you did. It is something that I also had in mind and I think your improvement will indeed have some performance impact.

I would merge most of your changes to freegcs, so it is a good idea to use your version also as a basis for the new solver version in FreeCAD (whatever it will be called), so that we will have a smaller diff between the two versions.

In general when you refactor a code, I would recommend you, to apply whitespace changes in a seperate commit than actual changes, so that it is easier to review.

I am wondering what is the reason for replacing pointers with "index<>" and dereferrencing with "value<>". That is one of the parts that I am skeptical about merging, because I can not see the advantage. Could you elaborate a bit on that change?
abdullah
Posts: 3174
Joined: Sun May 04, 2014 3:16 pm

Re: Solver/CGS architecture changes: Request for comment

Postby abdullah » Thu Nov 20, 2014 4:12 pm

sgrogan wrote:
abdullah wrote:There are more names in the code and github than the 3 founders that are no longer very active.
I don't think that came across as you intended
Ok, the founders are active, the other names are no longer very active. Fair enough!!
abdullah
Posts: 3174
Joined: Sun May 04, 2014 3:16 pm

Re: Solver/CGS architecture changes: Request for comment

Postby abdullah » Thu Nov 20, 2014 4:31 pm

At the end, it was good to drag Johan to the thread.

So, Johan. Do you think that merging your changes is viable at this moment? Do you have time for this at the moment?

I am trying to determine if it is viable to follow the suggestion of logari, so that he can have a small difference with respect his code, and we can start the new architecture on top of your changes and you can still have logari's code as a reference. It starts to become cyclic dependency.

I do not reach your level of understanding of the code. How would you propose to organize it?

DevJohan, if I understand you correctly, you have:
freegcs => logari+your modifications
freegcs_EXP => a widget to show solver runtime working with freegcs

where should FCGCS go? What is your proposal?

Have you taken a look at DeepSOICs proposal? Does it collide with your code?
User avatar
DeepSOIC
Posts: 7301
Joined: Fri Aug 29, 2014 12:45 am
Location: Saint-Petersburg, Russia

Re: Solver/CGS architecture changes: Request for comment

Postby DeepSOIC » Thu Nov 20, 2014 5:56 pm

abdullah wrote:Have you taken a look at DeepSOICs proposal? Does it collide with your code?
I'm sure it does. I have no problem redoing my changes to the new architecture, given some time to get into it. My changes are not that big, I even think that they are too small to be called "architecture changes". The only question is - when we get to that point - will I have time or even desire to do so?... I can't be sure.

EDIT: now that I've bought a new huge touchscreen monitor for my development PC :mrgreen: , I'll probably shift interest into bringing touchscreen support into FreeCAD.