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.
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...