What causes "Document::recompute(): Wall007 still touched after recompute"

Post here for help on using FreeCAD's graphical user interface (GUI).
Forum rules
and Helpful information
IMPORTANT: Please click here and read this first, before asking for help

Also, be nice to others! Read the FreeCAD code of conduct!
elsordo
Posts: 33
Joined: Sat Jan 30, 2016 6:34 am

What causes "Document::recompute(): Wall007 still touched after recompute"

Postby elsordo » Sat Apr 20, 2019 7:58 pm

In the report view, I am seeing the following error.

Document::recompute(): Wall007 still touched after recompute

What does it mean?

I searched the forums and could not find any explanation.

-David
chrisb
Posts: 19505
Joined: Tue Mar 17, 2015 9:14 am

Re: What causes "Document::recompute(): Wall007 still touched after recompute"

Postby chrisb » Sun Apr 21, 2019 5:02 am

It means that something went wrong when recomputing. Please verify that you have checked all boxes in Preferences->General->OutputWindow. Do you see any other hint? If not please upload the file for further inspection.
User avatar
furti
Posts: 329
Joined: Mon Nov 27, 2017 5:27 pm

Re: What causes "Document::recompute(): Wall007 still touched after recompute"

Postby furti » Sun Apr 21, 2019 5:16 am

What version of FreeCAD are you using?
With some (now pretty old) 0.18 dev Vetsions of FreeCAD this happened when you had cloned windows inside a wall. But this problem should be fixed already. But maybe it is still a problem in 0.17.

Or do you have TechDraw pages with Arch section views in your document? I had this also when the TechDraw Pages where recomputed. But a second recompute of the whole document fixed the problem every time it occured.
Forgot to report this and had no time yet to look into this any further.
User avatar
wandererfan
Posts: 3144
Joined: Tue Nov 06, 2012 5:42 pm

Re: What causes "Document::recompute(): Wall007 still touched after recompute"

Postby wandererfan » Sun Apr 21, 2019 11:50 am

elsordo wrote:
Sat Apr 20, 2019 7:58 pm
Document::recompute(): Wall007 still touched after recompute

What does it mean?
The state "touched" means (roughly) that a DocumentObject has been changed and needs to be "recomputed". This is the "feature recompute".

When DocumentObject A is changed, that change cascades through the chain of DocumentObjects that are linked in some way to Document A. The cascade of changes (feature recomputes) is the "document recompute".

At the end of the document recompute, all of the DocumentObjects should be "untouched" - ie no pending changes. It can happen that something is changed during the cascade that leaves a DocumentObject in the "touched" state.

The message means that at the end of the cascade Wall007 is still touched, so the model has not changed as much as it should have.

This is a programming issue. Sometimes you can get around it by manually forcing another document recompute.
vocx
Posts: 1850
Joined: Thu Oct 18, 2018 9:18 pm

Re: What causes "Document::recompute(): Wall007 still touched after recompute"

Postby vocx » Sun Apr 21, 2019 4:26 pm

elsordo wrote:
Sat Apr 20, 2019 7:58 pm
In the report view, I am seeing the following error.
...
Read the answer from wandererfan, I think it's the best one.

Also, this isn't an "error"; as far as I can tell, it's a "warning", meaning it's not a critical issue. I've had this message appear many times with Arch Windows and other objects, but really, I don't notice a problem at all; in most cases the only thing you need to do is to recompute the document, and everything will be fine.
elsordo
Posts: 33
Joined: Sat Jan 30, 2016 6:34 am

Re: What causes "Document::recompute(): Wall007 still touched after recompute"

Postby elsordo » Wed Apr 24, 2019 2:01 am

Thanks for the responses.
wmayer
Site Admin
Posts: 14989
Joined: Thu Feb 19, 2009 10:32 am

Re: What causes "Document::recompute(): Wall007 still touched after recompute"

Postby wmayer » Thu May 30, 2019 1:01 pm

When running the unit tests then sometimes you can see this warning too when doing the Spreadsheet tests. I have analysed the concrete test that causes the warning:
The test testPrecedence() creates three objects: a spreadsheet, a cylinder and a pipe. The spreadsheet contains some expressions using the cylinder and pipe.

Now before the first recompute none of the objects has any connections to the other objects so the order of recompute is totally random. So, it can happen that the spreadsheet is recomputed as very first.

Now when the spreadsheet is being executed it runs the expressions and this way it adds a reference to the other objects to itself and the spreadsheet will be added to the in-list of the other two objects.

After the recompute of the cylinder and pipe they touch the objects of their in-list -- the spreadsheet.

For any subsequent recompute the warning won't appear any more because due to the dependency the spreadsheet will be computed as very last.