I put together a simple assembly with 100 prismatic pieses. They are held together using contact ties. Looks like at this level of number of contacts it has a very noticeable effect on remeshing. Where it initially took like a second per part, the new courser mesh is taking a good 5 seconds per part or more. example_thermal_assy.pmx (2.1 MB)
I was investigating another related problem where the model is super simple but then you apply a thermal BC or Load and it just takes a very long time to refresh. Looks like this particular one flat out just died on re-mesh.
Can’t you use a compound part here ? Remeshing would be way faster and you wouldn’t need those tied contacts. It’s better to avoid having so many features if possible.
yeah you’re right. I’m just learning more about the limitations. I think this is low priority obviously, but let’s say I had a very large supercomputer at my disposal and I wanted to run a large model in it, then it would help that we keep CPU intensive processes out of the GUI as much as possible. So for instance, instead of selecting all nodes when you click on a surface, maybe the program only selects 3 nodes or the bounding corner nodes that define the selection. later at run time then, a final selection is made with all the possible nodes in the surfaces selected. That way, the slow part of building the model goes faster and the entire selection where all that computing comes in happens only once right before calculix is called in.
You are right. Multiple/many parts are not optimized for performance yet. The problem is that instead of first, remeshing all the parts and then running the model update routines, now each part is meshed first and then model update routines are called each time a single part is remeshed.
Using PrePoMax 1.4.1, (I have not tested in 2 yet, I’m barely getting my feet wet) I noticed that the gui becomes significantly slow if I select a surface directly from the BC temperature menu. If I however create a surface first, then apply a temperature to that pre selected surface, then the gui works as expected. I think it goes along with this other issue, so just adding this as a note.
Ok here is the example set. You will have to change the mesh refinements from 10mm to 1mm so you can see the behaviour: Slow_Gui_Demo_Part.pmx (581.4 KB) Fast_Gui_Demo_Part.pmx (660.3 KB)
The “slow” version selects the surfaces to apply the temperatures
The “fast” version creates surfaces and then applies temperatures to those surfaces
Somehow applying “surface flux” does not have the same effect regardless of how the surfaces are picked. Maybe if your computer is much faster than mine, you won’t see a difference.
To see the “bug” or observation simply select the temperature BC. In the slow version it will take much longer to complete the selection action or just about any action throughout the gui actually. On the fast version the gui remains unaffected by the increased mesh size at the locations where temperature BC was applied.
Yeah, the benchmark tests are pretty good because they are so simple and you can understand easily what to expect in the result. So cubes and spheres and such all have analytical solutions that can be used to compare with the FEA result.
But some times, its interesting to see what the software can do. Flexing our muscles, lets say. It can be something that gives a counter intuitive result like I recently had with a bar that would bend the wrong way when heated. But it can also be some really cool looking experiment where a larger assembly is tested or something to that effect where we wouldn’t normally venture into because it is specialized. Obviously we wouldn’t want to drop in models from our respective employers, but we could share simplified versions.
Some really good examples that I’ve seen so far are the bolted connection example where a preload is applied, and an example where a torque is applied. Anyway, it would probably be part of the tips and tricks section, so a little out of topic.
