Example 4: Different result, any idea why?

[j2l]

After almost 2 years, I gave FreeCAD now 1.0.2 a chance, and this time it worked! But I don't understand why this result:

Each time I run it, I get different results:

And it's very different from your result:

If force is applied at the upper left yellow-green arrow, and everything else is static, why this result? And why different with exactly same inputs? Any idea?

[fandaL]

With FreeCAD 1.0.0 and settings from example 4 as well as example 1 I get reasonable results. Your screens resemble me the situation when there is too fast material removal or when there is low mass_goal_ratio so that the solution starts to be unstable (e.g., after break of the right lower link, the structure is not able to get back to reasonable topology), which could be visible if you look at the topology evolution (more inp files in FreeCAD or resulting_states.vtk file in Paraview). Perhaps you can share beso_conf.py file and log file from the working directory, so I can look at input parameters.

[j2l]

Thank you @fandaL Here's the conf file: beso_conf.py.zip and the logs (I had to rerun so it's not exactly the same result as above): Plane_Mesh.log.zip

Could Calculix 2.23 help?

[fandaL]

I copied inputs from your beso_conf.py file (parameters correspond also to my log file generated from that optimization run). I got normal results and my peaks of the mean energy density in the graph do not exceed few percent, which correlates to relatively smooth changes in between iterations.

In the log file you provided, there are quite large peaks of the ener_dens_mean (mean energy density), especially in the iteration i = 12. Several years ago there was some calculix binary with which I run a file several times, and in one run from many it gave a nonsense stress peak on some arbitrary node, perhaps due to some numerical overflow problem (I cannot find the discussion about that). The issue was related only to multithreading, which should be possible to switch off by prescribing cpu_cores = 1 to the beso_conf.py If that is your case, using new calculix might help.

Moreover, in your log file, there is iteration “i” 15 right before 4 and there is “i” 16 two times, but I have no idea how that happened.

[j2l]

Indeed, even some one core runs of the exact same example are "out of bounds" and a few of them are almost normal, examples of both cases:

On ubuntu 22.04 (jammy), ccx is stuck at 2.17.3, I managed to install ccx_preCICE which is 2.20 (https://precice.org/adapter-calculix-get-adapter) and I changed to path_calculix = '/usr/bin/ccx_preCICE' but still some odd runs. But I still doesn't it in /tmp/.mount_FreeCAgKFhPl/usr/bin, only ccx is present. Is there anywhere else I could change ccx path?

I tried something ugly: Renamed /usr/bin/ccx and renamed /usr/bin/ccx_preCICE to /usr/bin/ccx. Now ccx --version is 2.20. With cpu_cores = 0, I still get huge peaks.

Notes:

• Changing to cpu_cores = 10 in beso_conf doesn't do anything, it runs on one core at a time (I have 12 cores).
• If I manually change to cpu_cores = 1 while beso_fc_gui is open and re-run it, it doesn't use one core but all cores, I have to kill FreeCAD and run it again.
• Hmm, even worse, manually change to cpu_cores = 1, restarting FreeCAD, fc_gui without "Generate conf. file" doesn't read cpu_cores = 1 from beso_conf (or ccx 2.20 is hardcoded as multi-CPU?).
• I didn't find how to stop the optimization cleanly, and closing FreeCAD (no more windows) doesn't stop the optimization process. A stop button might be needed in beso_fc_gui?
• BTW, is there a solution using GPU? I see Houdini (VFX, not CAD) seems to use it: https://www.youtube.com/shorts/aZt6HaNRv1I

[j2l]

Setting the force where it should be (AFAIK: one side is static, force is on the other side), ccx 2.20 slowly goes lalaland:

Even iteration 62 (the peak) is weird:

So, there's something I really don't get.

[fandaL]

• I didn't find how to stop the optimization cleanly, and closing FreeCAD (no more windows) doesn't stop the optimization process. A stop button might be needed in beso_fc_gui?

If you terminate Calculix from task manager/system monitor, optimization should stop soon due to missing Calculix results.

Setting the force where it should be (AFAIK: one side is static, force is on the other side), ccx 2.20 slowly goes lalaland:

Original boundary conditions were for symmetry on left side (long beam supported on both ends, loaded in the middle). It is slightly different situation when the left side is fixed and force is applied on the right side. But for testing purposes, both should give some results.