Recompute on file open

[IPowIPi]

This entire topic is based on a very questionable premise.

It is hard to imagine someone spending 100 hours on a model only to discover that it was "broken" at the beginning. (Whatever "broken" might mean.)

I recompute regularly, and I absolutely do not want an automatic recompute and "error check" on launch. And I often open the same model repeatedly with exactly the same version of FC. What would be the point of checking for OCC changes in that case?

My assumption was that a full recompute usually only happens if somebody changes a very early parameter - e.g. some dimensions inside the very first sketch. So it could take quite some time until one actually makes use of the parametric nature of the model - and only then one sees, that the recomputed model deviates from the stored one (e.g. in the case of an underconstrained model where either the heuristic to resolve this case has changed or this heuristic is even non-deterministic in the case of ambiguous steps).

Occasionally triggering a manual full recompute sounds like a good practise that makes this automatism unnecessary indeed! Not sure though whether everybody is even aware how to force a recompute without "wiggling" on some early parameter. E.g. Std Refresh seems to be disabled if FreeCAD considers a recompute unnecessary. Perhaps it would help to allow an easy way to Refresh in any state?

[GeneFC]

Perhaps it would help to allow an easy way to Refresh in any state?

OK, now I understand why you felt an auto-recompute was necessary. You may not know how to generate one manually. Right click on the top model tree item and select "Mark to recompute."

Request recompute.jpg (23.34 KiB) Viewed 1206 times

Then hit the recompute icon in the top menu bar (or F5).

Dirt simple.

Gene

[adrianinsaval]

what is underconstrained in your mind? unconstrained DOF are not the cause of breakage, if a model doesn't do what you expect because it's not properly constrained that's just bad modelling and not the software's fault (and I don't think recomputing affects that).

What can break on recompute are references to geometry (fillets, sketches mapped to faces, imported geometry in sketches, etc) because their names change, the topological naming algorithm is meant to minimize such things by storing additional data about the geometry to remap the references. Recomputing should be pretty safe when that additional data is available.

[IPowIPi]

what is underconstrained in your mind? unconstrained DOF are not the cause of breakage, if a model doesn't do what you expect because it's not properly constrained that's just bad modelling and not the software's fault (and I don't think recomputing affects that).

I wouldn't say that it is the software's fault, yes, it's more the way how it works. As long as one isn't changing parameters or applying new constraints, in my understanding FreeCAD works more like a vector graphics program that puts things exactly where the user put it, without solver involvement.
If recomputes are completely optional one can easily hack along on the model for days or weeks without any verification that the solver would be able to reconstruct the geometry based on the specification when needed. E.g. OpenSCAD or CadQuery are the exact opposite. There the model is usually reconstructed from scratch when one saves the model spec, so an underconstrained new element (or one whre the solver at least acts differently than expected) becomes immediately obvious as soon as the model is visualized the next time.
In FreeCAD this verification is currently left to the discipline of the user. Which can be convenient as it lets you get away with more lax specs - but this can backfire as soon as one actually wants to make use of the parametric nature of the model and it becomes clear what the solver makes out of it.

What can break on recompute are references to geometry (fillets, sketches mapped to faces, imported geometry in sketches, etc) because their names change, the topological naming algorithm is meant to minimize such things by storing additional data about the geometry to remap the references. Recomputing should be pretty safe when that additional data is available.

It would be good if Yori or Realthunder could chime in which additional scenarios they had in mind when talking about "doing a full recompute at file open would be disastrous" and "a full recompute is kind of fragile when the file is authored using a different OCC version". I can only bring up the cases I have on the radar, perhaps there are more severe cases what can go wrong after recompute. Think they don't talk about the TNP, because the assumption in the thread I got this out from is that RT's fix is already applied that fixes the native topology connection as soon as it sees that a discepancy was introduced during modelling. (Of course, if the TNP was already introduced in a pre 0.20 version then the algorithm has no chance to automatically fix this). But it is moot to speculate, they know best what they actually meant

If an automatism is not desired, for me personally the manual approach as proposed by GeneFC is ok. Perhaps it might be good to consider to change the functionality of Std Refresh that, when no specific subcomponent is selected for recomputation, that it recomputes the entire model by default instead of being disabled. Then one can make it a habit of pressing F5 after any relevant changes, to see what the solver makes out of the recent additions - like one frequently presses Ctrl+S.

[onekk]

[I wouldn't say that it is the software's fault, yes, it's more the way how it works. As long as one isn't changing parameters or applying new constraints, in my understanding FreeCAD works more like a vector graphics program that puts things exactly where the user put it,

FreeCAD is not Vector graphics, it all about 3d modelling, the model is based on some paradigm:

- you define curve (TopoShapes) supplyng some paramters, like the center, the orientation and the radius of a circle, or two point on a Line (Line is infinite)
- you supply some limits to these curves to form Edges
- assembly edges to form wires
- wires could be "filled" to make a face, using different strategies
- faces could be assembled to form a shell
- the shell could be made a solid

This is BREP that is the "modern" paradigm CSG is the old paradigm with boolean operations, (OpenSCAD is CSG only from what I remember".

But this is not true, as once you have a solid created with BREP it could be used to perform boolean operations, on them, it is not "all or nothing" is the use of different techniques together.

Positioning is another matter, what FreeCAD seems to be lacking, is the "local" and "global" positioning, at a first glance it is not implemented, but this matter is not about the modeler, is more a thing related to do "compounds" or assemblies, you could define a "local" or "relative" position not in term of absolute XYZ coordinates, but in term of "local" coordinates, maybe mapping a solid at the center of a face of another solid.

This task could be achieved in different ways, as an "official" Assembly module is not fully implemented. (there are many competitor, one of them is the Realthunder assembly "FreeCAD version").

See:

https://forum.freecadweb.org/viewtopic.php?f=20&t=40058

There the model is usually reconstructed from scratch when one saves the model spec, so an underconstrained new element (or one whre the solver at least acts differently than expected) becomes immediately obvious as soon as the model is visualized the next time.
....

In FreeCAD this verification is currently left to the discipline of the user. Which can be convenient as it lets you get away with more lax specs - but this can backfire as soon as one actually wants to make use of the parametric nature of the model and it becomes clear what the solver makes out of it.

OCCT is the 3d engine, many operations, are not in the OCCT tasks, and are left to the implementation of the modeler, OCCT has some modules that are "paid versions" that solve these "problems", so the TopoNaming issue is not on their priority list.

As there is no a "solver" for 3d models, constraints are not present, at least in a "formal" manner as in the sketcher wb for 2D work.

The fact that RealThunder has solved the Topo Naming Issue is related to the use that is done by the Assembly module, that has the name is telling is done to assembly different shapes together, the way this task is done has no found (as told earlier) an unique way in FreeCAD and this is one of the problem you are facing.

The fact that FreeCAD has no a "proper government structure" and the development is left to many volunteers don't help much in a "clear developing path" but as said in many other post, for the price you pay, what you are using is worth "more than you pay for FreeCAD".

Making some consideration about other Commercial software is not "fair" as you for a commercial software you will pay and in the future you will "pay per use" as this is the way things are going in the software industry.

OpenSCAD is very far from perfection, as there are many problems also in it, the most important problem is that is no a 3d modeler as it produce meshed objects (at least from my knowledge, having used it some years ago).



A little remarks Yorik is more geared toward Arch WB, and RealThunder has his own fork of FreeCAD and is doing many efforts to "port" gradually some of this code in the "main branch", all of them do things, "pro bono" so as said regarding FreeCAD, "you will get more than you pay for".

Regards

Carlo D.

[chrisb]

For the sake of more clarity we should completely avoid the notion of "solver" for what recompute does, and use "solver" for what is done in sketcher. (Not talking about assembly here).

[IPowIPi]

Thanks for the sum-up onekk. Didn't want to compare it to commercial software, speak down on FreeCAD nor sound unthankful - great collaborative effort!
chrisb, good point, will call it sequential construction history then perhaps, sorry for confusion! What I was subsuming with "recompute" was finding a 2d shape that fits the constraints for the sketches, building up the geometry step by step from the parametric model (e.g. explicit length of a linear extrude) and computing the orientation and location of parts based on constraints. Now I understand that compute uses the solver only for the first and third but not the second job in FreeCAD (so e.g. length of an extrude isn't a constraint and there are no driving and driven parameters in 3D, so everything is explicit as "drawn by the user").

[adrianinsaval]

It would be good if Yori or Realthunder could chime in which additional scenarios they had in mind when talking about "doing a full recompute at file open would be disastrous" and "a full recompute is kind of fragile when the file is authored using a different OCC version". I can only bring up the cases I have on the radar, perhaps there are more severe cases what can go wrong after recompute. Think they don't talk about the TNP, because the assumption in the thread I got this out from is that RT's fix is already applied that fixes the native topology connection as soon as it sees that a discepancy was introduced during modelling. (Of course, if the TNP was already introduced in a pre 0.20 version then the algorithm has no chance to automatically fix this). But it is moot to speculate, they know best what they actually meant

I'm pretty sure they were talking about the proposal just before their comments: to not store mapped names but generate them on file open via a full recompute, this would make the topo naming algorithm work only within one session, in that specific case the first recompute of the session would be as fragile as it is now without the algorithm but subsequent recomputes within the session won't, that's why the mapped names must be stored so they would be robust across sessions.

If an automatism is not desired, for me personally the manual approach as proposed by GeneFC is ok. Perhaps it might be good to consider to change the functionality of Std Refresh that, when no specific subcomponent is selected for recomputation, that it recomputes the entire model by default instead of being disabled. Then one can make it a habit of pressing F5 after any relevant changes, to see what the solver makes out of the recent additions - like one frequently presses Ctrl+S.

I think you are overestimating how fragile this is, doing a full recompute after every addition is overkill, even in current FreeCAD this is unnecessary. As I said before, underconstrained sketches or even assemblies are not the cause of breakage, if you change a parameter and something that shouldn't move moves it's trivial to add the proper constraint, it is referenced geometries that can break and the topological naming algorithm greatly reduces this occurrences, I doubt you can find a case were simply recomputing would break any model at all with the topological naming algorithm implemented (and the mapped names already stored), you would need to manually change some relevant parameter if you want to test the robustness of your model, in which case a global recompute button is not of use.

[IPowIPi]

I'm pretty sure they were talking about the proposal just before their comments: to not store mapped names but generate them on file open via a full recompute, this would make the topo naming algorithm work only within one session, in that specific case the first recompute of the session would be as fragile as it is now without the algorithm but subsequent recomputes within the session won't, that's why the mapped names must be stored so they would be robust across sessions.

That's the part I don't understand. Assume a change happens within a session that breaks the naming assignment (e.g. some intermediate face gets added or deleted). Then the topo algorithm should detect and fix the original references. Afterwards we have a correct name topology again. If you save that, why does it matter whether the map with the (additional) generated names is stored in the file or recreated at next reload (other than performance)? Shouldn't it be impossible to save a file with defect topology if the fix is in place? (And assuming it would - why should the algorithm be able to detect the problem in the next session when it wasn't able to do so in the previous one?)
From that logic one could easily drop the generated names at save time and recreate them at reload. This proposal led to the quotes this thread started with - and me wondering what makes recompute so unstable - and if it is, why it isn't triggered more often to check whether everything is still alright

[adrianinsaval]

That's the part I don't understand. Assume a change happens within a session that breaks the naming assignment (e.g. some intermediate face gets added or deleted). Then the topo algorithm should detect and fix the original references. Afterwards we have a correct name topology again. If you save that, why does it matter whether the map with the (additional) generated names is stored in the file or recreated at next reload (other than performance)?

there's a few things at play here:
-generating the mapped names for a model that doesn't have them requires a full recomputation
-the mapped names are necessary to auto-fix references so we want to have them generated
-recomputing is computationally expensive so it's undesirable to require recomputing at file open
-recomputing with different OCC or FreeCAD versions a model that doesn't have the mapped names can be fragile because there is no guarantee that the faces/edges/points will have the same index number despite having the same shape and without the mapped names these name changes won't be autofixed.

Thus, if the mapped names were not saved and we recomputed the model every time we open it we risk unnecessarily breaking the model at file load at worst and we waste CPU and human time in vain at best.
Besides, there's very little (and I dare say nothing) to gain by not storing the mapped names in the file.

Shouldn't it be impossible to save a file with defect topology if the fix is in place?

No topological naming algorithm is perfect, not even proprietary ones. There will always be cases were manual intervention is required, that's why it's considered bad practice for serious CAD to use references to geometry when other options are available. Anyway, the issue is not about a file that is saved broken but about one that breaks later on.

This proposal led to the quotes this thread started with - and me wondering what makes recompute so unstable - and if it is, why it isn't triggered more often to check whether everything is still alright

As mentioned before, arbitrarily recomputing will not give insight on the robustness of the model most of the time. As to why it's unstable, that's just one of the quirks of OCC (the geometric kernel), you'll have to ask someone with deeper knowledge than me to know why that is the case, however I think it's stable within the same version of the software and I doubt it will be unstable with the topo naming algorithm implemented if the mapped names are already generated.