Hasher mismatch warning when recomputing

[furgo16]

Is there an existing issue for this?

• [X] I have searched the existing issues

Problem description

Steps to reproduce:

1. Download the test file and uncompress it
2. In the folder with the uncompressed contents, open the cad/F4.0.FCStd file with FreeCAD
3. Right-click on the top element (F4.0) of the document tree
4. Choose Mark to recompute
5. Press Ctrl+R to recompute
6. The Report window outputs these warnings:

<TopoShape> TopoShapeExpansion.cpp(970): hasher mismatch
<TopoShape> TopoShapeExpansion.cpp(970): hasher mismatch
<TopoShape> TopoShapeExpansion.cpp(970): hasher mismatch
<TopoShape> TopoShapeExpansion.cpp(970): hasher mismatch
<TopoShape> TopoShapeExpansion.cpp(970): hasher mismatch
<TopoShape> TopoShapeExpansion.cpp(970): hasher mismatch
<TopoShape> TopoShapeExpansion.cpp(970): hasher mismatch
<TopoShape> TopoShapeExpansion.cpp(970): hasher mismatch
<TopoShape> TopoShapeExpansion.cpp(970): hasher mismatch
<TopoShape> TopoShapeExpansion.cpp(970): hasher mismatch

Full version info

OS: Ubuntu Core 22 (ubuntu:GNOME/ubuntu)
Word size of FreeCAD: 64-bit
Version: 1.1.0dev.38898 (Git) Snap 1156
Build type: Release
Branch: main
Hash: 32e09d9554db26414697ed19e0189ccab4ea9029
Python 3.10.12, Qt 5.15.10, Coin 4.0.0, Vtk 7.1.1, OCC 7.7.1
Stylesheet/Theme/QtStyle: OpenLight.qss/OpenLight/Qt default
Installed mods: 
  * OpenTheme 2024.9.1
  * ezydxf
  * Ondsel-Lens 2024.9.13.02
  * Assembly4 0.50.15

Subproject(s) affected?

Core

Anything else?

• Debugging might be easier if the "hasher mismatch" warning would mention which element it refers to.
• I would generally not worry too much about them, but this assembly tends to always derive at some point into a "Solve failed error" when manipulating it. The "hasher mismatch" warning and "Solve failed" error may or may not be related, but I thought I'd mention it.

Code of Conduct

• [X] I agree to follow this project's Code of Conduct

[luzpaz]

@bgbsww would you have a moment to diagnose this? TIA!

[maxwxyz]

@CalligaroV please

[furgo16]

Some more investigation:

1. By elimination, I've found out which component(s) the warning is coming from: It's the 10 links to the two external assemblies. The screen capture highlights the half of them used for the left window shash. If I remove any of these objects, the number of warnings keeps reducing, up to 0 (when I remove all ten of them).
2. I found a related forum conversation: https://forum.freecad.org/viewtopic.php?p=228949#p228949. Supposedly this was fixed (in Assembly 3? Link branch?), but I'm not sure if it ever made it into main.

   Hashing mismatch error is cause by the external link, which brings a shape from another document with a different hasher than the linking document. This will be fixed in the next release.

[CalligaroV]

@maxwxyz, @furgo16, @luzpaz,

I would say that yes, this is a TNP-code related issue. The hasher / hashing mechanism has been introduced during the TNP integration project.

I remember seeing similar messages working/testing another issue and another PR related to the effect of TNP in Assemblies (Integrated Assembly WB) but haven't focused much as those warnings wasn't the main cause/purpose of the issue/PR.

I also remember seeing the removal of several ->getHasher() / ->getStringHasher() in various cleanup commits, therefor I guess it may take me quite some time to figure out which one(s) is(are) causing this issue.

How critic is this one?

My "task list" is filling up quickly and therefor I'd like to understand what should have priority. :sweat_smile:

[furgo16]

Thank you.

How critic is this one?

I'd like to help with input, but I'm not knowledgeable enough with TNP and the code to have an informed opinion on how critical this one is.

All I can say is that for my use case (the test file on the issue), it appears to be a fairly fragile assembly, given the simplicity and low part count. For instance, it often fails with "Solve failed" errors when recomputing. Whether it is this "hasher mismatch" situation that leads to the assembly errors, I cannot tell.

Equally, I do not know if many other people will be in this situation with their models.

[CalligaroV]

You're welcome @furgo16!

I did a super quick analysis of the issue with

OS: Linux Mint 21.3 (X-Cinnamon/cinnamon)
Word size of FreeCAD: 64-bit
Version: 1.0.0RC2.38806 (Git) AppImage
Build type: Release
Branch: (HEAD detached at 1.0rc2)
Hash: 3d63fc6c2f665a8d5e6468845a419bcac80756c7
Python 3.11.9, Qt 5.15.13, Coin 4.0.3, Vtk 9.2.6, OCC 7.7.2
Locale: Italian/Italy (it_IT)
Stylesheet/Theme/QtStyle: OpenLight.qss/OpenLight/Qt default
Installed mods: 
  * Assembly4 0.50.15
  * freecad.gears 1.2.0
  * Beltrami 1.1.0
  * sheetmetal 0.4.24
  * Curves 0.6.44
  * fasteners 0.5.26
  * kicadStepUpMod 11.2.7
  * OpenTheme 2024.8.10
  * Render 2024.8.4
  * Ondsel-Lens 2024.7.5.02

following your steps in the OP and I don't get the hasher mismatch warnings. I do get many <App> Document.cpp(2900): F4_0#Fixed024 still touched after recompute error messages if, before marking the entire document for recompute and then recomputing, I open the left side of the door using the Integrated Assembly (simulation?) "drag function".

My dev build is currently in another branch I'm focused on, therefor before giving another try to this issue with a more recent version of main I'll hold until I'll make some progress on that one. This means, in any case, not before tomorrow late afternoon / evening (Italy time).

Sorry!

[furgo16]

@CalligaroV thanks for your help!

You're right, I cannot reproduce it with RC2 (AppImage), but I can on a main branch build (both snap and AppImage).

Version details (non-reproduceable issue, RC2, AppImage)

OS: Ubuntu 24.04.1 LTS (ubuntu:GNOME/ubuntu)
Word size of FreeCAD: 64-bit
Version: 1.0.0RC2.38806 (Git) AppImage
Build type: Release
Branch: (HEAD detached at 1.0rc2)
Hash: 3d63fc6c2f665a8d5e6468845a419bcac80756c7
Python 3.11.9, Qt 5.15.13, Coin 4.0.3, Vtk 9.2.6, OCC 7.7.2
Stylesheet/Theme/QtStyle: unset/FreeCAD Classic/Qt default
Installed mods: 
  * OpenTheme 2024.9.1
  * WikiPropertiesGenerator.FCMacro

Version details (reproduceable issue, main, snap)

OS: Ubuntu Core 22 (ubuntu:GNOME/ubuntu)
Word size of FreeCAD: 64-bit
Version: 1.1.0dev.38898 (Git) Snap 1156
Build type: Release
Branch: main
Hash: 32e09d9554db26414697ed19e0189ccab4ea9029
Python 3.10.12, Qt 5.15.10, Coin 4.0.0, Vtk 7.1.1, OCC 7.7.1
Stylesheet/Theme/QtStyle: OpenLight.qss/OpenLight/Qt default
Installed mods: 
  * OpenTheme 2024.9.1
  * ezydxf
  * Ondsel-Lens 2024.9.13.02
  * Assembly4 0.50.15

Version details (reproduceable issue, main, AppImage)

OS: Ubuntu 24.04.1 LTS (ubuntu:GNOME/ubuntu)
Word size of FreeCAD: 64-bit
Version: 1.1.0dev.38923 (Git) AppImage
Build type: Release
Branch: main
Hash: d20cb9e6ee198beb2bfd7e72d3dec0a575e3f28c
Python 3.11.9, Qt 5.15.13, Coin 4.0.3, Vtk 9.2.6, OCC 7.7.2
Stylesheet/Theme/QtStyle: unset/FreeCAD Classic/Qt default
Installed mods: 
  * OpenTheme 2024.9.1
  * WikiPropertiesGenerator.FCMacro

Regarding the <App> Document.cpp(2900): F4_0#Fixed024 still touched after recompute errors, that's exactly what I meant with the assembly being fragile. I'm guessing you're also getting the "Solve failed" errors (#15385) before the "still touched after recompute" ones?

[furgo16]

After finding out that the freecad-daily PPA keeps old packages, I did a poor man's bisect by installing and testing packages successively from the RC2 onwards. Here's what I found out:

• Last good version (this bug is not reproducible) corresponds to https://github.com/FreeCAD/FreeCAD/commit/7e81287914868b638f114dcbc8465ff70f349b41 (PR: #16994, 2024-10-03)
• First bad version corresponds to: https://github.com/FreeCAD/FreeCAD/commit/7e81287914868b638f114dcbc8465ff70f349b41 (PR: https://github.com/FreeCAD/FreeCAD/pull/16982, , 2024-10-04)

There were 5 PRs merged between these two, and I could not imagine that either of the two boundary PRs introduced the bug, as they are fairly simple and do not touch assembly or TNP code.

Pending a proper bisect, I would bet that the issue first manifested in this PR amongst the 5, which is TNP-related: https://github.com/FreeCAD/FreeCAD/pull/16726

I hope this helps for now in potentially pinpointing the cause for the warnings.

[MiqCG]

Hi,

Not sure but I think I have the same problem with an assembly that I have been using through several dev revisions. I was just reading because I didn't have much to add until today.

I have made a new part (#110-006), with 1.1.0-38898, and when I tried to add to an assembly, most of the geometric part weren’t recognized as a usable JCS. On the Report view, lots of "<TopoShape> TopoShapeExpansion.cpp(970): hasher mismatch" and "<class 'IndexError'>" when trying to select a geometry.

See screencast attached and files, just in case the part has been badly created for some reason. In the folder there is several test of assembly (inserted or linked, copied, and with RC2 revision). Test made with clean .config .cache. share folders. And same behaviour with revision 1.0.0RC2.

https://github.com/user-attachments/assets/a37d6ca1-fa47-4862-a4ec-3399f70abb90

Ass_test_1.zip

OS: Devuan GNU/Linux 5 (daedalus) (XFCE/xfce) Word size of FreeCAD: 64-bit Version: 1.1.0dev.38898 (Git) AppImage Build type: Release Branch: main Hash: 32e09d9554db26414697ed19e0189ccab4ea9029 Python 3.11.9, Qt 5.15.13, Coin 4.0.3, Vtk 9.2.6, OCC 7.7.2 Locale: Catalan/Spain (ca_ES) Stylesheet/Theme/QtStyle: FreeCAD Light.qss/FreeCAD Light/Fusion

[furgo16]

I can confirm the behavior ins @MiqCG's assembly.

Steps to reproduce (same as video):

1. Download and uncompress the test file: Ass_test_1.zip
2. Open Assembly_link_1.FCStd with FreeCAD; ensure the Report View is visible
3. Double-click on Assembly on the document tree to activate the assembly and load the Assembly Workbench
4. Click on the "Create a Fixed Joint" command on the toolbar, or press F
5. Hover over the center of the top face of the 220-004-1 component, and click on it to set it as the first connector of the joint
6. Hover over any part of the 110-006 component
7. Expected: no errors
8. Actual: the report panel is being overflooded with <TopoShape> TopoShapeExpansion.cpp(970): hasher mismatch warnings. Occasionally the following error is thrown:

<class 'IndexError'>
Traceback (most recent call last):
  File "/snap/freecad/1161/usr/Mod/Assembly/JointObject.py", line 1778, in moveMouse
    vertex_name = UtilsAssembly.findElementClosestVertex(self.assembly, ref, newPos)
  File "/snap/freecad/1161/usr/Mod/Assembly/UtilsAssembly.py", line 406, in findElementClosestVertex
    face = obj.Shape.Faces[elt_index - 1]
IndexError: list index out of range

I could also reproduce the behavior on the RC2 AppImage. The only difference is that RC2 only throws the <class 'IndexError'> as a warning without the traceback.

I'm not sure whether the Python error is related or whether it should be reported as a separate issue. In any case, one similarity between the two models (original issue and the previous commenter's) is that they use external links to put together the assembly.

Version details (reproducible, main)

``` OS: Ubuntu Core 22 (ubuntu:GNOME/ubuntu) Word size of FreeCAD: 64-bit Version: 1.1.0dev.38926 (Git) Snap 1161 Build type: Release Branch: main Hash: a9bff78974f301100134a13c636e23aa91be5bcf Python 3.10.12, Qt 5.15.10, Coin 4.0.0, Vtk 7.1.1, OCC 7.7.1 Stylesheet/Theme/QtStyle: OpenLight.qss/OpenLight/Qt default Installed mods: * OpenTheme 2024.9.1 * ezydxf * Ondsel-Lens 2024.9.13.02 * Assembly4 0.50.15 ```

Version details (reproducible, RC2)

``` OS: Ubuntu 24.04.1 LTS (ubuntu:GNOME/ubuntu) Word size of FreeCAD: 64-bit Version: 1.0.0RC2.38806 (Git) AppImage Build type: Release Branch: (HEAD detached at 1.0rc2) Hash: 3d63fc6c2f665a8d5e6468845a419bcac80756c7 Python 3.11.9, Qt 5.15.13, Coin 4.0.3, Vtk 9.2.6, OCC 7.7.2 Stylesheet/Theme/QtStyle: unset/FreeCAD Classic/Qt default Installed mods: * OpenTheme 2024.9.1 * WikiPropertiesGenerator.FCMacro ```

[MiqCG]

In any case, one similarity between the two models (original issue and the previous commenter's) is that they use external links to put together the assembly.

True. With the file "Assembly_drag_1" (copied parts in assembly) no "Hasher mismatch" warning appear (with 1.1.0-38898), only the "<class 'IndexError'>" error, apart from the frustrating impossibility to select the proper location of the JCS.

[furgo16]

True. With the file "Assembly_drag_1" (copied parts in assembly) no "Hasher mismatch" warning appear (with 1.1.0-38898)

Good thinking. I'll try using local links next to see if the warnings go away

only the "<class 'IndexError'>" error, apart from the frustrating impossibility to select the proper location of the JCS.

I'd suggest creating a new issue for that one. Happy to confirm it as per the previous results, if it helps.

[furgo16]

I've redone the assembly by moving the externally linked subassemblies to now reside inside the document. That is, one file contains all of the assemblies. Other than fixing fillets and chamfers due to TNP errors, no other changes. With this new setup, I cannot reproduce the issue. So perhaps the idea that it's related to the external links seems plausible.

[furgo16]

@CalligaroV if you have some time, would you be able to come back to debugging this issue? Thanks!

[CalligaroV]

@furgo16 yes sure and sorry for not giving updates.

Probably I already applied some modifications that may help solving this issue while working on another one. I said "probably" because on the imported code there's also related to the Hashers.

Most likely that modification won't be enough but at least is one piece less to add.

Tomorrow evening I'll give it a try and give you a feedback, regardless for the outcome.

Sorry again!

[furgo16]

Thank you so much!

[CalligaroV]

You're welcome @furgo16!

Anyway, as promised, I tested the file and the steps of the OP with the modified branch of my previous post (if interested you can find it at https://github.com/CalligaroV/FreeCAD/tree/toponaming-ElementMapVersion-code-from-LS3)

Surprising enough the result is that no <TopoShape> TopoShapeExpansion.cpp(970): hasher mismatch warning is triggered!!!

Not sure if it's because of the modifications but I get several <PropertyLinks> PropertyLinks.cpp(427): F4_0#[...].Reference[...] auto change element reference F4_0#[...] warnings but those are caused exactly by the modification, needed to solve the issue that made me create the branch above, that make me think that those modifications are actually acting, if not solving the original issue.

Also, I still get a couple of 829.118 <Assembly> AssemblyObject.cpp(176): Solve failed: vector::_M_range_check: __n (which is 391) >= this->size() (which is 391) and several 830.418 <App> Document.cpp(2903): F4_0#[...] still touched after recompute error messages but, after dragging Left sash and (optionally) performing a recompute, I don't get anymore those error messages.

Unfortunately I can't say the same for @MiqCG's Ass_test_1.zip: the <TopoShape> TopoShapeExpansion.cpp(970): hasher mismatch warning messages still trigger.

How do we want to proceed? Keep focused on the OP (which likely will be solved when/if my branch will be merged) or extend the analysis so that also @MiqCG issue is solved?

TIA!

[MiqCG]

If mine is not really the same issue, I can open a different one when ever you say. I think this is the correct way to go forward, allowing to test your solution for the OP.

[MiqCG]

I can open a different one when ever you say.

Rereading part of the messages, now I see that this was in fact the proposal of @furgo16 on 11th October.

[CalligaroV]

Thanks @MiqCG for the reply!

I can open a different one when ever you say.

I don't have a strong opinion about that: if we consider what the 2 cases have in common (the <TopoShape> TopoShapeExpansion.cpp(970): hasher mismatch warning messages) then I'd say that the issue is the same even if AFAICT the root cause (in the code) of those messages is different.

Rereading part of the messages, now I see that this was in fact the proposal of @furgo16 on 11th October.

Are you referring to a specific comment or all @furgo16's comments in that date?

[MiqCG]

I am referring to this specific part of one message where he/she answer a part of a message of mine:

only the "<class 'IndexError'>" error, apart from the frustrating impossibility to select the proper location of the JCS.

I'd suggest creating a new issue for that one. Happy to confirm it as per the previous results, if it helps.

[furgo16]

@CalligaroV thanks again!

I'd favor opening a separate issue for @MiqCG's bug for incremental improvement reasons, and to make it easier to debug and test. Also,

if we consider what the 2 cases have in common (the <TopoShape> TopoShapeExpansion.cpp(970): hasher mismatch warning messages) then I'd say that the issue is the same even if AFAICT the root cause (in the code) of those messages is different.

Along those lines, if the root cause is different, then I would guess that it would require a separate PR for each cause, each with its own test case.

Not sure if it's because of the modifications but I get several <PropertyLinks> PropertyLinks.cpp(427): F4_0#[...].Reference[...] auto change element reference F4_0#[...] warnings but those are caused exactly by the modification, needed to solve the issue that made me create the branch above, that make me think that those modifications are actually acting, if not solving the original issue.

I don't really understand what you're trying to say here, particularly the "acting" part. Could you please clarify?

Also, I still get a couple of 829.118 <Assembly> AssemblyObject.cpp(176): Solve failed: vector::_M_range_check: __n (which is 391) >= this->size() (which is 391) and several 830.418 <App> Document.cpp(2903): F4_0#[...] still touched after recompute error messages but, after dragging Left sash and (optionally) performing a recompute, I don't get anymore those error messages.

I'll try this, thanks.

I also think its worth mentioning, does your branch at https://github.com/CalligaroV/FreeCAD/tree/toponaming-ElementMapVersion-code-from-LS3 include https://github.com/FreeCAD/FreeCAD/pull/15629

[MiqCG]

New issue created with my case problem. https://github.com/FreeCAD/FreeCAD/issues/17830

[MiqCG]

@CalligaroV , can you test your solution to this issue with the files attached in this comment?

I have found that in file #110-006.FCStd the tip wasn't on the last operation. Maybe this was interfering with your code.

[CalligaroV]

@furgo16, @MiqCG thanks for your replies!

@furgo16 About your https://github.com/FreeCAD/FreeCAD/issues/17033#issuecomment-2471775336:

I'd favor opening a separate issue for @MiqCG's bug for incremental improvement reasons, and to make it easier to debug and test.

Fine for me! I see that @MiqCG opened a new issue. I'll give it a look right after writing this reply.

Along those lines, if the root cause is different, then I would guess that it would require a separate PR for each cause, each with its own test case.

Sure. My doubt was about the title and content of the new issue. To me that would have been something like "Hasher Mismatch Vol.1" and "Hasher Mismatch Vol.2" :sweat_smile: But probably @MiqCG refined it, I'll discover that soon :wink:

I don't really understand what you're trying to say here, particularly the "acting" part. Could you please clarify?

Sure. My doubt is that probably the modified code is actually solving your issue but I'm not 100% sure about that: it may simply contribute in solving it together with other parts of the codebase (in debug I often see differences between the stack traces of main and LS3 for the same breakpoint of the modified code, therefor I can't state that your issue is solved only because of the modified code). My biggest fear is that the modifications solve your issue but create new ones or, worst, generate regressions.

I'll try this, thanks.

You're welcome! Please let me know if other issues raises.

I also think its worth mentioning, does your branch at https://github.com/CalligaroV/FreeCAD/tree/toponaming-ElementMapVersion-code-from-LS3 include #15629

What do you mean? It is based on main@ e661774a29029660819a5981e2b710638e59d86c (Nov 11, 2024) therefor it should contain also #15629 (main@ 15100357dfc98e72445fcf972b146d128ef327be, Oct 28,2024) If you're asking if I focused on testing the effect of the modifications on the issue/reasons that led me to import the missing code then no, sorry :confounded:

@MiqCG, about your https://github.com/FreeCAD/FreeCAD/issues/17033#issuecomment-2471879130: Sure! I'll test it right after reading the OP and discussion of #17830 Let's hope It's actually caused by the tip.

I'll let you know as soon as I complete the tests (likely in the next hours, after today's Developers Meeting)

[vkhodygo]

Also, I still get a couple of 829.118 <Assembly> AssemblyObject.cpp(176): Solve failed: vector::_M_range_check: __n (which is 391) >= this->size() (which is 391) and several 830.418 <App> Document.cpp(2903): F4_0#[...] still touched after recompute error messages but, after dragging Left sash and (optionally) performing a recompute, I don't get anymore those error messages.

I do get similar messages when I try to introduce some constraints, not sure if I need to create a new issue for this. I still can work with it, but at some point the performance drop becomes unbearable. I noticed the problem is related to the conventional fasteners I use, but I'm not sure if it's limited only to this: the first one or two can be attached without any issues, but the rest can't regardless of order and whatnot.

[drwho495]

This issue is fixed when switching from getting elements directly from the edges/faces/vertices array to using Shape.getElement()

This fix also improves speed by quite a bit.

change in UtilsAssembly.py

def get_element(shape, name):
    element = shape.getElement(name)
    if element is None:
        print(f"Unable to find element.")
        return None
    return element

(this method is used to get the element to find JCS placement before solving, this is where the warning WAS occuring)

[furgo16]

@drwho495 , thanks, this is great. Would you mind sending a PR with this change that we can test?

[drwho495]

@

I will soon, I need to fix some issues with my fork first.

[drwho495]

PR is created

@drwho495 , thanks, this is great. Would you mind sending a PR with this change that we can test?