difficulty identifying elements in UI

[J-Dunn]

In manipulating non trivial objects it is necessary to identify which elements are being selected or to be able to select a specific element from the treeview.

eg. Referring to the assembly uploaded in #166:

There are two holes into which the two bearing-axis assemblies need to be inserted and aligned. Due to symmetry, it is difficult to know which one is being selected: hole01 or hole02.

Since most of they parts are greyed out in the treeview, nothing is indicated in the 3D view when a specific item is clicked in the treeview. Inversely , if a surface is selected in the 3D view, only the last element in the treeview which is not greyed out in the gets selected. This does not indicate the actual item selected. This is not helpful to identifying what has been selected.

Secondly, having applied a constraint, the default ( typically two ) elements get given default names. Coming back to an existing assy it is typically not clear visually what these banal names refer to, for example when coplanar. In order to give meaningful names to these elements one needs to know exactly what has been selected. Again this not at all evident in the UI.

Also, I am seeing names revert to meaningless defaults, which is not at all helpful. In the 3washer stack in bearing-spacer.fcstd, I had carefully given all elements clear, explicit names. Now after naming a couple of elements in the top level assy, I find most of the washer surfaces have lost the user defined names and returned to meaningless defaults.

Fortunately it crashed again and I was able to restart and delete transient objects so I did not need to re-edit all my element names ;)

[realthunder]

Since most of they parts are greyed out in the treeview, nothing is indicated in the 3D view when a specific item is clicked in the treeview. Inversely , if a surface is selected in the 3D view, only the last element in the treeview which is not greyed out in the gets selected. This does not indicate the actual item selected. This is not helpful to identifying what has been selected.

You probably misunderstood how PartDesign body works. All those features inside the body are the historical modeling steps which contains the whole geometry model at a historical time, except the last one, which holds the current state of the model. Even though a feature inside the body is named, say Chamfer, it does not mean it holds the chamfered face only. Instead, it is the whole model after you have performed the chamfer operation. This is why, when you show some feature in the middle of the body, other features are auto hidden, because otherwise there will be confusing overlaps.

Secondly, having applied a constraint, the default ( typically two ) elements get given default names. Coming back to an existing assy it is typically not clear visually what these banal names refer to, for example when coplanar. In order to give meaningful names to these elements one needs to know exactly what has been selected. Again this not at all evident in the UI.

You can use the navigation tools to jump to the owner.

Also, I am seeing names revert to meaningless defaults, which is not at all helpful

This is probably due to bug in #166. Please pull and build LinkStage3. Please also pull asm3 repo to test. There is only Python change in asm3, so no need rebuild.

[J-Dunn]

thanks now running 16302.

You can use the navigation tools to jump to the owner.

This does not seem to enable me to know whether I'm looking at bearing-hole01 or bearing-hole02 in the block.

I have a constraint between the under surface of the washers and the block surface where a sketch for the hole position lies. I can work out which instance of the bearing-axis-spacer I'm on but I can not determine which part that plane is. The link navigation tool takes me to Elements, not to Parts.

So, the problem is in the block45-2 itself. I have named the part ( sketch ) bearing02-face but cannot identify which element that is to name the element.

In this case I could go into edit the sketch from the treeview and watch to see as it spins round to the sketch editor but that is a special case that only applies to a sketch, and is really a hacky workaround.

Without some visual feedback in one direction or the other it seems there is no way work out which is which unless they are named at creation time.

[realthunder]

Please sync asm3 repo. No need to rebuild. You can continue click Go to linked button, and it will eventually lead you to the geometry model that owns the element.

[J-Dunn]

Thanks, so it is possible even if the path is somewhat complicated.

I've updated the assembly.py file in asm3

I've created the next level up in this assembly which uses two instances of the guide-block assembly. I went back to edit the guilde-block file to improve naming clarity and I now see two renditions of the block slightly offset from each other. It seems that this is related to there being relational links back to the parent assembly object.

I wanted to rework the alignment constraints placing the axes into the holes in the block but now I have two circles representing the entry to the hole. Which should I chose ? does it matter?

This presentation is very confusing, is this how it is intended to appear? Since they are both instances of the same assembly, what is the point of showing both?

guide-block-assy2-doubles-collection.zip rename *.tar.gz

[realthunder]

Because you change the ElementCount property and make the part instance an array. By default the new array element is offsetted by 1mm only. Just manually change the placement or use the mover to drag out the new instance.

[J-Dunn]

OK, thanks. What is the utility of having two renditions of the same thing? Are they now independent and can be edited separately? Two different versions of the same thing ? I'm a bit confused about what the two represent. I was assuming this was a bit like programming class and there were two instances of objects of that class. What is the logic behind the way this works?

[realthunder]

It is the same as making link to one object multiple times, and add them manually into an assembly. The Link has an array mode to simplify this task. It has other advanced usages like constraint multiplication. Also imagine the case you have a screw of 100 instances, and later decide to change the screw type, with Link array, you only need to change one LinkedObject instead of 100. The array elements have independent placement and visibility, but share the geometry and visual.

[J-Dunn]

OK, but why did I not see this at the previous level ? If you look at guide-block-assy2.fcstd there is an element count of two for the bearing+axis+spacer assy. Yet when I look at bearing-axis-spacer.fcstd, I don't see the double imaging.

[realthunder]

The ElementCount belongs to a Link that exists inside document guide-block-assy2. Therefore, the array element only exists inside guide-block-assy2. It does not affect the linked object in any way.

One thing I don't get it, you seem to be using Link array quite early on, why suddenly got confused now? You are using ElementCount to duplicate the brg+axis+spacer-assy inside guide-block-assy, aren't you?

[J-Dunn]

Yes, that is what I pointed out. The confusion comes from the fact that I appear to be getting a different behaviour now I use it on the block. I thought I had understood how it worked but I don't see the same thing.

I had a look back at the upload and I think what happened was that I had increased the component count in the guide-block-ass2 file , not in its parent object. In the case of the bearing-axis-spacer this was duped in the parent and thus I did not get a double in the actual assembly file of the child.

Sorry for the silly question, I was confusing myself.

Unrelated question: I need mirror image of this guild block assy. so that the bearings are the other way around. I could edit the sketch and move them but it would be nice if there is a simply way for mirror it and Save_As. Is that possible?

[realthunder]

There is a Scale property in every Link. Set it to -1 will give you a mirror. Note that the I didn't test much about this scale feature, and it is expected to cause problems, especially in complex link to link relations. In fact, I just fixed two bugs while trying this. Please sync and try.

[J-Dunn]

Cool , that worked fine.,

[J-Dunn]

I had my second block nicely placed and fully constrained, saved and closed asm3. Now when I reopen the assy file, the scale-1 block shows upside down and seem dissociated from the two elements used to constraint it. The elements show in highlight in the correct place but the block has lost connection with them. Recomputing the assy does not produce any errors but the block remains upside-down.

LH-assy-inverted-block-collection.zip

[realthunder]

Just committed a fix for this. Please sync LinkStage3.

[J-Dunn]

Perfect, I just opened the same file and it dropped back into place.

now running 16302. Any chance of another AppImage for the current build? I have a college following what I'm doing but he won't want to get deep into building everything from source.

[J-Dunn]

Am I organising these parts in a reasonable way?

How deep can this kind of assembly hierarchy go in practice? It's already getting rather long to open all these files and to switch from one tab to another.

I wondered about the choice of python for writing a CAD package. Not the most efficient language for complex tasks.

I have a fast 3GHz dual core Athlon but this mobo can't take more than 4GB or RAM. Is that likely to be a problem?

[realthunder]

Any chance of another AppImage for the current build?

Sure, here it is.

Am I organising these parts in a reasonable way?

Looks fine.

How deep can this kind of assembly hierarchy go in practice?

You can find a few tips here about handling deep hierarchies, especially the assembly Freeze feature.

It's already getting rather long to open all these files and to switch from one tab to another.

Really? how long exactly? You can type the following command in Python console to turn on file open timing

App.setLogLevel('App', 3)

You can find the the timing in Report Panel after opening the file. On my computer, with the attached AppImage, it only took 2 seconds to open your latest attached file. I am using a desktop with Core i5 3.3G. FreeCAD is a bit hungry for memory, but for your particular file, it does not use that much of memory.

[J-Dunn]

Thanks. If I open asm3 then open the top level file it takes about 30s before I see the plate+bearing block assembly rendered on screen. That is 14 files open. The report window is totally blank. There is another bearing assy which has three new individual parts since I last uploaded here. Same sort of thing: bearing, spacer, axis.

Once it is all open it takes about 3s to flip from one tab to another and render the new part.

How important is multicore to FreeCAD since python is essentially a single thread interpreter? Does it run multiple instances to make use of multicore CPUs?

It remains usable but I'm finding I have to wait, just while moving around the tree view for it to catch up. Sometimes I think I have not clicked on something and do it again but it's just being slow. I was wondering how this will scale as the hierarchy expands.

[realthunder]

If I open asm3 then open the top level file it takes about 30s before I see the plate+bearing block assembly rendered on screen. That is 14 files open. The report window is totally blank.

Can you attach the files here and let me have a try?

The report panel shows the statistics after loading all files. You may need to right click the report panel and enable Options->Log to see the output. You probably want to enable everything here to see other outputs. Also don't forget to run the setLogLevel command above. You only need to run the command once, and it will be remembered if you exit FreeCAD normally.

You can use the Freeze feature to reduce the number of file needed in upper hierarchy. For example, if you freeze bearing+axis+spacer, then none of the the sub-assemblies will be loaded for upper assembly.

Does it run multiple instances to make use of multicore CPUs?

Unfortunately, current FreeCAD is predominately a single thread application. The underlying CAD kernel support multithreading in some operation, depending on whether you enable it during compilation.

[J-Dunn]

enable Options->Log to see the output. thanks:

<App> Application.cpp(634): plate_blk_assy restore time: 0.840053s
<App> Application.cpp(635): plate_blk_assy postprocess time: 0.156751s
<App> Application.cpp(637): total time: 45.1759s

The underlying CAD kernel support multithreading in some operation, depending on whether you enable it during compilation.

Is that OpenCascade? How do I do that?

and it will be remembered if you exit FreeCAD normally.

Can't remember when that last happened ;) , still getting Close-All crashing.

[realthunder]

Can you show the whole statistics? It list the time spend on opening each of the files.

Is that OpenCascade? How do I do that?

Yes, but that only affect the modeling time, not much for assembling. The compile time option is HAVE_TBB. You can check in your OpenCascade build directly, CMakeCache.txt, search for this option.

[J-Dunn]

U-bearing_LH-plate-collection.zip

hopefully I have not missed anything. I need to start a script for this now. EDIT. ISO4762_M12x100_BTR got included as fcstd1, should be the same , rename it/

<App> Application.cpp(634): washer_M10 restore time: 5.06555s
<App> Application.cpp(635): washer_M10 postprocess time: 0.0555497s
<App> Application.cpp(634): ISO4762_M12x100_BTR restore time: 4.14517s
<App> Application.cpp(635): ISO4762_M12x100_BTR postprocess time: 0.0431754s
<App> Application.cpp(634): bearing_spacer restore time: 4.35965s
<App> Application.cpp(635): bearing_spacer postprocess time: 0.237206s
<App> Application.cpp(634): axis_grooved restore time: 3.98693s
<App> Application.cpp(635): axis_grooved postprocess time: 0.0770787s
<App> Application.cpp(634): bearing_6200 restore time: 3.89191s
<App> Application.cpp(635): bearing_6200 postprocess time: 0.154269s
<App> Application.cpp(634): ISO4762_M12x100_BTR_assy restore time: 3.86491s
<App> Application.cpp(635): ISO4762_M12x100_BTR_assy postprocess time: 0.0719681s
<App> Application.cpp(634): U_bearing_spacer restore time: 3.26004s
<App> Application.cpp(635): U_bearing_spacer postprocess time: 0.0422378s
<App> Application.cpp(634): U_bearing_20mm restore time: 2.98405s
<App> Application.cpp(635): U_bearing_20mm postprocess time: 0.0528025s
<App> Application.cpp(634): bearing_axis_spacer restore time: 2.79696s
<App> Application.cpp(635): bearing_axis_spacer postprocess time: 0.15805s
<App> Application.cpp(634): block45_2 restore time: 2.64121s
<App> Application.cpp(635): block45_2 postprocess time: 0.27933s
<App> Application.cpp(634): BTR_U_groove_spacer_assy restore time: 2.02534s
<App> Application.cpp(635): BTR_U_groove_spacer_assy postprocess time: 0.15086s
<App> Application.cpp(634): guide_block_assy2 restore time: 1.59089s
<App> Application.cpp(635): guide_block_assy2 postprocess time: 0.148712s
<App> Application.cpp(634): lhs_plate restore time: 1.98765s
<App> Application.cpp(635): lhs_plate postprocess time: 0.102836s
<App> Application.cpp(634): plate_blk_assy restore time: 0.840053s
<App> Application.cpp(635): plate_blk_assy postprocess time: 0.156751s
<App> Application.cpp(637): total time: 45.1759s

Those individual file times are consistent with the tab switching I estimated at 3s. Oddly , it's the lowest level and simplest files : washer and BTR which are taking longest and the highest level is fastest.

What is the longest part of opening these files? Is it the solver?

[J-Dunn]

https://www.opencascade.com/content/what-does-multithreading-havetbb-true-speed

It does not look like HAVE_TBB will do anything for FreeCAD until it is designed to profit from it. :(

[J-Dunn]

Is there a way to use scaling just on one axis? I have an SBR20 on either side of an I-beam but one needs to be shorter than the other but keep the profile dimensions. One is 1500mm, the other 1400mm

Doing this right back from the profile would mean an awful lot of duplication for such a trivial difference and so much commonality. Is there a trick I can apply here?

Thanks. SBR-on-I-beam-collection.zip

[realthunder]

What is the longest part of opening these files? Is it the solver?

No, the solver is not invoked when restoring. The longest time is usually file reading itself. Are you using a mechanical hard disk?

On my computer, it takes only 3 seconds to open your files. There is probably something wrong on your system. Can you try the AppImage, is it the same? What about your colleague? Did he also experience crash on CloseAll?

<App> Application.cpp(634): washer_M10 restore time: 0.134871s
<App> Application.cpp(635): washer_M10 postprocess time: 0.0133811s
<App> Application.cpp(634): ISO4762_M12x100_BTR restore time: 0.166721s
<App> Application.cpp(635): ISO4762_M12x100_BTR postprocess time: 0.0108459s
<App> Application.cpp(634): bearing_spacer restore time: 0.227551s
<App> Application.cpp(635): bearing_spacer postprocess time: 0.0569197s
<App> Application.cpp(634): axis_grooved restore time: 0.101712s
<App> Application.cpp(635): axis_grooved postprocess time: 0.00820354s
<App> Application.cpp(634): bearing_6200 restore time: 0.179895s
<App> Application.cpp(635): bearing_6200 postprocess time: 0.011782s
<App> Application.cpp(634): ISO4762_M12x100_BTR_assy restore time: 0.0970889s
<App> Application.cpp(635): ISO4762_M12x100_BTR_assy postprocess time: 0.0128692s
<App> Application.cpp(634): U_bearing_spacer restore time: 0.188124s
<App> Application.cpp(635): U_bearing_spacer postprocess time: 0.00805463s
<App> Application.cpp(634): U_bearing_20mm restore time: 0.108119s
<App> Application.cpp(635): U_bearing_20mm postprocess time: 0.00895242s
<App> Application.cpp(634): bearing_axis_spacer restore time: 0.218162s
<App> Application.cpp(635): bearing_axis_spacer postprocess time: 0.0614889s
<App> Application.cpp(634): block45_2 restore time: 0.272928s
<App> Application.cpp(635): block45_2 postprocess time: 0.0799797s
<App> Application.cpp(634): BTR_U_groove_spacer_assy restore time: 0.115192s
<App> Application.cpp(635): BTR_U_groove_spacer_assy postprocess time: 0.0291578s
<App> Application.cpp(634): guide_block_assy2 restore time: 0.161716s
<App> Application.cpp(635): guide_block_assy2 postprocess time: 0.0257923s
<App> Application.cpp(634): lhs_plate restore time: 0.662256s
<App> Application.cpp(635): lhs_plate postprocess time: 0.0234869s
<App> Application.cpp(634): plate_blk_assy restore time: 0.165601s
<App> Application.cpp(635): plate_blk_assy postprocess time: 0.0326759s
<App> Application.cpp(637): total time: 3.18508s

[realthunder]

It does not look like HAVE_TBB will do anything for FreeCAD until it is designed to profit from it. :(

FreeCAD does enable parallel processing if OpenCasCade is compiled with the flag.

Is there a way to use scaling just on one axis

I removed support of non-uniform scaling in Link on purpose, because it is bad for modeling. What OpenCasCade (OCC) does for non-uniform scaling is to change some of the curves into BSpline, even though they still look like a line or arc. And it is much slower, too. If you really want it, there is indeed a trick. For any Link, set its ElementCount to one, and ShowElement to False. You now have a collapsed link array with only one element. A collpased array does not show individual elements as items in the tree view. A side effect is that it allows you to manually set a scale vector for each of its element, using Python,

App.ActiveDocument.Link.ScaleList = [ App.Vector(1.0, 2.0, 1.0) ]

[J-Dunn]

No, the solver is not invoked when restoring. The longest time is usually file reading itself. Are you using a mechanical hard disk?

Yes, a hard-disk that is hard and disk shaped. 7200 rpm. However, those 16 files total about 300kB, that probably takes 30ms not 30s :? I could check the disk speed and do some diagnostics.

On my computer, it takes only 3 seconds to open your files. There is probably something wrong on your system. Can you try the AppImage, is it the same?

I will have a look at the AppImage.

I have just added another level and included the last assembly into it. FreeCAD is getting to the limit of being unusable. 5s to do just about anything: delete a constraint, anything. Stable apart from close-all but painfully slow.

What about your colleague? Did he also experience crash on CloseAll? He does not have net access right now. Someone using using a cell phone ended up hitting a telegraph pole and brought the line down. ( 21st century karma ). I'll ask him to test when he's back up.

Once I have things working a little better, I'll try the scaling trick, Thanks.

/dev/sdc:
 Timing buffered disk reads: 330 MB in  3.00 seconds = 109.97 MB/sec

Looks like my ballpark guess was bang on the money. ;) A raw read of that much data would take 3ms.

[realthunder]

Yes, a hard-disk that is hard and disk shaped. 7200 rpm. However, those 16 files total about 300kB

Each fcstd file are a zip archive actually. When loading, it will be extracted to a temporary directory on your hard disk. You 15 fcstd contains 472 files after extracting. Those random small file read and write is very demanding on hard disk. There might be potential optimization we can do for FC file loading by extraction on the fly without disk writing. But for now, like I said, once you finished one level assembly, you can freeze it to eliminate file loading lower level assembly in upper level.

[J-Dunn]

Thanks for the explanation, where do they get created? I see a ton of stuff like /tmp/FreeCADDoc* left over from crashes, is that it? Fedora shows that as tmpfs but I don't know where it resides. On root maybe or swap. It is the same size as my swap partition ( 4GB ).

If your system opens the same 16 ( really 472 ) files in 3s total that's 10x faster than mine. I don't think that is just disk speed. I'm downloading the AppImg.

I did try some cryogenics but when I created constraints and renamed elements it complained it could not write frozen files.

[J-Dunn]

I just opened the newer extra deep assy with the AppImg, it's just as slow. 76s cf 72s on my build. That new assy added four new asm3 files plus the new assy grouping all that together, not much more but WAY slower. This is getting worse exponentially with depth.

Same Close_All crashing.

cmake -DHAVE_TBB=true -DCMAKE_BUILD_TYPE=Release  ..

 .... 

-- Generating done
CMake Warning:
  Manually-specified variables were not used by the project:

    HAVE_TBB

[realthunder]

I did try some cryogenics but when I created constraints and renamed elements it complained it could not write frozen files.

The elements are meant to define the interface for an assembly for use by the upper assembly. When you create a part, i.e. a sub-assembly, you obviously already have some idea how this part is to be connected to other parts in upper assembly. So you should manually create those element first, and then freeze it. When using a frozen assembly in an upper hierarchy, you can constraint directly on those element you created manually. Please checkout the tutorial here for more details.

[realthunder]

cmake -DHAVE_TBB=true -DCMAKE_BUILD_TYPE=Release ..

Please try build OCC build with USE_TBB=On. However, as I mentioned above, this won't affect the file loading time in anyway.

[J-Dunn]

USE_TBB=On worked a lot better ;)
Do I need to rebuild linkStage3 ? I did a make on it but it did not seem to do any compiling.

I've seen that tuto but when I have named an element it does not always get used. Often when I create a constraint, it creates a new element reference in the parent and I have to go back, delete the one I named and rename the one FreeCAD made for me. The two side by side clearly highlight the same thing. I found this happening a lot using the inner surface of the the holes in the bearing block to align the axes to with an axialAlignment. I went over it several times but could not work out why it would not use my predefined elements. Sometimes it works. Never understood why.

BTW whenever you post links like above I get a 404. You seem to forget part of the URL. https://github.com/realthunder/wiki/How-to-Handle-Large-Scale-Assembly https://github.com/realthunder/FreeCAD_assembly3/wiki/How-to-Handle-Large-Scale-Assembly

[realthunder]

Do I need to rebuild linkStage3 ? I did a make on it but it did not seem to do any compiling.

No, you only need to rebuild OpenCasCade. BTW, you are invoking cmake in OpenCasCade's build directory, right?

I've seen that tuto but when I have named an element it does not always get used

In the screencast of that tutorial, I showed how to use the element directly for constraining. Simply expand the Elements tree item, and select the element there. The reason why you are experiencing problem, I guess, is that you are building your model while building the assembly. The element you created are from some historical body feature, and you later constrain on newer features.

[J-Dunn]

cmake , yes, thanks. then make ; make install ;)

I can see current date stamps in : /usr/local/include/opencascade

EDIT , no wait:

ls -ail /usr/local/include/opencascade/Adaptor2d_C*
1592399 -rw-r--r--. 1 root root 5882 May 29  2018 /usr/local/include/opencascade/Adaptor2d_Curve2d.hxx
1592400 -rw-r--r--. 1 root root  945 May 29  2018 /usr/local/include/opencascade/Adaptor2d_Curve2dPtr.hxx

None of the libs do not seem to have been changed since my original build?

-- Up-to-date: /usr/local/lib/libTKTObjDRAW.so.7
-- Up-to-date: /usr/local/lib/libTKTObjDRAW.so
-- Up-to-date: /usr/local/lib/libTKQADraw.so.7.3.0
-- Up-to-date: /usr/local/lib/libTKQADraw.so.7
-- Up-to-date: /usr/local/lib/libTKQADraw.so
-- Up-to-date: /usr/local/bin/DRAWEXE-7.3.0
-- Up-to-date: /usr/local/bin/DRAWEXE

all these files are dated 1st Dec. eg.:

ls -ail /usr/local/lib/libTK*
592880 lrwxrwxrwx. 1 root root      14 Dec  1 09:44 /usr/local/lib/libTKBinL.so -> libTKBinL.so.7
592875 lrwxrwxrwx. 1 root root      18 Dec  1 09:44 /usr/local/lib/libTKBinL.so.7 -> libTKBinL.so.7.3.0
592873 -rwxr-xr-x. 1 root root  354832 Dec  1 02:30 /usr/local/lib/libTKBinL.so.7.3.0

I will have another look at the tuto but like I said elsewhere I find them way too fast to follow precisely and the disadvantage with a Peek gif is that you cannot pause to check something out in detail to see what is what. To someone who is already familiar it may work but as a tutorial it is way too fast, I find.

[J-Dunn]

OK , I have manually removed anything looking like it's occt related; done make clean on opencascade, and doing a complete rebuild from cmake onwards.

I think with all these various out of tree builds hanging around there are version conflicts and some dead lib files which maybe in the path.

hmm ... /usr/local/lib/libTK* gets today's date but

ls -ail /usr/local/include/opencascade/Draw*
690049 -rw-r--r--. 1 root root  2294 May 29  2018 /usr/local/include/opencascade/Draw_Appli.hxx
690050 -rw-r--r--. 1 root root  1760 May 29  2018 /usr/local/include/opencascade/Draw_Axis2D.hxx
690051 -rw-r--r--. 1 root root  1748 May 29  2018 /usr/local/include/opencascade/Draw_Axis3D.hxx
690052 -rw-r--r--. 1 root root  2200 May 29  2018 /usr/local/include/opencascade/Draw_Box.hxx
690053 -rw-r--r--. 1 root root  1927 May 29  2018 /usr/local/include/opencascade/Draw_Chronometer.hxx

That's headers, so that may not be a problem.

Looking back at my install notes, I downloaded from here: https://git.dev.opencascade.org/gitweb/?p=occt.git;a=snapshot;h=refs/tags/V7_3_0;sf=tgz

[J-Dunn]

Despite having kindly released this as open source they don't actually seem that keen on you getting the source. I don't find any link to source code on their site. Just how to compile other peoples' code :?

https://dev.opencascade.org/doc/overview/html/occt_dev_guides__building.html

What is the definitive sourcecode for 7.3.0 , and where do I find it?

[J-Dunn]

Another little niggly bug that you may want to look at at some point: when I use F2 to edit an element , when I exit edit mode the element still has the highlight colour ( dark blue ) but no longer has the keyboard input focus.

this means that pressing F2 again will not re-enter edit mode and and up and down arrows will not select previous/following entries in the treeview.

There is an inconsistency in user feedback : the colour indicating it is still selected when it isn't and a lack of clarity about what does have the keyboard focus ( maybe nothing has ).

I mention this just so you are aware, but the other error in this area which I flagged is more annoying: the fact that Esc does not cancel the edit but does the same as Enter-key: ie confirms the edit changes.

If an edit goes wrong, there should be an obvious way to quit out without change. This would normally be the Escape key ( hence the name of this key ). It would be worth looking at what the onKeyPress event does in this case and why it is not responding in a more conventional way to char(27).

[J-Dunn]

I have tried freezing several files but it does not seem to prevent loading as you suggested. I have frozen everything in sight but if I open the block assy file it still opens all its children : block45-2, axis, bearing-spacer and washer.

I also had one of my hard drives showing rather high rate of read errors, so I eliminated it from the system. This sadly did not improve anything.

[realthunder]

What is the definitive sourcecode for 7.3.0 , and where do I find it?

https://git.dev.opencascade.org/repos/occt.git

Another little niggly bug that you may want to look at at some point: when I use F2 to edit an element , when I exit edit mode the element still has the highlight colour ( dark blue ) but no longer has the keyboard input focus.

I'll look into that later.

I have frozen everything in sight but if I open the block assy file it still opens all its children

This freeze feature seems to be broken now. I'll fix it soon.

[J-Dunn]

Thanks, I'll build from git , a clean compilation takes about 2h. Not too sure what that snapshot archive was but there seems to be quite a lot of diffs.

[realthunder]

Please do not use the unstable master branch. Run git checkout V7_3_0 for the official released 7.3.0. This will avoid lots of potential hard to trace problems.

[J-Dunn]

Damn, it had just finished compiling too. Well spotted.

git checkout V7_3_0  
Checking out files: 100% (3266/3266), done.
Note: checking out 'V7_3_0'.

You are in 'detached HEAD' state. You can look around, make experimental
changes and commit them, and you can discard any commits you make in this
state without impacting any branches by performing another checkout.

If you want to create a new branch to retain commits you create, you may
do so (now or later) by using -b with the checkout command again. Example:

  git checkout -b <new-branch-name>

HEAD is now at 42da0d511 Correction of corrupted png file

git checkout -b V7_3_0  
Switched to a new branch 'V7_3_0'

cmake USE_TBB=On -DCMAKE_BUILD_TYPE=Release  ../occt
....
-- Info: TKIVtk and TKIVtkDraw toolkits excluded due to VTK usage is disabled

is that info about TKIVtkDraw normal ?

[J-Dunn]

OK, I have the new build with multithreading enabled ( allegedly ), no difference to speed or crashes but that's another thing in a known state.

I'm going to have to remain with fewer levels in the hierarchy until this is working better. It is really not usable with the full file set I have now.

How does it end up with hundreds of files from my 16 fcstd files? Is there a separate file for each part, element and constraint?

[J-Dunn]

Could you clarify your earlier comment about opening times. I'm taking 3s per file and you opened the whole multilevel assembly in 3s, is that correct ? Are you using SSD?

This seems like a madly inefficient way of storing data. I just unzipped my U-bearing-assy file and it produced 34 files, half of which were only 8bytes long and most of the rest were ASCII renditions of 16s.f. floating point numbers.

Is this storage system imposed by opencascade formats?

[realthunder]

Could you clarify your earlier comment about opening times. I'm taking 3s per file and you opened the whole multilevel assembly in 3s, is that correct ? Are you using SSD?

Yes, it takes 3 seconds to open all files on my computer. And yes, I am using SSD. However, I digged a bit deeper into the file loading code. I was wrong. FreeCAD is using extraction on the fly. There is no extraction to disk, i.e. no disk write when loading file. I even tested loading files from a USB thumb drive, barely any slow down. There must be something else holding your system back. Do you have other computer to try? Or try one of those LiveCD of other linux system (I am using Ubuntu 16.04) and run the AppImage to see if there is an obvious speed difference.

This seems like a madly inefficient way of storing data. I just unzipped my U-bearing-assy file and it produced 34 files, half of which were only 8bytes long and most of the rest were ASCII renditions of 16s.f. floating point numbers.

You can guess what those files are for based on their file name. I guess the intention is to save the verbosity of XML for those array of data. Whether that is effective is indeed debatable.

[J-Dunn]

Good idea, I will see whether I can build on another machine or use alive boot and AppImage.

BTW , presumably I will need to rebuild stage3 having built the multithread occt. This seems to fail:

/usr/include/eigen3/Eigen/src/Core/products/GeneralBlockPanelKernel.h:1203:104: error: inconsistent operand constraints in an ‘asm’
             #define EIGEN_GEBP_2PX4_SPILLING_WORKAROUND __asm__  ("" : [a0] "+rm" (A0),[a1] "+rm" (A1));
                                                                                                        ^
/usr/include/eigen3/Eigen/src/Core/products/GeneralBlockPanelKernel.h:1221:15: note: in expansion of macro ‘EIGEN_GEBP_2PX4_SPILLING_WORKAROUND’
               EIGEN_GEBP_2PX4_SPILLING_WORKAROUND                               \
               ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
/usr/include/eigen3/Eigen/src/Core/products/GeneralBlockPanelKernel.h:1245:13: note: in expansion of macro ‘EIGEN_GEBGP_ONESTEP’
             EIGEN_GEBGP_ONESTEP(0);
             ^~~~~~~~~~~~~~~~~~~
make[2]: *** [src/Mod/Mesh/App/CMakeFiles/Mesh.dir/build.make:112: src/Mod/Mesh/App/CMakeFiles/Mesh.dir/Core/Approximation.cpp.o] Error 1
make[1]: *** [CMakeFiles/Makefile2:1682: src/Mod/Mesh/App/CMakeFiles/Mesh.dir/all] Error 2
make: *** [Makefile:130: all] Error 2

[realthunder]

Found similar issue here. The solution is to either downgrade to eigen-3.3.5, or upgrade to 3.3.7.

[J-Dunn]

Ah, thanks. My Fedora does not seem to have eigen3 pkg only eigen3-devel . Is this just macros or headers ? This is getting messy. OK, looks like "eigen3" just installs the eigen-devel pkg.

Having set that back to 3.5.5 I'm now rebuilding occt and linkstage3 without multithreading. I need to work out other probs before worrying about introducing other possible sources of error.

[J-Dunn]

Going through a clean rebuild I noticed this OpenGL stuff while building slvs:

  FindOpenGL found both a legacy GL library:

    OPENGL_gl_LIBRARY: /usr/lib64/libGL.so

  and GLVND libraries for OpenGL and GLX:

    OPENGL_opengl_LIBRARY: /usr/lib64/libOpenGL.so
    OPENGL_glx_LIBRARY: /usr/lib64/libGLX.so

  OpenGL_GL_PREFERENCE has not been set to "GLVND" or "LEGACY", so for
  compatibility with CMake 3.10 and below the legacy GL library will be used.

ls -ail /usr/lib64/libGLX.so.0.0.0  /usr/lib64/libOpenGL.so.0.0.0
410431 -rwxr-xr-x. 1 root root  79744 Aug 16 20:04 /usr/lib64/libGLX.so.0.0.0
407693 -rwxr-xr-x. 1 root root 197576 Aug 16 20:04 /usr/lib64/libOpenGL.so.0.0.0

Should I set OpenGL_GL_PREFERENCE ?