# Validation against ISO 10211-2017

**URL:** <https://prepomax.discourse.group/t/validation-against-iso-10211-2017/3467>\
**Category:** General Questions\
**Created:** [May 9, 2026, 7:59am UTC](https://prepomax.discourse.group/t/validation-against-iso-10211-2017/3467 "2026-05-09T07:59:07Z")\
**Posts on this page:** 20\
**Page:** 1

<div class="post-metadata">

**Author:** ![CosmoKramer](https://yyz2.discourse-cdn.com/free1/user_avatar/prepomax.discourse.group/cosmokramer/32/6636_2.png) [@CosmoKramer](https://prepomax.discourse.group/u/CosmoKramer)\
**Post date:** [May 9, 2026, 7:59am UTC](https://prepomax.discourse.group/t/validation-against-iso-10211-2017/3467/1 "2026-05-09T07:59:07Z")

</div>

I’m trying to validate PrePoMax v2.5.0 against ISO 10211-2017. The standard consists of 4 test cases (1-4) and to be classified as a _three-dimensional steady-state high precision method_, the software has to pass all 4.

I’ve run Case 3 with no probs. For Case 4 however, I couldn’t get the results to be within the allowed margin of error (≤ 1% for heat flow and ≤ 0.005 C for temperature). Closest I got was 0.530 W (1.908%) for heat flow and 0.795 C (0.010 C) for temperature.

 ![image](https://global.discourse-cdn.com/free1/uploads/prepomax/original/2X/1/14bb7c1831ed35103a1e3c77abcdcb9bbf777b7b.png)

The pmx file can be downloaded from [here](https://1drv.ms/u/c/eec7215cdc16258e/IQDT-nKqx1C4TY3PFIDP0PvbAV52DL3cSY0KjzTtXTUXdxc?e=lbFXAa). The standard can be viewed [here](https://1drv.ms/b/c/eec7215cdc16258e/IQAy8FhaJocTQ5Nl_vdYv1lJAW80WI855Zw3lhS8tv7gbjY?e=RYQ2uW) (Case 4 is on p.44).

I’ll continue to try different tweaks and post updates here. It’ll be good to get participation from the community on this project as it would add more confidence to the software.

Cheers!

---

<div class="post-metadata">

**Author:** ![FEAnalyst](https://yyz2.discourse-cdn.com/free1/user_avatar/prepomax.discourse.group/feanalyst/32/688_2.png) [@FEAnalyst](https://prepomax.discourse.group/u/FEAnalyst)\
**Post date:** [May 9, 2026, 8:14am UTC](https://prepomax.discourse.group/t/validation-against-iso-10211-2017/3467/2 "2026-05-09T08:14:27Z")

</div>

Accuracy is on the solver’s side and you are actually validating CalculiX, so it might be better to ask on its forum: [https://calculix.discourse.group/](https://calculix.discourse.group/)

The setup looks good (after all, 2% accuracy is very close already). I assume that you’ve tried further refining the mesh. You could use hex elements here since the geometry is very simple, but you would have to split it so that all subvolumes have 5 or 6 faces with 3 or 4 edges each.

Ideally, you should avoid using a tie constraint and just compound both parts to get a continuous mesh.

---

<div class="post-metadata">

**Author:** ![CosmoKramer](https://yyz2.discourse-cdn.com/free1/user_avatar/prepomax.discourse.group/cosmokramer/32/6636_2.png) [@CosmoKramer](https://prepomax.discourse.group/u/CosmoKramer)\
**Post date:** [May 9, 2026, 11:15am UTC](https://prepomax.discourse.group/t/validation-against-iso-10211-2017/3467/3 "2026-05-09T11:15:50Z")

</div>

Compounding the whole thing makes it difficult to assign materials later on (there’s two materials). But getting past that through `Region type` \> `Part name`, I get the following warning before running the analysis:

 ![image](https://global.discourse-cdn.com/free1/uploads/prepomax/original/2X/d/d0067053bc77da95f99a6c690d62fe4ab13fb7b0.png)

And ignoring that, I get the following error:

 ![image](https://global.discourse-cdn.com/free1/uploads/prepomax/original/2X/a/aebe42753637814b7bf90fba972eb9b7b224fe41.png)

---

<div class="post-metadata">

**Author:** ![FEAnalyst](https://yyz2.discourse-cdn.com/free1/user_avatar/prepomax.discourse.group/feanalyst/32/688_2.png) [@FEAnalyst](https://prepomax.discourse.group/u/FEAnalyst)\
**Post date:** [May 9, 2026, 11:52am UTC](https://prepomax.discourse.group/t/validation-against-iso-10211-2017/3467/4 "2026-05-09T11:52:39Z")

</div>

I guess that the previously meshed individual parts remained in the FE Model tab. And you should disable the option to merge compound parts into a single part. Then you will be able to assign materials normally.

> **[Dropbox](https://www.dropbox.com/scl/fi/vabyo102bzv4xs7sj9k0c/Case4-mod.pmx?rlkey=q8b9iutrbhznyhaqznqa5tjg6&st=c5xpv3yb&dl=0)**

---

<div class="post-metadata">

**Author:** ![FEAnalyst](https://yyz2.discourse-cdn.com/free1/user_avatar/prepomax.discourse.group/feanalyst/32/688_2.png) [@FEAnalyst](https://prepomax.discourse.group/u/FEAnalyst)\
**Post date:** [May 9, 2026, 12:17pm UTC](https://prepomax.discourse.group/t/validation-against-iso-10211-2017/3467/5 "2026-05-09T12:17:50Z")

</div>

And here’s your model with a hex mesh (had to partition it first):

[Case 4 hex.pmx](https://prepomax.discourse.group/uploads/short-url/eYFvXmGS0wI05UXdL8wd5vOZvJA.pmx) (4.9 MB)

Of course, you can try refining it further. It should be lighter than the model meshed with tetras, though.

---

<div class="post-metadata">

**Author:** ![FEAnalyst](https://yyz2.discourse-cdn.com/free1/user_avatar/prepomax.discourse.group/feanalyst/32/688_2.png) [@FEAnalyst](https://prepomax.discourse.group/u/FEAnalyst)\
**Post date:** [May 9, 2026, 12:37pm UTC](https://prepomax.discourse.group/t/validation-against-iso-10211-2017/3467/6 "2026-05-09T12:37:28Z")

</div>

I’ve just noticed that in COMSOL, they select all front surfaces (including all surfaces of the bar) for the “Internal” load, even though the arrows in the ISO document are misleadingly suggesting what you selected.

 ![image](https://global.discourse-cdn.com/free1/uploads/prepomax/original/2X/9/9a6c24d352ba3362b0c4c73e154a70ece6f7ffcc.png)  
([Thermal Bridges in Building Construction — 3D Iron Bar Through Insulation Layer](https://www.comsol.com/model/thermal-bridges-in-building-construction-3d-iron-bar-through-insulation-layer-12575))

 ![image](https://global.discourse-cdn.com/free1/uploads/prepomax/original/2X/7/7e7de1d5362503c67501c4ca6b91822686cdffb8.png)

With this corrected selection, I get:

 ![image](https://global.discourse-cdn.com/free1/uploads/prepomax/original/2X/f/f672d0c5b3a0b44c6f66fd5d5644defa89ac18d2.png)

[Case 4 hex 2.pmx](https://prepomax.discourse.group/uploads/short-url/rDqtPgOPHvwc8fN6aewusJmfvGk.pmx) (5.2 MB)

---

<div class="post-metadata">

**Author:** ![CosmoKramer](https://yyz2.discourse-cdn.com/free1/user_avatar/prepomax.discourse.group/cosmokramer/32/6636_2.png) [@CosmoKramer](https://prepomax.discourse.group/u/CosmoKramer)\
**Post date:** [May 9, 2026, 12:48pm UTC](https://prepomax.discourse.group/t/validation-against-iso-10211-2017/3467/7 "2026-05-09T12:48:35Z")

</div>

Thanks @FEAnalyst. Yes, I just looked at the documents for HEAT3 and they assumed that only the cut off planes of the insulation layer are adiabatic – suggesting that all internal surface of the iron bar have a load. So I’ve now changed that while keeping the same merge compound + tie settings and got 0.543 W (0.527%) and 0.800 C (0.005 C), which complies with the standard. The standard is indeed confusing.

I prefer to work with merge compound + ties as it makes it easier to assign materials. I’ve also passed Case 3 with the same settings, which is much more complex.

 ![image](https://global.discourse-cdn.com/free1/uploads/prepomax/original/2X/6/6298465e0ad5fe70f5785369fa883146f01a98e6.png)

---

<div class="post-metadata">

**Author:** ![CosmoKramer](https://yyz2.discourse-cdn.com/free1/user_avatar/prepomax.discourse.group/cosmokramer/32/6636_2.png) [@CosmoKramer](https://prepomax.discourse.group/u/CosmoKramer)\
**Post date:** [May 9, 2026, 12:54pm UTC](https://prepomax.discourse.group/t/validation-against-iso-10211-2017/3467/8 "2026-05-09T12:54:41Z")

</div>

In hindsight, compounding the entire model then unchecking merge compound means I don’t have to search for ties and swap slave/master, which would also save time. So I might adopt that workflow in the future

---

<div class="post-metadata">

**Author:** ![FEAnalyst](https://yyz2.discourse-cdn.com/free1/user_avatar/prepomax.discourse.group/feanalyst/32/688_2.png) [@FEAnalyst](https://prepomax.discourse.group/u/FEAnalyst)\
**Post date:** [May 9, 2026, 1:05pm UTC](https://prepomax.discourse.group/t/validation-against-iso-10211-2017/3467/9 "2026-05-09T13:05:09Z")

</div>

Yes, both workflows are valid, but it’s good to avoid tie constraints if possible (they may e.g. introduce artificial stress concentrations and interfere with other constraints).

Thus, I use compounding with the default settings in most cases (it may just not work well for shells and some assemblies without good alignment).

---

<div class="post-metadata">

**Author:** ![CosmoKramer](https://yyz2.discourse-cdn.com/free1/user_avatar/prepomax.discourse.group/cosmokramer/32/6636_2.png) [@CosmoKramer](https://prepomax.discourse.group/u/CosmoKramer)\
**Post date:** [May 11, 2026, 4:24am UTC](https://prepomax.discourse.group/t/validation-against-iso-10211-2017/3467/10 "2026-05-11T04:24:16Z")

</div>

I’ve now done all four cases and the results fall within the permitted margin of error. So it can now be said that PrePoMax/CalculiX is validated against ISO 10211-2017. Putting the results here so all the details are publicly available (the pmx files for all cases can be downloaded from [here](https://1drv.ms/u/c/eec7215cdc16258e/IQAw6Y58-6RnQJKzz-4D6q0gATn-LYK7k4cfiBFFE_FjDTM?e=XHPsQC)).

**Case 1**

 ![Case1_TmprtrDist](https://global.discourse-cdn.com/free1/uploads/prepomax/original/2X/4/4dc49913695355434efa8b76f16ab462715c53a4.jpeg)

Results for each point were obtained through linear interpolation (using ParaView)

 ![image](https://global.discourse-cdn.com/free1/uploads/prepomax/original/2X/d/daf2b26cfd4f5e6ef6a3e59677f2e66c2b93920c.png)

**Case 2**

 ![Case2_TmprtrDist](https://global.discourse-cdn.com/free1/uploads/prepomax/original/2X/8/8008aca26e847cb06cab6481af89f38386859404.jpeg)

 ![image](https://global.discourse-cdn.com/free1/uploads/prepomax/original/2X/d/d34ef3b97eaca5e8a9aae77e853944a73af289b9.png)

**Case 3**

 ![Case3_TmprtrDist](https://global.discourse-cdn.com/free1/uploads/prepomax/original/2X/6/66d92e5385c77c7374cbe6a2de942f1df624f950.jpeg)

 ![image](https://global.discourse-cdn.com/free1/uploads/prepomax/original/2X/4/4fae0b49bf35b71471eefb3196033714a1484b08.png)

**Case 4**

 ![Case4_TmprtrDist](https://global.discourse-cdn.com/free1/uploads/prepomax/original/2X/9/901b70423e27e56866b600a55f6a4af323d05f57.jpeg)

 ![image](https://global.discourse-cdn.com/free1/uploads/prepomax/original/2X/4/44001d314715033d3f8822f76f65c8ae6de077fd.png)

---

<div class="post-metadata">

**Author:** ![MisiaKu](https://avatars.discourse-cdn.com/v4/letter/m/e5b9ba/32.png) [@MisiaKu](https://prepomax.discourse.group/u/MisiaKu)\
**Post date:** [May 12, 2026, 7:43am UTC](https://prepomax.discourse.group/t/validation-against-iso-10211-2017/3467/12 "2026-05-12T07:43:57Z")

</div>

I apologize for the translation errors. Thank you for carrying out the validation. Great work. The mesh in the models you shared is too fine. I opened the first model. The FEM mesh should be as coarse as possible to demonstrate the maximum error of the results. Proving minimal error and maximum accuracy is unnecessary, because in real engineering work nobody has that much time. Excessive mesh refinement makes it more difficult to identify errors:

 ![image](https://global.discourse-cdn.com/free1/uploads/prepomax/original/2X/0/04d48061e0d68e02773008ee5ab390b1d10e35b3.png)

 ![image](https://global.discourse-cdn.com/free1/uploads/prepomax/original/2X/5/57db4d0c1146304c4b78c7008e7274c6758fff51.png)

 ![image](https://global.discourse-cdn.com/free1/uploads/prepomax/original/2X/7/70ef8796402debd9e535c2789644e09bb4a4e2e6.jpeg)

---

<div class="post-metadata">

**Author:** ![FEAnalyst](https://yyz2.discourse-cdn.com/free1/user_avatar/prepomax.discourse.group/feanalyst/32/688_2.png) [@FEAnalyst](https://prepomax.discourse.group/u/FEAnalyst)\
**Post date:** [May 12, 2026, 8:02am UTC](https://prepomax.discourse.group/t/validation-against-iso-10211-2017/3467/13 "2026-05-12T08:02:49Z")

</div>

Yes, hex elements whenever possible and mesh convergence studies (starting from lower densities) are always recommended: [https://wiki.freecad.org/FEM\_Geometry\_Preparation\_and\_Meshing#Mesh\_convergence\_studies](https://wiki.freecad.org/FEM_Geometry_Preparation_and_Meshing#Mesh_convergence_studies)

> [@CosmoKramer](#):
>
> Putting the results here so all the details are publicly available (the pmx files for all cases can be downloaded from [here](https://1drv.ms/u/c/eec7215cdc16258e/IQAw6Y58-6RnQJKzz-4D6q0gATn-LYK7k4cfiBFFE_FjDTM?e=XHPsQC)).

Any chance you could put them in a GitHub repo ?

---

<div class="post-metadata">

**Author:** ![ANYS](https://yyz2.discourse-cdn.com/free1/user_avatar/prepomax.discourse.group/anys/32/7737_2.png) [@ANYS](https://prepomax.discourse.group/u/ANYS)\
**Post date:** [May 12, 2026, 8:40am UTC](https://prepomax.discourse.group/t/validation-against-iso-10211-2017/3467/14 "2026-05-12T08:40:36Z")

</div>

[https://arxiv.org/pdf/2010.05207](https://arxiv.org/pdf/2010.05207)

---

<div class="post-metadata">

**Author:** ![FEAnalyst](https://yyz2.discourse-cdn.com/free1/user_avatar/prepomax.discourse.group/feanalyst/32/688_2.png) [@FEAnalyst](https://prepomax.discourse.group/u/FEAnalyst)\
**Post date:** [May 12, 2026, 8:50am UTC](https://prepomax.discourse.group/t/validation-against-iso-10211-2017/3467/15 "2026-05-12T08:50:54Z")

</div>

Simscale’s validation cases also include this standard:

 ![image](https://global.discourse-cdn.com/free1/uploads/prepomax/original/2X/d/d06b06a844964b4fb8f9b88e22f8d8a9443a1176.png)

> **[Validation Cases | Cloud-Based CAE Simulation | SimScale](https://www.simscale.com/docs/validation-cases/)**
>
> Discover our validation page where you can find validation cases for fluid dynamics, solid mechanic, thermal, and thermomechanical simulations!

But they use extremely dense tetrahedral meshes:

 ![image](https://global.discourse-cdn.com/free1/uploads/prepomax/original/2X/9/99c23c2799aaaf45b78dbadcd9447d31813044d2.jpeg)

---

<div class="post-metadata">

**Author:** ![CosmoKramer](https://yyz2.discourse-cdn.com/free1/user_avatar/prepomax.discourse.group/cosmokramer/32/6636_2.png) [@CosmoKramer](https://prepomax.discourse.group/u/CosmoKramer)\
**Post date:** [May 12, 2026, 9:59am UTC](https://prepomax.discourse.group/t/validation-against-iso-10211-2017/3467/16 "2026-05-12T09:59:08Z")

</div>

> [@MisiaKu](#):
>
> The mesh in the models you shared is too fine. I opened the first model. The FEM mesh should be as coarse as possible to demonstrate the maximum error of the results.

The point isn’t to demonstrate maximum error. It’s to see if the software could get results that fall within the allowed margin of error. This was only possible through a mesh size of 5 mm.

> [@MisiaKu](#):
>
> Proving minimal error and maximum accuracy is unnecessary, because in real engineering work nobody has that much time. Excessive mesh refinement makes it more difficult to identify errors:

This isn’t ‘real engineering work’. It’s a standard that has to be followed if we were to say that PrePoMax/CalculiX is validated against ISO 10211-2017. Plus when you want to use a software for engineering/academic work, it has to be validated against some standard. COMSOL, HEAT2&3, Mecway, SimScale, QuickField, FEMAP, and WUFI all use ISO 10211.

You should aim for a scientific balance between accuracy and time/resources. Saying “I don’t have time” isn’t good practice, and a lot of engineering catastrophes happened because people were trying to save time/resources

---

<div class="post-metadata">

**Author:** ![FEAnalyst](https://yyz2.discourse-cdn.com/free1/user_avatar/prepomax.discourse.group/feanalyst/32/688_2.png) [@FEAnalyst](https://prepomax.discourse.group/u/FEAnalyst)\
**Post date:** [May 12, 2026, 10:15am UTC](https://prepomax.discourse.group/t/validation-against-iso-10211-2017/3467/17 "2026-05-12T10:15:29Z")

</div>

> [@CosmoKramer](#):
>
> This was only possible through a mesh size of 5 mm.

A hex mesh should perform better. The easiest case to verify it is the first one.

> [@CosmoKramer](#):
>
> It’s a standard that has to be followed if we were to say that PrePoMax/CalculiX is validated against ISO 10211-2017. Plus when you want to use a software for engineering/academic work, it has to be validated against some standard. COMSOL, HEAT2&3, Mecway, SimScale, QuickField, FEMAP, and WUFI all use ISO 10211.

Btw. your work would be really beneficial for the CalculiX users community if you could post on [their forum](https://calculix.discourse.group/). A proof that CalculiX is now validated against this standard is something definitely worth sharing on the solver’s website or social media. Perhaps the dev team could make good use of this fact.

---

<div class="post-metadata">

**Author:** ![ANYS](https://yyz2.discourse-cdn.com/free1/user_avatar/prepomax.discourse.group/anys/32/7737_2.png) [@ANYS](https://prepomax.discourse.group/u/ANYS)\
**Post date:** [May 12, 2026, 12:46pm UTC](https://prepomax.discourse.group/t/validation-against-iso-10211-2017/3467/18 "2026-05-12T12:46:49Z")

</div>

Validation according to ISO do not only limit to temperatures.

“C.2 General considerations and requirements for validation of calculation methods”

Case 1 has a singular point due to discretely assigned Dirichlet boundary condition. 20ºC and 0ºC are applied to the same node. There is no way to validate in heat flow requirements unless one assumes some additional considerations.

---

<div class="post-metadata">

**Author:** ![FEAnalyst](https://yyz2.discourse-cdn.com/free1/user_avatar/prepomax.discourse.group/feanalyst/32/688_2.png) [@FEAnalyst](https://prepomax.discourse.group/u/FEAnalyst)\
**Post date:** [May 12, 2026, 1:05pm UTC](https://prepomax.discourse.group/t/validation-against-iso-10211-2017/3467/19 "2026-05-12T13:05:11Z")

</div>

That’s why case 1 is the only one where heat fluxes are not considered/required and only temperatures at points away from this singularity are of interest.

---

<div class="post-metadata">

**Author:** ![ANYS](https://yyz2.discourse-cdn.com/free1/user_avatar/prepomax.discourse.group/anys/32/7737_2.png) [@ANYS](https://prepomax.discourse.group/u/ANYS)\
**Post date:** [May 12, 2026, 1:53pm UTC](https://prepomax.discourse.group/t/validation-against-iso-10211-2017/3467/20 "2026-05-12T13:53:29Z")

</div>

I don’t understand SIMSCALE using 1.431.857 Elements for passing temperatures.

ccx reaches the required \<0.1ºC with 128 Linear Hex Elements.

 ![imagen](https://global.discourse-cdn.com/free1/uploads/prepomax/original/2X/c/cb26dd7eaa98a5fce35662efb52bf46fafbe0b9c.png)

EDITED: Just 32 elements in case C3D20 are used.

---

<div class="post-metadata">

**Author:** ![FEAnalyst](https://yyz2.discourse-cdn.com/free1/user_avatar/prepomax.discourse.group/feanalyst/32/688_2.png) [@FEAnalyst](https://prepomax.discourse.group/u/FEAnalyst)\
**Post date:** [May 12, 2026, 2:03pm UTC](https://prepomax.discourse.group/t/validation-against-iso-10211-2017/3467/21 "2026-05-12T14:03:47Z")

</div>

It seems that Simscale uses such dense meshes for many of its validation cases. It is indeed strange. From what I know, they use Code\_Aster internally, but such a mesh looks like an overkill at first glance already.

Unfortunately, Abaqus doesn’t use this standard in its documentation, but QuickField does: [Thermal bridges in building construction. Test case A.1 validation --QuickField FEA Software](https://quickfield.com/advanced/iso_10211_2007_case1.htm)

Their mesh is based on automatic refinement:

 ![image](https://global.discourse-cdn.com/free1/uploads/prepomax/original/2X/4/4c27841bb728c02588d8d761c2a2b12efd4bbce6.jpeg)

[Next page](https://prepomax.discourse.group/t/validation-against-iso-10211-2017/3467.md?page=2)
