# A new PrePoMax version v2.4.0 has been released **URL:** \ **Category:** News\ **Created:** [October 13, 2025, 3:08pm UTC](https://prepomax.discourse.group/t/a-new-prepomax-version-v2-4-0-has-been-released/3011 "2025-10-13T15:08:10Z")\ **Posts on this page:** 6\ **Page:** 1
**Author:** ![Matej](https://avatars.discourse-cdn.com/v4/letter/m/a698b9/32.png) [@Matej](https://prepomax.discourse.group/u/Matej)\ **Post date:** [October 13, 2025, 3:08pm UTC](https://prepomax.discourse.group/t/a-new-prepomax-version-v2-4-0-has-been-released/3011/1 "2025-10-13T15:08:11Z")
A new release version of the PrePoMax contains the following fem features (with regard to v2.3.9): - bug fixes And the following user features: - Added support for user views - Added support for follower view - Added support for computing volume from results by using a history output called From Element Size - Added support for smoother zooming by using CTRL + mouse wheel or CTRL + middle mouse button - bug fixes The list of all new features can be found at: [Version 2.4.0](https://prepomax.fs.um.si/version-2-4-0/) Download: [PrePoMax](https://prepomax.fs.um.si/downloads/) ---
**Author:** ![OpenSourceFEA](https://avatars.discourse-cdn.com/v4/letter/o/4da419/32.png) [@OpenSourceFEA](https://prepomax.discourse.group/u/OpenSourceFEA)\ **Post date:** [October 16, 2025, 3:45am UTC](https://prepomax.discourse.group/t/a-new-prepomax-version-v2-4-0-has-been-released/3011/2 "2025-10-16T03:45:13Z")
Hi Matej, Is it possible to bring back a feature that was present until 2.3.0? When you split a part and select surfaces and merge the split parts back, the selected surfaces which is now inside the part, vanishes. If you select FE based surface, it stays but when you apply pre-tension load on that surface, there it faces issues. In one of my previous projects, > [@V2.3.dev: Load assignment on "internal" faces gets lost after merging parts](https://prepomax.discourse.group/t/v2-3-dev-load-assignment-on-internal-faces-gets-lost-after-merging-parts/2710/9): > > I have a tubular structure where I apply the bolt pretension at a cross section just above the threads. Since it is a complex part, I use second order tet mesh with a boundary layer on both sides of the cross section. > > Pre 2.3.0 I was able to select the surface and merge the part back into one and was able to run the simulation successfully. But the newer versions, I can only select the FE based surface like you suggested here. I set the pretension direction “auto-compute”. > > Geometry based surface selection I get the pretension direction calculated by calculix > > `*INFO: pre-tension normal for surface BOLTLOAD-1` > `-4.5946230207038368E-018 1.6354628026558331E-016 -1.0000000000000000` > > which is purely in z-direction (x and y values are very small and negligible for my calculation) > > FE based surface selection I get the pretension direction calculated by calculix > > `*INFO: pre-tension normal for surface BOLTLOAD-1` > `0.54178583594546259 -0.84051657209651520 0.0000000000000000` > > I am completely getting pretension in some other undesired direction. > > So I did two things > > 1. Either set the pretension direction manually in z direction for FE surface selection > 2. Or leave the split parts unmerged for geometry based surface selection > > I am still getting some convergence issues while trying the workarounds which was not present in the older versions. The older version was more convenient, is it possible to bring it back? In the end I had to keep the split parts separate, al though this is not a huge issue, but when I have many parts in the simulation, it is hard to keep track. So can you have a look into it? Thank you ---
**Author:** ![Matej](https://avatars.discourse-cdn.com/v4/letter/m/a698b9/32.png) [@Matej](https://prepomax.discourse.group/u/Matej)\ **Post date:** [October 16, 2025, 6:14am UTC](https://prepomax.discourse.group/t/a-new-prepomax-version-v2-4-0-has-been-released/3011/3 "2025-10-16T06:14:21Z")
I will look into it. However, I believe I have made some changes to address the issues with exacly this matter. But as a temporary solution, instead of merging the parts, you can try merging only the nodes. ---
**Author:** ![Matej](https://avatars.discourse-cdn.com/v4/letter/m/a698b9/32.png) [@Matej](https://prepomax.discourse.group/u/Matej)\ **Post date:** [October 16, 2025, 7:51am UTC](https://prepomax.discourse.group/t/a-new-prepomax-version-v2-4-0-has-been-released/3011/4 "2025-10-16T07:51:18Z")
> [@Matej](#): > > But as a temporary solution, instead of merging the parts, you can try merging only the nodes. I think I understand now. Your nodes are already merged and you merge the parts only. Is it necessary to merge the parts at the end? ---
**Author:** ![OpenSourceFEA](https://avatars.discourse-cdn.com/v4/letter/o/4da419/32.png) [@OpenSourceFEA](https://prepomax.discourse.group/u/OpenSourceFEA)\ **Post date:** [October 17, 2025, 3:15pm UTC](https://prepomax.discourse.group/t/a-new-prepomax-version-v2-4-0-has-been-released/3011/5 "2025-10-17T15:15:11Z")
Keeping the split parts separate won’t be an issue as long as the part count is low. If I use lots of bolts say for example in a flange, then the part count nearly doubles and it will be hard to track contact surface pairs and since there is no way to rearrange the part list in prepomax, all of them are jumbled up here and there and sometimes I pair the wrong surface and the model never converges. It is not a deal breaker but it was a nice feature till it was there. ---
**Author:** ![Matej](https://avatars.discourse-cdn.com/v4/letter/m/a698b9/32.png) [@Matej](https://prepomax.discourse.group/u/Matej)\ **Post date:** [October 18, 2025, 7:27am UTC](https://prepomax.discourse.group/t/a-new-prepomax-version-v2-4-0-has-been-released/3011/6 "2025-10-18T07:27:31Z")
The reason why the internal faces do not work any more is by desing. After some problems with internal faces after the neighbouring parts are merged (in PrePoMax, only parts can be hidden, so after merger, the internal faces can not be reselected by the user or automatically), I decided that keeping internal faces which cannot be used later is not useful. And it is also topologically incorrect. So this will stay as it is. However, I also see the need to be able to organise items in the tree, so I will look into adding support for moving and grouping tree items. In this way, the problem you describe can be solved in a correct way. It will introduce some additional work, but it will bring a better user experience for the future.