not only [Sketch] - FC becomes unresponsive while performing calculations
Forum rules
Be nice to others! Respect the FreeCAD code of conduct!
Be nice to others! Respect the FreeCAD code of conduct!
Re: not only [Sketch] - FC becomes unresponsive while performing calculations
Many thanks! Now showing/hiding is very fast.
However the main FC-wide issues remains:
- when FC has to calculate, FC becomes unresponsive. It should always stay responsive.
- only one CPU core is used to calculate in every case
There are also Sktecher-only performance issues remaining:
- take my test file from the initial post
- draw in a line whose first point is connected to a point of the existing sketch lines
result: this takes so long that FC becomes unresponsive
- now try to select the line by clicking onto it
result: this is hard, often I fail
- when you could select it, press DEL to delete it
result: this takes so long that FC becomes unresponsive. I wonder about this, because a deletion reduces the complexity of the sketch and here only a line is deleted, so not all constraints have to be re-evaluated.
Here are screencasts of these Sketcher-only issues:
However the main FC-wide issues remains:
- when FC has to calculate, FC becomes unresponsive. It should always stay responsive.
- only one CPU core is used to calculate in every case
There are also Sktecher-only performance issues remaining:
- take my test file from the initial post
- draw in a line whose first point is connected to a point of the existing sketch lines
result: this takes so long that FC becomes unresponsive
- now try to select the line by clicking onto it
result: this is hard, often I fail
- when you could select it, press DEL to delete it
result: this takes so long that FC becomes unresponsive. I wonder about this, because a deletion reduces the complexity of the sketch and here only a line is deleted, so not all constraints have to be re-evaluated.
Here are screencasts of these Sketcher-only issues:
Re: not only [Sketch] - FC becomes unresponsive while performing calculations
The constraints form a big - in your case I would say unnecessary huge - equation system. In general it is not possible without further analysis to remove a variable from such a system while keeping the rest.
A Sketcher Lecture with in-depth information is available in English, auf Deutsch, en français, en español.
Re: not only [Sketch] - FC becomes unresponsive while performing calculations
In my mind those are known limitations in general. I see this on a regular basis under different operation system and versions. FC seems to stop talking to the OS while it's calculation, therefore it seems unresponsive.
The one CPU core thing depends on what's supported so far if I recall correctly. Not sure if the Sketcher WB normally uses more than one core at the moment.
Regards / Viele Grüße
Max
Max
Re: not only [Sketch] - FC becomes unresponsive while performing calculations
Every operation needing QR decomposition is going to be slow.uwestoehr wrote: ↑Tue Sep 28, 2021 11:44 pm However the main FC-wide issues remains:
- when FC has to calculate, FC becomes unresponsive. It should always stay responsive.
- only one CPU core is used to calculate in every case
There are also Sktecher-only performance issues remaining:
- take my test file from the initial post
- draw in a line whose first point is connected to a point of the existing sketch lines
result: this takes so long that FC becomes unresponsive
- now try to select the line by clicking onto it
result: this is hard, often I fail
- when you could select it, press DEL to delete it
result: this takes so long that FC becomes unresponsive. I wonder about this, because a deletion reduces the complexity of the sketch and here only a line is deleted, so not all constraints have to be re-evaluated.
As noted, in my Debug system the QR decomposition was taking 50 seconds. The only possibility I see to improve this is by using a library that does multithreaded QR decomposition. In Eigen documentation there are GPL-only possibilties (no LGPL ones). For this reason, I have never looked into using them.
The alternative to that is using lower amount of constraints...
Re: not only [Sketch] - FC becomes unresponsive while performing calculations
How about http://buttari.perso.enseeiht.fr/qr_mumps/ ?abdullah wrote: ↑Wed Sep 29, 2021 11:14 am As noted, in my Debug system the QR decomposition was taking 50 seconds. The only possibility I see to improve this is by using a library that does multithreaded QR decomposition. In Eigen documentation there are GPL-only possibilties (no LGPL ones). For this reason, I have never looked into using them.
Disclaimer : I have a very limited understanding of this.
Re: not only [Sketch] - FC becomes unresponsive while performing calculations
The Sketcher does use two cores when doing QR decomposition, because it does two different QR decompositions in parallel. The first QR decomposition is formulated to obtain additional information about constraints (redundancy/conflicting). The second QR decomposition is formulated to obtain additional information on geometry (which elements are constrained an which are not). Both QR decompositions are equivalent from a computational point of view, and independent from each other (they are QR decompositions of a matrix and its transpose). The program continues as single threaded just after both results are obtained. This is the sole instance in which the sketcher uses multiple cores.
There is potential to add multi-threading to a second operation. After QR decomposition, the very big large system is "decoupled" in subsystems. These are solved (DogLeg) one after the other. It might be possible (to tell it for sure I would need to look deeper into it) to solve these in parallel. However, even when this is demonstrated possible, I am unsure how much improvement it may bring. These systems are for sure not equivalent in terms of computational requirements. In some cases they are extremely asymmetrical. Even if run in parallel, it is likely that any possible gain is negligible, as the cost of several processes is negligible and the overall time would be driven by the larger subsystem. In the extreme, it could even happen that the cost of firing and joining different threads is higher than the additional cost of having the light subsystems processed, leading to an increased of solving time by using multiple cores. Of course, in such a case, it should still be possible to decide whether to run parallel processes or do it iteratively depending on the size of the individual subsystems.
However, this actual solving of decoupled systems, in my experience, only takes long when there are convergence problems. This means that one of the subsystems, the one that would drive the overall time if run in parallel, would still determine the overall cost. In the other cases, it is fast, so probably no meaningful advantage could be obtained from making them parallel (even if time would be cut by 50%, which is quite an improvement, what is the difference between 0.3 secs and 0.15 secs?). So, all-in-all, it has remained a very low priority for me over the years, because I have the feeling that it would bring no meaningful advantage. So it is probably only worth as a theoretical exercise to test multi-threading skills.
In the present case, the solving time is clearly driven by the QR decomposition, so the gain, if any, would not be perceived, or even when it can be perceived, it would not still make the program "responsible".
Re: not only [Sketch] - FC becomes unresponsive while performing calculations
It does not sound bad... now it would be great to contact them and convince them to port it from Fortran to C++ with an Eigen interfaceopenBrain wrote: ↑Wed Sep 29, 2021 11:28 amHow about http://buttari.perso.enseeiht.fr/qr_mumps/ ?abdullah wrote: ↑Wed Sep 29, 2021 11:14 am As noted, in my Debug system the QR decomposition was taking 50 seconds. The only possibility I see to improve this is by using a library that does multithreaded QR decomposition. In Eigen documentation there are GPL-only possibilties (no LGPL ones). For this reason, I have never looked into using them.
Disclaimer : I have a very limited understanding of this.
The one I got from the Eigen documentation is this:
https://eigen.tuxfamily.org/dox/group__ ... odule.html
https://people.engr.tamu.edu/davis/suitesparse.html
https://github.com/DrTimothyAldenDavis/SuiteSparse
Re: not only [Sketch] - FC becomes unresponsive while performing calculations
How can I do so?
However, I notice that the performance is better when I prior hide ALL constraints and then, add the line and select it. The deletion however is not faster.
Concerning the deletion, can nothing be done? For example to keep the whole system of equations and only recalculate the affected constraints. For example when I delete a line that is not connected to any other sketch geometry, I think then no recomputation is necessary at all, right?
Re: not only [Sketch] - FC becomes unresponsive while performing calculations
By using a PD Pattern, if that meets your needs. Here, others will be able to advise you better.
For deletion, it may be possible to do group deletion. I think the code is already there in SketchObject. I can look into this.
It is not possible to my knowledge to reuse the result of a previous QR decomposition. Even if it were (which I still think it is not), it would need to take into account (track) all changes in geometry and constraints, which probably would make it not feasible.uwestoehr wrote: ↑Wed Sep 29, 2021 1:01 pm Concerning the deletion, can nothing be done? For example to keep the whole system of equations and only recalculate the affected constraints. For example when I delete a line that is not connected to any other sketch geometry, I think then no recomputation is necessary at all, right?
When you delete a line, you delete at least 4 parameters (provided that it contained no constraint at all). This changes the rank of the system. In such straightforward case, while for you it is evident the result (substract 4 DoF from the previous rank), it is not obvious for the software and it needs to calculate it. When it comes to a more serious delete, it is generally the case that you will have a very hard time to calculate the actual DoF, redundant constraints and so on. The software still does it (provided enough time is provided)...