I’m running into issues trying to model a wall assembly. So I tried a simplified smaller version (WallTest8) and all works fine. Then I increase the size of the wall in FreeCAD, follow the exact same procedure, and I get “Failed with results” and a temperature gradient that doesn’t make much sense (WallTest9). Anyone knows why?
I’m using v2.4.0.
If you scroll higher in the job monitor, you will see more specific error messages:
*ERROR in cascade: zero coefficient on the
dependent side of an equation
dependent node: 17543 direction: 0
new coefficient = 1.000000e-05
*ERROR in cascade: zero coefficient on the
dependent side of an equation
dependent node: 111 direction: 0
new coefficient = 1.000000e-05
*ERROR in cascade: zero coefficient on the
dependent side of an equation
dependent node: 113 direction: 0
new coefficient = 1.000000e-05
*ERROR in cascade: zero coefficient on the
dependent side of an equation
dependent node: 114 direction: 0
Use Tools → Find to locate these nodes. They are all located in this region:
So you should check the tie constraints there and look for an overconstraint - multiple tie constraints using the same surfaces in a conflicting manner.
In this case, it’s “Solid_part-1_to_Solid_part-7” and “Solid_part-7_to_Solid_part-2”. The same face is used once as master and once as slave. You can try this to get rid of the errors:
But (especially when using the Search contact pairs tool), you should check all the tie constraints for such conflicts and modify them if needed. It’s also recommended to always run a frequency step to check the connections in assembly models. And read all the warnings in the job monitor.
Thanks @FEAnalyst
I’ve checked the tie constraints and made sure there are no slave/master conflicts (as much as I can for 8 parts!). I am no longer getting errors, but the results still don’t make sense even as I 10x the conductivity of the screw. Is that conflict the only thing I should be looking for in tie constraint? I thought I’d try changing the ‘direction’ of ties in accordance to heat flow, but same result. Looked in the user manual but couldn’t find an answer.
Here are the warnings I’m getting (they’re all related to the connection between two parts)
The strange thing is that the smaller version (WallTest8) had the same number of tie constraint as the larger version, but its results are much more sensible.
Here’s the latest file.
Try putting two temperatures on the opposite ends of the domain and see if it conducts heat. Sometimes it’s just a matter of adjusting the legend and doing a section cut.
You should also make sure they have sufficient tolerances corresponding to the gaps between the parts, with some additional margin - try increasing them. Then the results of a frequency step can show if everything is properly connected.
That’s not necessary, pretty much the only rule here is that master side should have a coarser mesh.
This may mean some ties still overlap in a way (e.g. share common edges), but don’t worry about all the warnings related to them too much - they are usually almost inevitable and it’s just important you understand them and their impact on the model.
Actually, why are you using tie constraints instead of compound parts ? That would be the easiest way in most cases.
There are two different temperatures (0 and 20 C) on the outer and inner face of the wall/mechanical part. Adjusted the legend and now I can see some difference:
Well technically there are no ‘gaps’ – it’s just one part that is penetrating through different parts.
I watched this video that you made and thought I’d follow suit 
But the compound part is a great tip – it saved me time assigning materials and doing tie constraint. I assume I still have to do the tie constrain between the mechanical part > its surroundings & each of the layers. It did make some difference:
Thanks again @FEAnalyst!
Using section views and queries (on the selected nodes) also helps. Unfortunately, XY plots along path are not yet supported (but FreeCAD FEM and ParaView can do them).
Sometimes there are small gaps or interferences due to geometry misalignments and discretization. Position tolerance is the maximum orthogonal distance between the slave nodes and adjacent master faces for which constraints will be generated. The default value (2.5% of the typical element size) is often not enough.
Tie constraints are necessary only where compounding was not applied or didn’t work as expected. Because compounding ensures continuous meshes and eliminates the need for constraints.
There’s also thermal contact - you define a contact pair, specify gap conductance and this allows you to model imperfect heat transfer through the interface (tie constraints model interfaces with no thermal resistance).
What I like most about results manipulation is that I can get total heat flux of a surface without having to export to ParaView and do it there (what’s required under FreeCAD’s FEM).
For the legend, why does it display an extra min and an extra max value? Is there a way to fix this?
In my mind, if I compound the whole thing I wouldn’t be able to assign materials (or least it wouldn’t be easy). When I created a compound for the mechanical part I made sure to enable Merge compound parts.
In PrePoMax, it’s indeed convenient. But FreeCAD FEM has section print too.
The purpose of the topmost and bottommost values is to show the real extrema.
It’s still possible to assign individual materials, but I wouldn’t check that option. It’s disabled by default and shouldn’t be necessary.
But the bottom two and upper two entries have the exact same value, but different colours. Seems a little redundant and confusing
Because you have the same custom and real extrema. If you e.g. set Max to less than 20, the uppermost label will keep showing 20 for reference.
Perhaps a check could be added to hide the duplicated values if they are equal.
With the limit set as Automatic, the extremes are 0.25 and 19.02. Changing to Manual and setting min/max to -5 and 25 still shows two identical values at the top and bottom.
Seems like a bug to me.
Here’s how it works in Abaqus on which CalculiX is based:
If you have specified a maximum value that is less than the actual maximum or if you have specified a minimum value that is greater than the actual minimum, Abaqus displays the actual maximum or minimum value (respectively) in the legend.
So it could indeed be improved in PrePoMax to show the additional labels only when the automatic values are the true extrema.
I think this is unexpected behaviour. But in version 2.4.3, this is fixed. And there is a setting to hide these additional values if they are lower than the manually set limit. If they are higher, they are not shown.
Since the topic does not directly address a PrePoMax bug but rather a modelling problem, I am moving it to General Questions.
