Recompute on file open

Have some feature requests, feedback, cool stuff to share, or want to know where FreeCAD is going? This is the place.
Forum rules
Be nice to others! Read the FreeCAD code of conduct!
IPowIPi
Posts: 90
Joined: Sun Jul 25, 2021 9:37 am

Recompute on file open

Post by IPowIPi »

@realthunder @yorikvanhavre
Hi, some comments from the topological naming pull request got me thinking. In order not to derail the merge request here a separate thread. These comments were:

"Besides, a full recompute is kind of fragile when the file is authored using a different OCC version. "

and

"And yes, doing a full recompute at file open would be disastrous... All the way FreeCAD stores files is exactly made to avoid that."

If a model would implode when it would have to be recomputed, wouldn't that mean that e.g. changes on dimensions of one of the fundamental sketches aren't advisable anymore - but the user might spend another 100 hours adding additional layers on a basically broken fundament. And the person might have the expectation to be able to use the parametric aspect of the model later on, being able to change earlier dimensioning at any time, while this option realistically doesn't exist anymore.

So, wouldn't a "fail early" (if broken) policy be more helpful for the users?
E.g. if one would have the choice to
1) do a full recomputation on every load - as verification step that the model *can* still be recomputed.
2) open the model without recomputation but with history stripped (so it would be treated like a STEP file and could still be manipulated with direct editing features).

Then people wouldn't have the false sense of safety that they have a parametric model in cases where the parametric aspect is long broken. And if parametric is important but broken, then they could import it with recomputation on at an early stage, fix the result (e.g. add missing constraints), save and reload it again to see whether it's stable now - no late game surprises when the model is even more complex and the fixing potentially more difficult. Or they could willingly decide that history isn't important anymore, then there would be no false promise, they could still use direct editing techniques though.

In cases where people want to open their 0.19 and earlier models in FreeCAD 0.20 (when the topo fix makes it), a recompute would be necessary anyways as far as I understood. Then that behavior would at least be consistent.

Thoughts?
User avatar
onekk
Veteran
Posts: 6144
Joined: Sat Jan 17, 2015 7:48 am
Contact:

Re: Recompute on file open

Post by onekk »

If you have a broken model, "model is broken" so if the relevant informations (the ones that cause the brekage) where already stored in the model, there is no way to retrieve the "good informations".

I haven't gave an ey of the FCStd format but if it don't store an "history" storing also all the shapes information prior and after a modification, how FreeCAD would retrieve the "good informations".

Maybe having a way to set an autosave feature that will save some "old copy" of the FCStd file, would be a way to achieve a "recovery path", but also this strategy has some cost, if the model is big an automatica "save as" done by FreeCAD would involve some lags.

And if using such a strategy you have to set some "autosave rules", when an "autosave" will occur?

- at each modifications
- every X modifications
- every X minutes
...

FreeCAD in some way stores the brp files of the "shapes" see:

https://dev.opencascade.org/doc/occt-7. ... ep_wp.html

Some of these brp files are recalculated, some of the information are stored in the FCStd file that is "zipped directory" you will see easily if you change the extension in .zip and decompress it.
You will see something similar to this:
fcstd_dir.png
fcstd_dir.png (11.54 KiB) Viewed 1419 times
Document.xml is holding the modelling data.

Regards

Carlo D.
GitHub page: https://github.com/onekk/freecad-doc.
- In deep articles on FreeCAD.
- Learning how to model with scripting.
- Various other stuffs.

Blog: https://okkmkblog.wordpress.com/
IPowIPi
Posts: 90
Joined: Sun Jul 25, 2021 9:37 am

Re: Recompute on file open

Post by IPowIPi »

Yeah, I guess the people quoted above had very concrete ideas what might go wrong during a full recompute.
My guess would be that one way could be that the models might be underconstrained, so the solver has to pick an arbitrary solution at recompute - which might not be what the designer had in mind. In this case manually rearranging things as intended and adding constraints might solve this. But there could be more more to it.
As far as I understood the bare geometry information is always stored in the file, so going with that in the case a recompute fails (and construction history isn't considered important) might be an option.

The current approach of no recomputation at file load has the advantage that people who don't need to change a very early sketch might get away with a model that wouldn't survive a full recompute, can indeed change some parameters (as long as they aren't triggering a recompute of the critical parts) and might even never realize that something is wrong with the model at all. For them a forced full recompute might mean unnecessary extra work or restrictions (in the case that the full history gets dropped).

On the other hand, if one might need to change such an early parameter at some point then failing as early as possible could make repair easier (in the case of underconstrained models).

Perhaps instead of an all-or-nothing approach another option could be do the recomputation step by step and compare the result to the stored geometry? And if a divergence is found one could have the choice to convert everything before that step to history-less geometry and keep the history from that point on (assuming the remaining computation steps reproduce the stored geometry? That way people who only need to retain certain newer parametric features and can live with giving up on some earlier history for the advantage of not having to fix the model, would have that choice.
User avatar
adrianinsaval
Veteran
Posts: 5541
Joined: Thu Apr 05, 2018 5:15 pm

Re: Recompute on file open

Post by adrianinsaval »

needlessly recomputing all the time is a massive waste of time, specially considering occ doesn't parallelize stuff and a change in occ version doesn't happen often enough to warrant recomputing at file load and recomputing a file that was created with the same occ version just to test if it would break is even more useless. What you talk about is just basically the old and known topological naming problem, exactly what the PR is trying to address, have you read Topological_naming_problem?
IPowIPi
Posts: 90
Joined: Sun Jul 25, 2021 9:37 am

Re: Recompute on file open

Post by IPowIPi »

I think the quotes above were made under the assumption that a topo naming correction mechanism is already in place that fixes the native name hierarchy if it finds problems.

If a full calculation just takes long and preventing it is merely a performance optimization then this is a good thing.

If full calculation is avoided because it can break the model (e.g. because the heuristic which path to choose in the case of an underdefined model changes between OCC versions or even some nondeterminism in the selection process) then fail early could help to improve trust in reliability and help to fix problems early on.

Thats why it would make sense to better understand the reasons that led to these quotes and doubts? If it is mainly a performance concern - then fine!
chrisb
Veteran
Posts: 53919
Joined: Tue Mar 17, 2015 9:14 am

Re: Recompute on file open

Post by chrisb »

We had already discussed to include a file format version number in connection with incompatibilities of the new sketcher format. FreeCAD could then decide all by itself if a recompute is needed or not, e.g. by increasing the format version if a new OCC version is included. No recompute would be performed if the program is opened repeatedly with the same or a compatible version - which is the most common use case.
A Sketcher Lecture with in-depth information is available in English, auf Deutsch, en français, en español.
IPowIPi
Posts: 90
Joined: Sun Jul 25, 2021 9:37 am

Re: Recompute on file open

Post by IPowIPi »

Thanks @chrisb for the feedback. If recomputes within one version are always deterministic then that sounds like a good solution!
Then the expected recompute for 0.1x->0.20 wouldn't be a special case but could be triggered whenever incompatibilities are expected between versions - sounds good!

And the conversion to historyless geometry in case this forced recompute fails could also manually be handled by exporting the file from the last version that could correctly render it as STEP and importing that into the new version. Thus the proposed automatism and verification step (comparing the recompute with the stored geometry) and proposing to drop the history in case of a difference and just importing the stored geometry would more be a safety net (in case of non-obvious deviations) and convenience feature.
GeneFC
Veteran
Posts: 5373
Joined: Sat Mar 19, 2016 3:36 pm
Location: Punta Gorda, FL

Re: Recompute on file open

Post by GeneFC »

IPowIPi wrote: Wed Aug 04, 2021 9:13 am but the user might spend another 100 hours adding additional layers on a basically broken fundament.

Thoughts?
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?

Definitely a solution looking for a problem.

Gene
User avatar
onekk
Veteran
Posts: 6144
Joined: Sat Jan 17, 2015 7:48 am
Contact:

Re: Recompute on file open

Post by onekk »

I agree with @GeneFC that creating a solution for unexistent problem is always a bad thing.

As I'm mostly drawing with Scripting, the Document.recompute() instructions is occurring quite often, and I don't see many slowness in the execution.

The slowness is noticeable when you have to add many instances of "Document.Objects" that will populate the "tree view", , rather than creating many "TopoShapes" that have no representation in "tree view".

This slowness is happening even if I not explicitly fire a recomputing in the creation phase, that generally is done in loop.

So the point is maybe the "document preparation" phase, as if something go wrong when FreeCAD is restarted it ask to recover the document, so some sort of "writing a working document to disk" is happening "behind the scenes", (or maybe not too behind the scenes but above my knowledge).

A triggered recompute is easy as right click with mouse on an object and selecting the "appropriate menu item", an the state of "unfinished" is shown clearly in treeview.

I agree also that is rather difficult to work many "hour" on a drawing over "bad base objects", as I suspect that some recomputing will occur if i add an object that depends on another, as for some operations, the object is duplicated and the operation are working on the copy to compute things.

But not using so much the Gui to model things, I'm not an authoritative source.

As usual if someone find that I'm saying insanities, I would be very happy to know where I'm doing wrong assumptions or if I'm telling something imprecise or wrong, as some ancient Greek say, "The only thing I know is that I'm not knowing" (sorry for the citation, but English is not my mother language).

Best Regards to all.

Carlo D.
GitHub page: https://github.com/onekk/freecad-doc.
- In deep articles on FreeCAD.
- Learning how to model with scripting.
- Various other stuffs.

Blog: https://okkmkblog.wordpress.com/
User avatar
adrianinsaval
Veteran
Posts: 5541
Joined: Thu Apr 05, 2018 5:15 pm

Re: Recompute on file open

Post by adrianinsaval »

IPowIPi wrote: Thu Aug 05, 2021 8:10 am I think the quotes above were made under the assumption that a topo naming correction mechanism is already in place that fixes the native name hierarchy if it finds problems.
It was in the context of the previous comment that proposed not saving the mapped names in the file but generating them on file open by recomputing everything. That has always been fragile, the purpose of storing the discussed data is to overcome this, they were explaining why we need that data stored. At least that is my interpretation.
Post Reply